(no subject)
Locked
 
|
Rony,
Currently the novice user doesn't even need a compiler - he can just use NetRexx to interpret his programs. Serious developers (working in a combined NetRexx/Java environment) will generally want a full language compiler. I see Janino as an interesting and useful niche tool, but I don't think trying to integrate it with NetRexx is the way to go. As Mike pointed out, NetRexx itself could be extended to generate byte code. Keeping NetRexx compiler independent is a benefit, not a deficit. Making NetRexx dependent on Janino to solve a user installation problem doesn't makes sense to me. By all means make it easy for a user to use Janino if he wishes, but do not bundle it. Certainly any user who can download and install NetRexx and can also download and install Janino. Presumably the Janino installation includes adding it to the class path, so wouldn't adding the ability to use the new compiler API to NetRexx handle the problem quite simply? It seems to me that bundling a compiler or any other external package with NetRexx is a bad idea in general. Users with compiler problems may assume that they are NetRexx problems, and expect support. Keeping up with the releases of another package is bad enough, let alone being forced to update the NetRexx distribution. Currently I include the NetRexx jar with the Eclipse plugin only for user convenience. As soon as there is a "Standard" NetRexx installation process, the plugin will just point to it so there will not be a synchronization problem. As for ease of use, all the Eclipse user has to do is to install the plugin, edit his .nrx file and "Alt-I" will run it without a compiler. "Alt-T" translates to Java, which can be exported and the user can compile it with any compiler he chooses. "Alt-C" compiles, using what ever compiler has been specified (although until NetRexx can be told to use the standard API, it assumes the old interface). If you can tell me how to make it easier or more flexible (given the Eclipse environment), I'll consider implementing it! On the less serious side, if you want to bundle other packages with NetRexx why not just bundle that little Eclipse package? That would give the user all the features you are asking for and much more - ease of installation, immediate full use of NetRexx, a full 1.6 level compiler, etc. :) :) Bill On 9/23/2011 5:48 AM, Rony G. Flatscher wrote: ... > The core of the problem seems to be that the NetRexx package is not self-contained in the sense, that one is able to take immediately advantage in full of it after installation. > > What is missing is a compiler being on board/part of the NetRexx package, such that no other dependencies exist for the developers and users of NetRexx. > > To alleviate this nasty (and counter-productive) and big problem for most, adding an opensource, license compatible Java compiler would fill the bill for the time being. If the compiler gets added to the NetRexx distribution (to the NetRexx jar) itself is also capable of taking advantage of the 1.6/6 and later compilers, then it would solve a big usability/deployment problem for NetRexx. And it would solve it now. > > Adding Janino or the like to NetRexx would not mean that some future developments are not possible, but rather, that the current drop of NetRexx can finally run without a need to hunt down the needed compiler. > > To make this flexible, one could change the current NetRexx code to fall back to Janino or the like, if the NetRexx-expected Java compiler cannot be found. This way, the execution paths remain the same for installations and developers who have managed to spot tools.jar and incorporate it. Newcomers (developers as well as users), however, who have no real clues about this specifity are safe as well, being able to use NetRexx in full without any further hazzles. ... > ---rony -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Bill -
As soon as I can get a little spare time to set up a test branch, I will look into how to add support for the compiler API to NetRexx. Accessing Java items that may or may not be present is a little tricky! -- Kermit On 9/23/2011 12:31 PM, [hidden email] wrote: > Rony, > > Currently the novice user doesn't even need a compiler - he can just use > NetRexx to interpret his programs. Serious developers (working in a > combined NetRexx/Java environment) will generally want a full language > compiler. I see Janino as an interesting and useful niche tool, but I > don't think trying to integrate it with NetRexx is the way to go. As Mike > pointed out, NetRexx itself could be extended to generate byte code. > Keeping NetRexx compiler independent is a benefit, not a deficit. > > Making NetRexx dependent on Janino to solve a user installation problem > doesn't makes sense to me. By all means make it easy for a user to use > Janino if he wishes, but do not bundle it. Certainly any user who can > download and install NetRexx and can also download and install Janino. > Presumably the Janino installation includes adding it to the class path, so > wouldn't adding the ability to use the new compiler API to NetRexx handle > the problem quite simply? > > It seems to me that bundling a compiler or any other external package with > NetRexx is a bad idea in general. Users with compiler problems may assume > that they are NetRexx problems, and expect support. Keeping up with the > releases of another package is bad enough, let alone being forced to update > the NetRexx distribution. Currently I include the NetRexx jar with the > Eclipse plugin only for user convenience. As soon as there is a "Standard" > NetRexx installation process, the plugin will just point to it so there > will not be a synchronization problem. > > As for ease of use, all the Eclipse user has to do is to install the > plugin, edit his .nrx file and "Alt-I" will run it without a compiler. > "Alt-T" translates to Java, which can be exported and the user can compile > it with any compiler he chooses. "Alt-C" compiles, using what ever > compiler has been specified (although until NetRexx can be told to use the > standard API, it assumes the old interface). If you can tell me how to > make it easier or more flexible (given the Eclipse environment), I'll > consider implementing it! > > On the less serious side, if you want to bundle other packages with NetRexx > why not just bundle that little Eclipse package? That would give the user > all the features you are asking for and much more - ease of installation, > immediate full use of NetRexx, a full 1.6 level compiler, etc. :) :) > > Bill > > On 9/23/2011 5:48 AM, Rony G. Flatscher wrote: > ... >> The core of the problem seems to be that the NetRexx package is not > self-contained in the sense, that one is able to take immediately advantage > in full of it after installation. >> What is missing is a compiler being on board/part of the NetRexx package, > such that no other dependencies exist for the developers and users of > NetRexx. >> To alleviate this nasty (and counter-productive) and big problem for > most, adding an opensource, license compatible Java compiler would fill the > bill for the time being. If the compiler gets added to the NetRexx > distribution (to the NetRexx jar) itself is also capable of taking > advantage of the 1.6/6 and later compilers, then it would solve a big > usability/deployment problem for NetRexx. And it would solve it now. >> Adding Janino or the like to NetRexx would not mean that some future > developments are not possible, but rather, that the current drop of NetRexx > can finally run without a need to hunt down the needed compiler. >> To make this flexible, one could change the current NetRexx code to fall > back to Janino or the like, if the NetRexx-expected Java compiler cannot be > found. This way, the execution paths remain the same for installations and > developers who have managed to spot tools.jar and incorporate it. Newcomers > (developers as well as users), however, who have no real clues about this > specifity are safe as well, being able to use NetRexx in full without any > further hazzles. > ... >> ---rony > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://link.mail2web.com/mail2web > > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
On Fri, Sep 23, 2011 at 16:31, [hidden email] <[hidden email]> wrote:
> As Mike > pointed out, NetRexx itself could be extended to generate byte code. > Keeping NetRexx compiler independent is a benefit, not a deficit. Is it me or the two statements above contradict each other?. I remember reading Mike said that generating Java source ensures 100% compatibility with whatever changes the JDK compiler might bring. Whereas generating bytecode directly is something I'd really would like to AVOID, as it just introduces problems for no benefit at all. FC -- "Si, yo creo en los objetos. Inclusive más que en los seres humanos. Creo que son más fieles ¿no?. Porque, claro, los seres humanos pueden traicionarte, pero los objetos no, a los objetos los traicionamos nosotros." -Manuel Mujica Laines _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by billfen
Fernando,
I don't think there is a contradiction - the first is a possibility (pointed out by Mike), the second is my opinion that keeping NetRexx out of the compiler business is preferable. The point is that IF it is decided that NetRexx MUST get into the compiler business, enhancing NetRexx to generate byte code is yet another possibility. I didn't say I was in favor of it, and I agree that it would NOT be a good idea. Better to just let the user specify whatever compiler he wants to use. The existing compilers are adequate, and the effort necessary to implement NetRexx byte code generation might be better spent on other things (like installers :) Bill On 9/24/2011 2:07 AM, Fernando Cassia wrote: > On Fri, Sep 23, 2011 at 16:31, [hidden email] <[hidden email]> wrote: >> As Mike >> pointed out, NetRexx itself could be extended to generate byte code. >> Keeping NetRexx compiler independent is a benefit, not a deficit. > Is it me or the two statements above contradict each other?. I > remember reading Mike said that generating Java source ensures 100% > compatibility with whatever changes the JDK compiler might bring. > > Whereas generating bytecode directly is something I'd really would > like to AVOID, as it just introduces problems for no benefit at all. > > FC > -------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Fernando Cassia-2
It seems to me the contradiction is inevitable from the conflicting desires that have been expressed on the list: 1) Don't let NetRexx generate Java byte-code - let someone else worry about JVM byte-code compatibility while we only worry about compatibility with Java source code changes. 2) Let NetRexx installation and user development be independent of whether or not a Java compiler has been installed by either including a compiler such as Janino with the distribution or by extending NetRexx to generate byte-code directly. In case you did not notice it, there is a bit of contradiction in goals that someone is going to have to address. ;-) My personal opinion in case anyone is interested: I don't think #1 makes much sense because my understanding is that Java byte-code is a far more stable target than Java source code. Correct me if anyone knows different, but I think I have heard that the changes to Java in the last decade have been almost entirely to the source code with very little change to byte-code. As for #2, it seems to me that if we include a compiler with NetRexx, we are going to get stuck supporting it and to some degree guaranteeing that it produces compatible byte-code. If we have to do that anyway, it would be a lot easier with our own code (in NetRexx!). Just my $.02 -- Kermit On 9/23/2011 11:07 PM, Fernando Cassia wrote: > On Fri, Sep 23, 2011 at 16:31, [hidden email]<[hidden email]> wrote: >> As Mike >> pointed out, NetRexx itself could be extended to generate byte code. >> Keeping NetRexx compiler independent is a benefit, not a deficit. > Is it me or the two statements above contradict each other?. I > remember reading Mike said that generating Java source ensures 100% > compatibility with whatever changes the JDK compiler might bring. > > Whereas generating bytecode directly is something I'd really would > like to AVOID, as it just introduces problems for no benefit at all. > > FC > Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
Kermit, As soon as I can get a little spare time to set up a test branch, I will look into how to add support for the compiler API to NetRexx. Accessing Java items that may or may not be present is a little tricky! No, it's not. At its simplest: do compilerClass = Class.forName("comp.fake.janino.Main")
catch ClassNotFoundException
say "Falling back to SUN's compiler"
compilerClass = Class.forName("com.sun.tools.javac.Main")
end compiler = compilerClass.newInstance() Really a Constructor object should be instantiated in order to be able to catch some exceptions, and pass constructor parameters in via its newInstance method.
Just wanted to show the pattern is not tricky at all. Saludos / Regards, David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
2011/9/24 Kermit Kiser <[hidden email]> Folks, get over it. You need to spend 15 minutes reading the right documentation to transform that install nightmare into a breeze. You'll be able actually understand what to do when you ask on the list "How do I do X" and you get a response like "use library Y or library Z" back.In case you did not notice it, there is a bit of contradiction in goals that someone is going to have to address. ;-) What I notice is we're completely missing the point. See below. My personal opinion in case anyone is interested: True. That could change tomorrow. Do we wan't * WARRANTED* compatibility or do do we want *MOST PROBABLE* compatibility?
As for #2, it seems to me that if we include a compiler with NetRexx, we are going to get stuck supporting it and to some degree guaranteeing that it produces compatible byte-code. If we have to do that anyway, it would be a lot easier with our own code (in NetRexx!). Anyway nothing is to be achieved.
Admittedly that documentation should be at the "User's guide" which it is not today. So lets solve the actual problem at hand, lets do explain our new users how thing work; its not rocket science.
Saludos / Regards, David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Kermit wrote:
Does this matter? NetRexx doesn't (necessarily) have to track changes in Java source code practices - it only has to produce source code acceptable to the compiler. That is, some subset adequate for NetRexx's purposes. Can anyone give an example of changes to Java source that have occurred since NetRexx's last iteration that MUST be tracked by NetRexx to guarantee class compatibility? Is it likely that Java will change in some direction that invalidates existing source code? Producing source code has a critical role in reassuring potential users of NetRexx's compatibility with Java, which should not be undersold. I suspect almost any article comparing JVM languages would quote the following assertion about NetRexx (if we stress it): NetRexx is guaranteed to produce classes identical to those of any desired compiler because it emits Java source code, which can simply be compiled with that compiler.
This strikes me as an arresting claim to anyone using Java to make a living. And its correctness seems indisputable -- the potential user does not have to wonder about NetRexx's ability to produce correct byte code whose verification, according to "The Java Virtual Machine" (O'Reilly), does not seem a simple process. He takes on no new risk (re byte code compliance) beyond that already incurred with his favored Java compiler. [Of course, this does not guarantee that NetRexx produces a correct translation of his NetRexx statements into Java source.]This is not to say that NetRexx should not be capable of generating byte code, whether as default or option. However, if David is right that the installation process can be gotten under control basically through clear thinking, it seems a poor idea to introduce compilers and/or byte code generation just to "solve" the installation problem. The cure could be worse than the disease. George On Sat, Sep 24, 2011 at 7:00 AM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I don't know where this idea comes from but it simply is not true.
When I researched creating Java byte-code, I discovered that the
developers of Java have a VERY strict rule of backwards
compatibility for the JVM. That means that Java 1.0 byte-code will
still run on a Java 7 JVM. That is not the case for Java source
code. Changes to Java often break source code compatibility - just
for example Java 1.5 introduced the restricted keyword "enum" which
forced source code changes to many Java programs. It did NOT break
byte-code compatibility, however. There are many similar examples.
The fact is that guaranteeing compatibility with Java source code is
MORE difficult than guaranteeing byte-code compatibility, not less!
Note that I am NOT advocating removing the ability of NetRexx to produce Java source code or to use any compiler desired. There are other reasons to keep that ability that are important. For example, Android programs don't use Java byte-code but something else called "dex-code". Another example - GCJ can turn Java source code into native binary executables which should allow NetRexx programs to run on machines that don't even have Java (I confess I have not tried this yet.). -- Kermit On 9/24/2011 7:06 AM, George Hovey wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Kermit,
This idea came out of my head, but I'm prepared to be disabused of it. Admittedly, since Java made the (very bad in my view) decision to reserve words, this particular type of problem can arise at any time. It also doesn't sound very serious (for us) because we have only one program to patch up. Can you list some other types of source problems that have arisen that would prove troublesome? However, re the byte code issue, I wasn't thinking of backward compatibility, but the problem of verifying that the NetRexx compiler generates correct byte code under all circumstances on each release. Do you see this as a problem? On Sat, Sep 24, 2011 at 1:04 PM, Kermit Kiser <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by George Hovey-2
On Sat, Sep 24, 2011 at 11:06, George Hovey <[hidden email]> wrote:
> The cure could be worse than the disease. If there is any ´installer´ it should just check "is javac available"? yes=>check version if minimum required by netrexx no=>offer to download the JDK (if platform=win32, Linux, solaris). if platform=other detect OS and point users to the right web page (IBM´s JDKs, etc).. potentially offering to download it and start the jdk install process. (the above would require a list of hardcoded JDK download urls, or just a fixed location at netrexx.org where the jdks would be mirrored always at the last version for each OS). Just my $0.02 FC _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
On Sat, Sep 24, 2011 at 14:04, Kermit Kiser <[hidden email]> wrote:
> Another example - GCJ can turn Java source code into native binary > executables which should allow NetRexx programs to run on machines that > don't even have Java (I confess I have not tried this yet.). Didn´t IBM also have its own Java native code compiler? JIKES perhaps? that name rings a bell. It´s all in that nebulous past when I was an OS/2 Warp 4.x user... only 14 years ago. FC _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by George Hovey-2
Hi George -
Actually, NetRexx consists of about 100 source modules which use various Java features so it may be a little more complex than you thought. I think that the problems that have come up in NetRexx, like the inability to extend Java classes such as PrintStream, are not generally caused by changes to Java byte-code nor by changes to Java source code syntax. They seem to be mostly related to changes in the base Java class libraries. That makes it very difficult to predict when Java changes are going to break NetRexx since there is a lot of content to consider. It also makes the discussion of byte-code vs source code probably of limited value since that is not where our problems come from. Changes like the assert and enum keywords or generics syntax have not broken NetRexx, fortunately! I am not sure I understand your question about generating byte-code. If NetRexx created valid byte-code for a Java 1.5 JVM, that byte code would automatically be valid for any later Java version. If you are talking about a later release of NetRexx, then any change we made to the generated bytecode for an instruction would have to be tested, but only with the target JVM version - pretty much the same thing we do now with the Java source code. -- Kermit On 9/24/2011 2:10 PM, George Hovey wrote: Kermit, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Fernando Cassia-2
On Sun, Sep 25, 2011 at 02:39, Fernando Cassia <[hidden email]> wrote:
> > Didn´t IBM also have its own Java native code compiler? JIKES perhaps? > that name rings a bell. Oh, sorry, it seems Jikes is not a native compiler, just an improved javac, and according to people in StackOverflow, it´s no longer the advantage that used to be: http://stackoverflow.com/questions/810535/is-it-worth-switching-to-ibm-jikes-java-compiler FC _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by Fernando Cassia-2
Hello there,
first I did change the SUBJECT to 'Installer issues' I'm actually hating messages with (no subject), as it does partially make my whole archiving&filing system a bit obsolete :-) Second, *I think* that Fernando's *short spec* (below) is a very valid one. Bravo, Fernando. All: Have a nice weekend, Thomas. ========================================================= Am 25.09.2011 07:31, schrieb Fernando Cassia: > On Sat, Sep 24, 2011 at 11:06, George Hovey<[hidden email]> wrote: >> The cure could be worse than the disease. > If there is any ´installer´ it should just check > > "is javac available"? yes=>check version if minimum required by netrexx > no=>offer to download the JDK (if platform=win32, Linux, solaris). > > if platform=other detect OS and point users to the right web page > (IBM´s JDKs, etc).. potentially offering to download it and start the > jdk install process. > > (the above would require a list of hardcoded JDK download urls, or > just a fixed location at netrexx.org where the jdks would be mirrored > always at the last version for each OS). > > Just my $0.02 > FC > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |