This is Stuafcb's Typepad Profile.
Join Typepad and start following Stuafcb's activity
Join Now!
Already a member? Sign In
Stuafcb
Recent Activity
@Scott I should have been clearer - when I say shell script I do mean writing custom code in Java and then calling that from the script.. I wasn't suggesting that was the way to reduce the overhead... I don't necessarily agree that the batch-immediate job is always worse though. After all that job goes away and the resources are freed up rather than being held onto for the lifetime of the calling job. That may, or may not, be more desirable behaviour depending on the scenario at hand; how long lived the parent job is and how much Java work is going to be done. I didn't say that the classpath issue was insurmountable, just that people need to be aware of it and plan around it. If you set it globally so that everything you ever want is on it then everything always needs to be compatible with the same versions of all of the jars. If you upgrade one of them you'll need to regression-test everything else against the new version. It would be far preferable for every application to be able to set its own classpath. I don't think an "RPG coder that doesn't want to learn Java" is going to get very far in making use of any of the Java libraries you mention without learning quite a bit of Java first. That coder needs the kind of RPG-friendly wrapper libraries that the article talks about rather going directly to the RPG->Java interface themselves.. but they do still need to be aware of the issues that the underlying Java presents... The crux of the matter, which I think we both agree on, is that you should only use Java when you absolutely must (when your software is running in OS/400 and outside of an application server anyway..) - I just wanted to sound a little note of caution to that effect.
1 reply
I'd be cautious over recommending using the RPG -> Java interface because there are a few issues which mean that you need to be very careful about how you use it. Firstly, there's the fact that it creates a JVM to execute the code in. There's a performance hit there and a scalability issue. If you've got a lot of interactive users then this isn't something you want every user with an interactive session doing... Secondly, there are issues with the classpath. Once you've called Java from RPG in your job, you can't do it again with a different classpath. So if a user calls program A which loads up POI and make a spreadsheet, it may work great. Trouble is if that user then wants to call program B which loads up JFreeChart and make a graph, it's not going to work. You either need a classpath with all the Java libraries you can possibly ever need on it, or you need your own classloader. Personally, I don't see a need ever to use it. There's plenty of good things to be had from Java, but I've never found a task that I wanted to use Java for in OS400 that I couldn't accomplish by calling the Java through a shell script.
1 reply
1. Simplify the declarative mess required for the creation of a subprocedure If I want to create a method in Java, it's really quick. public void doStuff(int parameter) { // Code away! } D doStuff PR D parameter 10i 0 P doStuff B EXPORT D doStuff PI D parameter 10i 0 /FREE //Great, now I can actually write some code. /END-FREE P doStuff E When you put a number of subprocedures in code together, each nice and functionally cohesive - the look of the source member is often more blooming declaration than actual code. It's great that we lose the need for prototypes for private procedures in V6R1 but we could do with getting rid of a lot more of this messy stuff. Why? Because it's a barrier. I have tried to teach a lot of people modern coding techniques, and in spite of the fact that I can sell the benefits of the approaches in keeping data locally scoped, actually getting people to use them becomes very hard because of the overhead of the declarations and the reduced readability of the code. I'd also like to add my vote to these others that people have suggested 2. Procedure namespaces - these should have been in from the start 3. Procedure overloading 4. Improved string handling - even just %bcat() and %tcat() BIFs would be nice. Building a string and having to trim it every time I want to append something to the end is a real PITA.
Toggle Commented Nov 3, 2010 on RPG Wishes at iDevelop
1 reply
Stuafcb is now following The Typepad Team
Nov 3, 2010