NetRexx on J2ME
Locked
 
|
Hi All,
Just to reassess the situation on current CLDC/MIDP (1.1/2.1) levels (and to refresh my memories) I just tried building a simple midlet using NetRexx. Unfortunately it didn't even pass pre-verification: Preverifying 25 file(s) into C:\Documents and Settings\David Requena\Mis documentos\NetBeansProjects\J2MEBook\build\preverified directory. Error preverifying class netrexx.lang.Rexx java/lang/NoClassDefFoundError: java/io/Serializable Mind you that is just by including NetRexxR.jar as a library in a regular WSDK 3.0 project. Obviously some class inside the jar is implementing the java.io.Serializable interface which is *not available* on J2ME. As far as I know, building some stub class under the java.* hierarchy would be disallowed by the platform. I'm so completely stuck as this point. Patric, would you please show me how did you workaround this issue? That would be great as it has kept me from using NetRexx for mobile development for years. Thanks in advance. -- --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Hi David, (old) Friend,
please proceed to re-gister in the NABBLE Environment, IAN has just set for all of us.. IT#s amazing to SEE what is already there on the Internet! Tom. ================================================================== David Requena schrieb: > Hi All, > > Just to reassess the situation on current CLDC/MIDP (1.1/2.1) levels > (and to refresh my memories) > > I just tried building a simple midlet using NetRexx. Unfortunately it > didn't even pass pre-verification: > > Preverifying 25 file(s) into C:\Documents and Settings\David > Requena\Mis documentos\NetBeansProjects\J2MEBook\build\preverified > directory. > Error preverifying class netrexx.lang.Rexx > java/lang/NoClassDefFoundError: java/io/Serializable > > Mind you that is just by including NetRexxR.jar as a library in a > regular WSDK 3.0 project. > > Obviously some class inside the jar is implementing the > java.io.Serializable interface which is *not available* on J2ME. > > As far as I know, building some stub class under the java.* hierarchy > would be disallowed by the platform. I'm so completely stuck as this > point. > > Patric, would you please show me how did you workaround this issue? > That would be great as it has kept me from using NetRexx for mobile > development for years. > > Thanks in advance. > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
In reply to this post by David Requena
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 David Requena schrieb am 19.02.2010 22:54: > Hi All, > > Just to reassess the situation on current CLDC/MIDP (1.1/2.1) levels > (and to refresh my memories) > > I just tried building a simple midlet using NetRexx. Unfortunately it > didn't even pass pre-verification: > > Preverifying 25 file(s) into C:\Documents and Settings\David Requena\Mis > documentos\NetBeansProjects\J2MEBook\build\preverified directory. > Error preverifying class netrexx.lang.Rexx > java/lang/NoClassDefFoundError: java/io/Serializable > > Mind you that is just by including NetRexxR.jar as a library in a > regular WSDK 3.0 project. > > Obviously some class inside the jar is implementing the > java.io.Serializable interface which is *not available* on J2ME. > > As far as I know, building some stub class under the java.* hierarchy > would be disallowed by the platform. I'm so completely stuck as this point. > > Patric, would you please show me how did you workaround this issue? > That would be great as it has kept me from using NetRexx for mobile > development for years. > > Thanks in advance. > That trick is simple: I used options strictimport binary to avoid floating point math and I didn't use the Rexx datatype, hence no NetRexxR.jar needed on the actual device. Anyway, the speed of these devices back in 2000 was an 8MHz 68k CPU, so I needed to quench every cycle out of the code - though using my favourite programming language. Hope that clarifies things a bit... - -- Patric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkt/FZQACgkQfGgGu8y7ypDpWACfVpeu9TsGh7lndg1Efu/Orl0w K/AAnA4iEEwW/aGagrJMxfj3ZN572zvU =kIDA -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
Hello Patric,
*could you* (??) please give short advise where I can read about Java 2 ME (1 bit) ?? Thomas. PS: Please look at what Ian Sterling did with setting up our common appearence there... For me, 'it a great step forward.... simply for common apperance of all those NetRexx discussions ... I simply think, that we are now going into the right directions .,.. ****************************************** .... I.E.: spreading the knowledge about NetRexx ... ****************************************** Thomas.Schneider.Wien (Tom.) =================================================================================== ==================================================================== Patric Bechtel schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David Requena schrieb am 19.02.2010 22:54: > >> Hi All, >> >> Just to reassess the situation on current CLDC/MIDP (1.1/2.1) levels >> (and to refresh my memories) >> >> I just tried building a simple midlet using NetRexx. Unfortunately it >> didn't even pass pre-verification: >> >> Preverifying 25 file(s) into C:\Documents and Settings\David Requena\Mis >> documentos\NetBeansProjects\J2MEBook\build\preverified directory. >> Error preverifying class netrexx.lang.Rexx >> java/lang/NoClassDefFoundError: java/io/Serializable >> >> Mind you that is just by including NetRexxR.jar as a library in a >> regular WSDK 3.0 project. >> >> Obviously some class inside the jar is implementing the >> java.io.Serializable interface which is *not available* on J2ME. >> >> As far as I know, building some stub class under the java.* hierarchy >> would be disallowed by the platform. I'm so completely stuck as this point. >> >> Patric, would you please show me how did you workaround this issue? >> That would be great as it has kept me from using NetRexx for mobile >> development for years. >> >> Thanks in advance. >> >> > > That trick is simple: I used options strictimport binary to avoid > floating point math and I didn't use the Rexx datatype, hence no > NetRexxR.jar needed on the actual device. > Anyway, the speed of these devices back in 2000 was an 8MHz 68k CPU, so > I needed to quench every cycle out of the code - though using my > favourite programming language. > > Hope that clarifies things a bit... > > - -- > Patric > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: GnuPT 2.5.2 > > iEYEARECAAYFAkt/FZQACgkQfGgGu8y7ypDpWACfVpeu9TsGh7lndg1Efu/Orl0w > K/AAnA4iEEwW/aGagrJMxfj3ZN572zvU > =kIDA > -----END PGP SIGNATURE----- > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > > > _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Thomas Schneider schrieb am 20.02.2010 00:01: > Hello Patric, > > *could you* (??) please give short advise where I can read about Java > 2 ME (1 bit) ?? > Hi Thomas, http://en.wikipedia.org/wiki/Connected_Limited_Device_Configuration plenty of links from there... - -- Patric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkt/JR8ACgkQfGgGu8y7ypBukQCdFPf2ZHtQe+hyY2E5uGPabkrF N9UAnRovi29OBKKi4mLOGKj/rLpXyspe =HBfW -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by Patric Bechtel
El 19/02/2010 23:49, Patric Bechtel escribió: > That trick is simple: I used options strictimport binary to avoid > floating point math and I didn't use the Rexx datatype, hence no > NetRexxR.jar needed on the actual device. > Anyway, the speed of these devices back in 2000 was an 8MHz 68k CPU, so > I needed to quench every cycle out of the code - though using my > favourite programming language. > hmm... I must admit I never thought about the bread-without-butter approach. So you loose: - REXX type (decimal aritmetic, arbitrary precision, indexed strings, string handling methods) - NetRexx specific exceptions (overflow error flaging) - Parse - RexxIO (say, ask) - Trace functionality But then you get basic NetRexx syntax. Is that it? Not that I'm saying that all of these are useful on J2ME but anyway it seems is an awful lot to loose to me. I wonder which other NetRexx features are dependent on the NetRexx runtime. Any one? > Hope that clarifies things a bit... > > Yes, it does. Thanks very much. --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
> hmm... I must admit I never thought about the > bread-without-butter approach. > > So you loose: > > - REXX type (decimal arithmetic, arbitrary precision, indexed > strings, string handling methods) > - NetRexx specific exceptions (overflow error flaging) > - Parse > - RexxIO (say, ask) > - Trace functionality > > But then you get basic NetRexx syntax. Is that it? That's about it -- you have 'bare Java' but with NetRexx style & economy of syntax. Some of the applet examples in the package similarly do not need the NetRexx runtime (in their case, mostly to preserve performance across the 'net -- less of an issue these days, but important where people are still connected by dial-up). mfc _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
In reply to this post by David Requena
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 David Requena schrieb am 20.02.2010 11:08: > hmm... I must admit I never thought about the bread-without-butter > approach. That's sound a bit disappointed... > So you loose: > > - REXX type (decimal aritmetic, arbitrary precision, indexed strings, > string handling methods) > - NetRexx specific exceptions (overflow error flaging) decimal arithmetic and arbitrary presision on an embedded device, nahh... String handling works in Java, too. > - Parse that would need input from the user, without keyboard... have fun. > - RexxIO (say, ask) again, no keyboard, no console. > - Trace functionality without console, doesn't make too much sense. > But then you get basic NetRexx syntax. Is that it? I get the language, not the runtime. Nice, compact, concise syntax without semicolons and unnecessary declarations. Yes, basically the syntax is left over. But what do you expect from this kind of device? They are terribly slow and constraint in so many regards... But one advantage stays: I could write my backend and frontend in the same language, share the same I/O classes (ok, some discipline required here, too), same types with same behaviour on both sides. A clear win. > Not that I'm saying that all of these are useful on J2ME but anyway it > seems is an awful lot to loose to me. Ah... at least on J2ME. On Android, we're talking a complete different level, now. There, most if not all of them do make sense. > I wonder which other NetRexx features are dependent on the NetRexx > runtime. Any one? I think you pretty much covered them all. - -- Patric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: GnuPT 2.5.2 iEYEARECAAYFAkt/zs4ACgkQfGgGu8y7ypCUbgCfUf6xGc7gSLnANozwHURtX8Jw C9kAn1Q/pA2ErRgxtLzKLSL4fxv/dfs6 =W/IZ -----END PGP SIGNATURE----- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
>
>> hmm... I must admit I never thought about the bread-without-butter >> approach. >> > That's sound a bit disappointed... > > Unsuprisingly, after having overlooked a simple trick like this for such a long time, *I am disapointed* :-) > decimal arithmetic and arbitrary presision on an embedded device, > well, we're not talking about your microcontroller managing your washing machine programms here... many current cell phones have a lot more muscle than a PC circa 2000 > nahh... String handling works in Java, too. > > Yeah, java String class has lots of string handling methods. I use the a lot when programming in java ;-) >> - Parse >> > that would need input from the user, without keyboard... have fun. > > I fail to see how string deconstruction based on paterns, positional specs, etc. relates to keyboard input at all. Decomposed string could come out of a network socket as well. No to mention I still haven't seen a cell phone without a keyboard :-) >> - RexxIO (say, ask) >> > again, no keyboard, no console. > > Agreed, no console, no use. Maybe while developing with the WSDK but then you have System.in and System.out >> - Trace functionality >> > without console, doesn't make too much sense. > > Looking at trace output at the java console while running a midlet on the emulator sounds like an invaluable tool to me. Failing that, I maybe prefer to go with java and stepping midlets through the debugger. > > I get the language, not the runtime. Nice, compact, concise syntax > without semicolons and unnecessary declarations. Yes, basically the > syntax is left over. > I see value in tht of course. > But what do you expect from this kind of device? They are terribly slow > and constraint in so many regards... > Again, I don't think we're talking about the same kind of target device. > Ah... at least on J2ME. On Android, we're talking a complete different > level, now. There, most if not all of them do make sense. > > The fact remains that J2ME is awfully restricted when it comes to core java APIs while adding lots of jsr for accessing all kinds of exatic hardware. Frankly I'd rather having serialization than having the ability to make the damned thing vibrate :-( OTH there're lots of non Android cells out there which are al least as powerful as current Android models. OK, leave the Nexus One out :-) >> I wonder which other NetRexx features are dependent on the NetRexx >> runtime. Any one? >> > I think you pretty much covered them all. > Mike also confirmed that. Many thanks to both! _______________________________________________ Ibm-netrexx mailing list [hidden email] |
|
|
All the large device makers that support J2ME publish an API for using
the device specific functions. Ex: http://www.blackberry.com/developers/docs/4.0.2api/overview-summary.html Your biggest problem will not be how Parse works, but the security of the J2ME spec. Rusty Ps: The coolest thing to me about NetRexx other than I could still use my favorite Rexx functions, is it's ability to wrap and ribbon existing java code. I see too many questions here where people want to re-invent something in NetRexx that is just fine and dandy in java. NetRexx requires *some* understanding of java. If it were C++Rexx you'd expect the user to have some clue about C++ wouldn't you ?? -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of David Requena Sent: Saturday, February 20, 2010 2:54 PM To: IBM Netrexx Subject: Re: [Ibm-netrexx] NetRexx on J2ME > >> hmm... I must admit I never thought about the bread-without-butter >> approach. >> > That's sound a bit disappointed... > > Unsuprisingly, after having overlooked a simple trick like this for such a long time, *I am disapointed* :-) > decimal arithmetic and arbitrary presision on an embedded device, > well, we're not talking about your microcontroller managing your washing machine programms here... many current cell phones have a lot more muscle than a PC circa 2000 > nahh... String handling works in Java, too. > > Yeah, java String class has lots of string handling methods. I use the a lot when programming in java ;-) >> - Parse >> > that would need input from the user, without keyboard... have fun. > > I fail to see how string deconstruction based on paterns, positional specs, etc. relates to keyboard input at all. Decomposed string could come out of a network socket as well. No to mention I still haven't seen a cell phone without a keyboard :-) >> - RexxIO (say, ask) >> > again, no keyboard, no console. > > Agreed, no console, no use. Maybe while developing with the WSDK but then you have System.in and System.out >> - Trace functionality >> > without console, doesn't make too much sense. > > Looking at trace output at the java console while running a midlet on the emulator sounds like an invaluable tool to me. Failing that, I maybe prefer to go with java and stepping midlets through the debugger. > > I get the language, not the runtime. Nice, compact, concise syntax > without semicolons and unnecessary declarations. Yes, basically the > syntax is left over. > I see value in tht of course. > But what do you expect from this kind of device? They are terribly slow > and constraint in so many regards... > Again, I don't think we're talking about the same kind of target device. > Ah... at least on J2ME. On Android, we're talking a complete different > level, now. There, most if not all of them do make sense. > > The fact remains that J2ME is awfully restricted when it comes to core java APIs while adding lots of jsr for accessing all kinds of exatic hardware. Frankly I'd rather having serialization than having the ability to make the damned thing vibrate :-( OTH there're lots of non Android cells out there which are al least as powerful as current Android models. OK, leave the Nexus One out :-) >> I wonder which other NetRexx features are dependent on the NetRexx >> runtime. Any one? >> > I think you pretty much covered them all. > Mike also confirmed that. Many thanks to both! _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |