|
Am Mittwoch, 20. März 2002 04:26 schrieben Sie: > >> If you need newly written native procedures for performance reasons, it > > would be a better choice to use c modules, they are (more or less) portable > as > source code. > > Oh darn and we were agreeing on so much <grin> > > I would no more use C developing a business app than I would use Java for > writing an OS. > RPG is alive and well and has more than enough horsepower > for business processing. I suspect you have not kept up with RPG or you Jon, you're known as the author of the one and only rpg redbook, but the world outside hasn't changed - not in germany. I'm working in consulting and besides I'm teaching java for rpg people in germany the last 3 years and sometimes I'm teaching ile rpg as well. When I'm asking people, if they are working with ILE RPG, everybody answers shure, he does and asking what he knows about subprocedures and prototypes, they tell: we didn't use this yet, but we have changed a lot of calls to callb. Last three weeks I was teaching ile rpg for a customer of mine and they said: thats not rpg anymore, it looks like c: the c programmers where happy and some of the rpg programmers a little bit more unhappy. > > wouldn't be saying things like: > >> The RPG programmer writing the JNI code has to deal with c in the > > prototypes anyway. > > Which is just plain not true. As I said in an earlier post - all I need to > do to allow Java to call an RPG method is to add the keyword > EXTPROC (*Java:'className':'methodName') > to the prototype of a regular piece of RPG code. Compile it, add it to a > service program and I'm done. JNI - what JNI? The compiler just did all > that for me. I've did a lookup to the manuals of V5R1, you're right there are some pretty enhancements for this; I was playing around with JNI calls to rpg with V4. The example in the programmer guide declares the prototypes by rpg types (and this is the translation step I was talking about in my last posting) - but this seems to be possible with like definitions to java classes as well. Maybe my recommandations will change in the future. There are two problems left: most service programms are using ACTGRP(*CALLER) and the threading issues; synchronization at the module level, but this will normally not cause problems as long as no other thread is created, calling a procedure of the same module (to avoid this, I would not call java from this module). Now we have two ways to call rpg programms of the business layer from a java application: 1) writing a wrapper for a JNI call or 2) registering as stored procedure or UDF case 1 the rpg programmer needs java knowledge case 2 the rpg programmer needs sql knowledge Maybe this might make the decision? When it comes to RPG creating Java objects and using them, > the story is a tiny bit more complex - I have to code the whole prototype > for each Java method that I want to use. Luckily David Morris (?) has > already done this for most methods in the standard Java classes and I > believe has a Java based tool which builds the protos for any custom > classes. Again JNI - what JNI - the compiler does the work! > > Jon Paris > Partner400 > > > _______________________________________________ > This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) > mailing list To post a message email: JAVA400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l > or email: JAVA400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/java400-l. -- mfG Dieter Bender DV-Beratung Dieter Bender Wetzlarerstr. 25 35435 Wettenberg Tel. +49 641 9805855 Fax +49 641 9805856 www.bender-dv.de
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.