design straw man for java compilation by NetRexx
Locked
 
|
Kermit (and others)
if we think about how translated NetRexx source is to be compiled by a Java compiler, and how the location thereof is sometimes a slight impediment to a quick installation, we should also consider other ways than locating the needed components by the installer, being human or software agent. I can think of the following strategies. Implementing some of those and choosing a good interface to steer the process is a design process that we should carefully think through: 1) involving the shell a) saving translated source with -keepasjava -replace and then having javac as a step in a build procedure b) doing a system.exec of javac or its equivalents b1) javac b2) eclipse batch (ecj.jar) b3) jikes b4) janino 2) calling an API a) calling the (now deprecated) sun.tools compiler. This is where we are now. b) calling the new 1.6 compiler api c) calling a compiler specific api - for the b2-b4 mentioned above d) calling a facade pattern like api of our design Safest would be a 'line-of-defence' approach that gradually falls back from most desirable to to less desirable options, following a classification of the above that needs to be made. Note that if we find a working javac on a system, it knows about its runtime and linking necessities, so we could leverage those if our own (human or software) location ability fails. An interface for this could consist of an environment variable, options on the translator or in the source, a configuration file with an optional gui, or a completely automatic and built-in set of rules. Related is the dependency resolution, which is probably the next issue for building larger systems. It would be great if we could combine the two - but the dependency on what the java compiler does should be handled. This is a straw man, it is meant to be fired upon. best regards, René Jansen. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: design straw man for java compilation by NetRexx
|
|
It sounds like you have been thinking along the same lines that I have.
If I understand correctly, the idea is that since we need to modify NetRexx to handle the compiler API and possibly other compiler interfaces, we might as well add all of the logic needed to locate the Java compiler to NetRexx itself, rather than bothering the installer with that task. That seems like a good idea to me. If no compiler can be located, we inform the user that he can only interpret programs until he installs a JDK or other Java compiler. Maybe if the compiler locator is a separate class module, the installer could also include it and give the user an option to set an environment variable if that is needed to locate a Java compiler? Could you explain the dependency issue? Is it something that can be handled by Ant or such? -- Kermit On 9/27/2011 2:30 AM, rvjansen wrote: > Kermit (and others) > > if we think about how translated NetRexx source is to be compiled by a > Java compiler, and how the location thereof is sometimes a slight > impediment to a quick installation, we should also consider other ways > than locating the needed components by the installer, being human or > software agent. > > I can think of the following strategies. Implementing some of those > and choosing a good interface to steer the process is a design process > that we should carefully think through: > > 1) involving the shell > a) saving translated source with -keepasjava -replace and then having > javac as a step in a build procedure > b) doing a system.exec of javac or its equivalents > b1) javac > b2) eclipse batch (ecj.jar) > b3) jikes > b4) janino > > 2) calling an API > a) calling the (now deprecated) sun.tools compiler. This is where we > are now. > b) calling the new 1.6 compiler api > c) calling a compiler specific api - for the b2-b4 mentioned above > d) calling a facade pattern like api of our design > > Safest would be a 'line-of-defence' approach that gradually falls back > from most desirable to to less desirable options, following a > classification of the above that needs to be made. Note that if we > find a working javac on a system, it knows about its runtime and > linking necessities, so we could leverage those if our own (human or > software) location ability fails. > > An interface for this could consist of an environment variable, > options on the translator or in the source, a configuration file with > an optional gui, or a completely automatic and built-in set of rules. > > Related is the dependency resolution, which is probably the next issue > for building larger systems. It would be great if we could combine the > two - but the dependency on what the java compiler does should be > handled. > > This is a straw man, it is meant to be fired upon. > > best regards, > > René Jansen. > _______________________________________________ > 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 rvjansen
I think it is ill advised to assume that the NetRexx translator should take
on the task of locating Java compilers. Who knows what what operating systems and architectures will be using NetRexx? Do we really want to take on the job of modifying NetRexx for OS2, Android or who knows how many other operating systems or special Java environments? What do we do if we find more than one compiler? How do we handle changes? Should NetRexx really be searching for the compiler every time it compiles? I recommend that a more cautious and flexible (and easier) approach be taken: For now, simply tell the user that if he wants to compile the NetRexx source rather than interpret it, he must install the JDK and set the JAVA_HOME environment variable to the JDK directory. (A current common practice.) That satisfies the Java 1.5 requirement of using the old interface with minimal changes. The user will not be able to compile unless he installs a compiler anyway (unless you want NetRexx to take on the job of installing the JDK, janino, jikes, etc. as well, or turn NetRexx into a compiler, or include / integrate janino - all bad ideas in my opinion). Since he installed the compiler, he certainly knows where it is, and should be able to set the JAVA_HOME environment variable with proper instructions and documentation. I believe it is better to ask the user where the compiler is, while providing a reasonable default, than to assume that it can be easily found programmatically. Providing installers for the common operating systems (Windows, Mac and *nix) to do this should be straight forward. Then provide a NetRexx option which specifies that the compiler uses the standard API, and that the compiler is on the class path. Actually specifying the (standard API) compiler path as a NetRexx option or in another environment variable (as Rene suggested) is another alternative. There is a danger in assuming too little competence on the part of the user when he is compiling rather than interpreting. If you want to have the installer ask the user where the compiler he wants to use is, or somehow try to find it, that is one thing, but I definitely suggest that it should NOT be the job of the translator. I think the Unix philosophy of "Do a simple, well defined job, and do it well" applies here. As for the development of the installer(s), the 3 major system families have differences, and clearly the installer(s) must handle them. Where is the NetRexx jar to reside? Certainly putting it in one of Java's folders is a bad idea. In a Windows system it would be in something like C:\Program Files\NetRexx\, or whatever other directory the user specifies. Mac and *nix are obviously different. And what about all the other less used systems? The translator should be as environment independent as possible - the installer(s) should handle those differences. The installers should be system specific, and NetRexx should be system independent. As I suggested some time ago, I think the emphasis should be on the user experience and what installation process he is used to. A windows user wants the install process to be what he is used to. Mac and *nix users want what they are used to. Trying to provide something different may be universally disliked, unless it is as elementary as I described earlier: 3 buttons on a web page and only a "click to install" instruction. I don't have much experience with Net Beans. How should NetRexx fit with that? As for the dependency resolution, I assume you mean the forward reference problem that currently (as far as I know) is not handled by NetRexx. I provided a general (but ad-hoc) solution for this some time ago in the netrexx3 ant task (as an attachment to issue 14) which allows sets of NetRexx files to be compiled by specifying the compilation order. Patric wants NetRexx to handle this automatically, and I agree that would be best. Unfortunately I suspect that may be a long time in coming. The netrexx3 task needs to be updated to allow and use the -keepasjava option, and I'll get to that when I can. But as far as I know, no one else is using it so that is low priority. It isn't a perfect solution but it does work for arbitrary sets of NetRexx files, not just the translator itself. For Java and NetRexx builds, I believe that Ant is the way of the future and all of the DOS bat/cmd and unix "make" stuff should be abandoned. If and when I have time, I'll tackle the possibility of an Eclipse incremental builder, but that only helps the Eclipse users, not the general population. Bill PS This is offered as food for thought - I don't claim to have all (or even any) of the right answers, although I obviously have opinions :) On 9/27/2011 8:11 PM, Kermit Kiser wrote: > It sounds like you have been thinking along the same lines that I have. If I understand correctly, the idea is that since we need to modify NetRexx to handle the compiler API and possibly other compiler interfaces, we might as well add all of the logic needed to locate the Java compiler to NetRexx itself, rather than bothering the installer with that task. That seems like a good idea to me. If no compiler can be located, we inform the user that he can only interpret programs until he installs a JDK or other Java compiler. Maybe if the compiler locator is a separate class module, the installer could also include it and give the user an option to set an environment variable if that is needed to locate a Java compiler? > > Could you explain the dependency issue? Is it something that can be handled by Ant or such? > > -- Kermit > > > On 9/27/2011 2:30 AM, rvjansen wrote: >> Kermit (and others) >> >> if we think about how translated NetRexx source is to be compiled by a Java compiler, and how the location thereof is sometimes a slight impediment to a quick installation, we should also consider other ways than locating the needed components by the installer, being human or software agent. >> >> I can think of the following strategies. Implementing some of those and choosing a good interface to steer the process is a design process that we should carefully think through: >> >> 1) involving the shell >> a) saving translated source with -keepasjava -replace and then having javac as a step in a build procedure >> b) doing a system.exec of javac or its equivalents >> b1) javac >> b2) eclipse batch (ecj.jar) >> b3) jikes >> b4) janino >> >> 2) calling an API >> a) calling the (now deprecated) sun.tools compiler. This is where we are now. >> b) calling the new 1.6 compiler api >> c) calling a compiler specific api - for the b2-b4 mentioned above >> d) calling a facade pattern like api of our design >> >> Safest would be a 'line-of-defence' approach that gradually falls back from most desirable to to less desirable options, following a classification of the above that needs to be made. Note that if we find a working javac on a system, it knows about its runtime and linking necessities, so we could leverage those if our own (human or software) location ability fails. >> >> An interface for this could consist of an environment variable, options on the translator or in the source, a configuration file with an optional gui, or a completely automatic and built-in set of rules. >> >> Related is the dependency resolution, which is probably the next issue for building larger systems. It would be great if we could combine the two - but the dependency on what the java compiler does should be handled. >> >> This is a straw man, it is meant to be fired upon. >> >> best regards, >> >> René Jansen. >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ -------------------------------------------------------------------- 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/ |
|
|
Bill,
1) future operating environments We can speculate all we want, but the world seems to gradually converge on Unix, and the parts of Java and NetRexx that do not give us grief follow Unix conventions - even on Z we rely on these. When future tablets and phones diverge there is probably work to do. I am not against NetRexx having some knowledge of the outside world where this diverges from Unix conventions. I am in agreemenet with Kermit that this knowledge should be shared by the translator and the installer(s). 2) netrexx taking on installation of compilers, libraries etc Actually, this is not such a bad idea, but it does not need to be done in NetRexx, because maven can do it. I am working on a maven .pom that draws everything in. It could also be the start of a CPAN-like library system. 3) assuming too little competence on the user's part Well, installation issues are real, as demonstrated by list traffic and private emails, and are an impediment to adoption. I myself have lost a lot of time on various configurations that I could have used better. z/Linux had such an odd setup for the IBM J9 VM and compiler with library naming that I had to phone someone in the know. I agree that the installers must look like something the user knows, and fortunately the Java cross-platform installers mostly do. Of course, these need GUI (native or X) so are not universally usable. Again, I agree with Kermit that whatever the translator can solve for the installer, can be left out of the installer. 4) netbeans NetBeans is just like Eclipse, maybe a bit less complex on the user. If we would have the antlr grammar running, we could provide functionality on NetBeans analogous to your Eclipse package, David told me. 5) make make should not be ditched as it provides very quick builds, but more importantly the ability to quickly do stuff like this: NRX_COMPILE_COMMAND = java org.netrexx.process.NetRexxC NRX_COMPILE_FLAGS = -comments -sourcedir -time -keepasjava -replace -format -warnexit0 -compact -nocrossref -nocompile JAVA_COMPILE_COMMAND = java org.eclipse.jdt.internal.compiler.batch.Main JAVA_COMPILE_FLAGS = -warn:-unusedPrivate .nrx.class: $(NRX_COMPILE_COMMAND) $< $(NRX_COMPILE_FLAGS) $(JAVA_COMPILE_COMMAND) $(JAVA_COMPILE_FLAGS) $*.java NRX_SRC := $(wildcard *.nrx) NRX_OBJS := $(NRX_SRC:.nrx=.class) JAVA_SRC := $(wildcard *.java) JAVA_OBJS := $(JAVA_SRC:.java=.class) .SUFFIXES: .nrx .nry .njp .class .skel .xsl .java .pl # # target all compiles the netrexx and java code # all:: $(NRX_OBJS) $(JAVA_OBJS) this was done yesterday night in ten minutes because I decided that I had enough of Windows XP in the workplace and I would like to switch to a Linux machine that did not have a compiler on it - but it does posess a Java runtime. In ant I would have to write an ant task in NetRexx or Java - and of course I would have liked the compiler to just work. But in this case I could just upload the eclipse compiler jar an be on my way, installing nothing. And I am not root on that machine, so it does count. I am happy to see make targets converted to ant, as not everyone is on Unix or has a windows make installed, but I generally think ant wastes my time in setup and execution. But again, I am very happy (and truly grateful) that others pick it up. 6) dependency issue yes. the forward reference issue - correct layering and interfaces are the best solution (these however are beyond a number of people, including architects, that I know or have met on projects), but a solution that NetRexx could offer should not include the specification of build sequence, it should look around for sources named alike to the missing classes - or it should believe a forward declaration, which would speed up compilation a lot; this however has been successfully done in GO and is probably not rexxish at all. Here it is actually a strong point of NetRexx not allowing more class specifications in one source file (although there is an exception for minor classes, which fortunately still can be found that way). best regards, René Jansen. On Wed, 28 Sep 2011 03:07:52 -0400, [hidden email] wrote: > I think it is ill advised to assume that the NetRexx translator > should take > on the task of locating Java compilers. > > Who knows what what operating systems and architectures will be using > NetRexx? Do we really want to take on the job of modifying NetRexx > for > OS2, Android or who knows how many other operating systems or special > Java > environments? What do we do if we find more than one compiler? How > do we > handle changes? Should NetRexx really be searching for the compiler > every > time it compiles? > > I recommend that a more cautious and flexible (and easier) approach > be > taken: For now, simply tell the user that if he wants to compile the > NetRexx source rather than interpret it, he must install the JDK and > set > the JAVA_HOME environment variable to the JDK directory. (A current > common > practice.) That satisfies the Java 1.5 requirement of using the old > interface with minimal changes. > > The user will not be able to compile unless he installs a compiler > anyway > (unless you want NetRexx to take on the job of installing the JDK, > janino, > jikes, etc. as well, or turn NetRexx into a compiler, or include / > integrate janino - all bad ideas in my opinion). Since he installed > the > compiler, he certainly knows where it is, and should be able to set > the > JAVA_HOME environment variable with proper instructions and > documentation. > I believe it is better to ask the user where the compiler is, while > providing a reasonable default, than to assume that it can be easily > found > programmatically. > > Providing installers for the common operating systems (Windows, Mac > and > *nix) to do this should be straight forward. Then provide a NetRexx > option > which specifies that the compiler uses the standard API, and that the > compiler is on the class path. Actually specifying the (standard > API) > compiler path as a NetRexx option or in another environment variable > (as > Rene suggested) is another alternative. > > There is a danger in assuming too little competence on the part of > the user > when he is compiling rather than interpreting. If you want to have > the > installer ask the user where the compiler he wants to use is, or > somehow > try to find it, that is one thing, but I definitely suggest that it > should > NOT be the job of the translator. I think the Unix philosophy of "Do > a > simple, well defined job, and do it well" applies here. > > As for the development of the installer(s), the 3 major system > families > have differences, and clearly the installer(s) must handle them. > Where is > the NetRexx jar to reside? Certainly putting it in one of Java's > folders > is a bad idea. In a Windows system it would be in something like > C:\Program Files\NetRexx\, or whatever other directory the user > specifies. > Mac and *nix are obviously different. And what about all the other > less > used systems? The translator should be as environment independent as > possible - the installer(s) should handle those differences. The > installers should be system specific, and NetRexx should be system > independent. > > As I suggested some time ago, I think the emphasis should be on the > user > experience and what installation process he is used to. A windows > user > wants the install process to be what he is used to. Mac and *nix > users > want what they are used to. Trying to provide something different > may be > universally disliked, unless it is as elementary as I described > earlier: 3 > buttons on a web page and only a "click to install" instruction. > > I don't have much experience with Net Beans. How should NetRexx fit > with > that? > > As for the dependency resolution, I assume you mean the forward > reference > problem that currently (as far as I know) is not handled by NetRexx. > I > provided a general (but ad-hoc) solution for this some time ago in > the > netrexx3 ant task (as an attachment to issue 14) which allows sets of > NetRexx files to be compiled by specifying the compilation order. > Patric > wants NetRexx to handle this automatically, and I agree that would be > best. > Unfortunately I suspect that may be a long time in coming. The > netrexx3 > task needs to be updated to allow and use the -keepasjava option, and > I'll > get to that when I can. But as far as I know, no one else is using > it so > that is low priority. It isn't a perfect solution but it does work > for > arbitrary sets of NetRexx files, not just the translator itself. > > For Java and NetRexx builds, I believe that Ant is the way of the > future > and all of the DOS bat/cmd and unix "make" stuff should be > abandoned. If > and when I have time, I'll tackle the possibility of an Eclipse > incremental > builder, but that only helps the Eclipse users, not the general > population. > > Bill > > PS This is offered as food for thought - I don't claim to have all > (or even > any) of the right answers, although I obviously have opinions :) > > > On 9/27/2011 8:11 PM, Kermit Kiser wrote: >> It sounds like you have been thinking along the same lines that I >> have. > If I understand correctly, the idea is that since we need to modify > NetRexx > to handle the compiler API and possibly other compiler interfaces, we > might > as well add all of the logic needed to locate the Java compiler to > NetRexx > itself, rather than bothering the installer with that task. That > seems like > a good idea to me. If no compiler can be located, we inform the user > that > he can only interpret programs until he installs a JDK or other Java > compiler. Maybe if the compiler locator is a separate class module, > the > installer could also include it and give the user an option to set an > environment variable if that is needed to locate a Java compiler? >> >> Could you explain the dependency issue? Is it something that can be > handled by Ant or such? >> >> -- Kermit >> >> >> On 9/27/2011 2:30 AM, rvjansen wrote: >>> Kermit (and others) >>> >>> if we think about how translated NetRexx source is to be compiled >>> by a > Java compiler, and how the location thereof is sometimes a slight > impediment to a quick installation, we should also consider other > ways than > locating the needed components by the installer, being human or > software > agent. >>> >>> I can think of the following strategies. Implementing some of those >>> and > choosing a good interface to steer the process is a design process > that we > should carefully think through: >>> >>> 1) involving the shell >>> a) saving translated source with -keepasjava -replace and then >>> having > javac as a step in a build procedure >>> b) doing a system.exec of javac or its equivalents >>> b1) javac >>> b2) eclipse batch (ecj.jar) >>> b3) jikes >>> b4) janino >>> >>> 2) calling an API >>> a) calling the (now deprecated) sun.tools compiler. This is where >>> we are > now. >>> b) calling the new 1.6 compiler api >>> c) calling a compiler specific api - for the b2-b4 mentioned above >>> d) calling a facade pattern like api of our design >>> >>> Safest would be a 'line-of-defence' approach that gradually falls >>> back > from most desirable to to less desirable options, following a > classification of the above that needs to be made. Note that if we > find a > working javac on a system, it knows about its runtime and linking > necessities, so we could leverage those if our own (human or > software) > location ability fails. >>> >>> An interface for this could consist of an environment variable, >>> options > on the translator or in the source, a configuration file with an > optional > gui, or a completely automatic and built-in set of rules. >>> >>> Related is the dependency resolution, which is probably the next >>> issue > for building larger systems. It would be great if we could combine > the two > - but the dependency on what the java compiler does should be > handled. >>> >>> This is a straw man, it is meant to be fired upon. >>> >>> best regards, >>> >>> René Jansen. >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -------------------------------------------------------------------- > 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/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by Kermit Kiser
The idea to:
1.) try to locate the compiler, and, when not possible 2.) *interpret* the programs (and inform the user) is *ingenious*. Please let us go this route.... :-) Thomas. ====================================================== Am 28.09.2011 02:11, schrieb Kermit Kiser: > It sounds like you have been thinking along the same lines that I > have. If I understand correctly, the idea is that since we need to > modify NetRexx to handle the compiler API and possibly other compiler > interfaces, we might as well add all of the logic needed to locate the > Java compiler to NetRexx itself, rather than bothering the installer > with that task. That seems like a good idea to me. If no compiler can > be located, we inform the user that he can only interpret programs > until he installs a JDK or other Java compiler. Maybe if the compiler > locator is a separate class module, the installer could also include > it and give the user an option to set an environment variable if that > is needed to locate a Java compiler? > > Could you explain the dependency issue? Is it something that can be > handled by Ant or such? > > -- Kermit > > > On 9/27/2011 2:30 AM, rvjansen wrote: >> Kermit (and others) >> >> if we think about how translated NetRexx source is to be compiled by >> a Java compiler, and how the location thereof is sometimes a slight >> impediment to a quick installation, we should also consider other >> ways than locating the needed components by the installer, being >> human or software agent. >> >> I can think of the following strategies. Implementing some of those >> and choosing a good interface to steer the process is a design >> process that we should carefully think through: >> >> 1) involving the shell >> a) saving translated source with -keepasjava -replace and then having >> javac as a step in a build procedure >> b) doing a system.exec of javac or its equivalents >> b1) javac >> b2) eclipse batch (ecj.jar) >> b3) jikes >> b4) janino >> >> 2) calling an API >> a) calling the (now deprecated) sun.tools compiler. This is where we >> are now. >> b) calling the new 1.6 compiler api >> c) calling a compiler specific api - for the b2-b4 mentioned above >> d) calling a facade pattern like api of our design >> >> Safest would be a 'line-of-defence' approach that gradually falls >> back from most desirable to to less desirable options, following a >> classification of the above that needs to be made. Note that if we >> find a working javac on a system, it knows about its runtime and >> linking necessities, so we could leverage those if our own (human or >> software) location ability fails. >> >> An interface for this could consist of an environment variable, >> options on the translator or in the source, a configuration file with >> an optional gui, or a completely automatic and built-in set of rules. >> >> Related is the dependency resolution, which is probably the next >> issue for building larger systems. It would be great if we could >> combine the two - but the dependency on what the java compiler does >> should be handled. >> >> This is a straw man, it is meant to be fired upon. >> >> best regards, >> >> René Jansen. >> _______________________________________________ >> 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/ > > -- 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 |
|
|
In reply to this post by rvjansen
Rene,
On 9/28/2011 5:58 AM, rvjansen wrote: > Bill, > > 1) future operating environments > > We can speculate all we want, but the world seems to gradually converge on Unix, and the parts of Java and NetRexx that do not give us grief follow Unix conventions - even on Z we rely on these. When future tablets and phones diverge there is probably work to do. I am not against NetRexx having some knowledge of the outside world where this diverges from Unix conventions. I am in agreemenet with Kermit that this knowledge should be shared by the translator and the installer(s). While I have no love for that robber baron Gates, the reality is that windows is not going away. Assuming a Unix convergence is ignoring the 800 pound gorilla. The impending M$ takeover of the PC BIOS may cement windows in the desktop and marginalize Linux there. To ignore the windows platform is a mistake in my opinion, and tying NetRexx to Unix is even more so. I think corrupting the NetRexx translator with OS dependencies is a major mistake, so we can agree to disagree on that one. The whole point of Java is to be system independent. I find it particularly troublesome for my efforts - Eclipse runs on all 3 of the major platforms and requires a degree of system independence in it's applications. Adding Unix or other platform specific code to NetRexx may force me to use a custom (forked) version, and I would prefer to not to have to do that. Possibly a Net Beans solution would be affected as well. I do hope you reconsider this issue. Clearly you fail to see what I think is the wisdom in keeping system dependencies out of the NetRexx translator. > 2) netrexx taking on installation of compilers, libraries etc > > Actually, this is not such a bad idea, but it does not need to be done in NetRexx, because maven can do it. I am working on a maven .pom that draws everything in. It could also be the start of a CPAN-like library system. The issue on this one is priorities - how much effort should be devoted to it, and when? > 3) assuming too little competence on the user's part > > Well, installation issues are real, as demonstrated by list traffic and private emails, and are an impediment to adoption. I myself have lost a lot of time on various configurations that I could have used better. z/Linux had such an odd setup for the IBM J9 VM and compiler with library naming that I had to phone someone in the know. I agree that the installers must look like something the user knows, and fortunately the Java cross-platform installers mostly do. Of course, these need GUI (native or X) so are not universally usable. Again, I agree with Kermit that whatever the translator can solve for the installer, can be left out of the installer. At what expense? The installers should solve system dependencies for the translator, not the other way around. Which is the tail and which is the dog? > 4) netbeans > > NetBeans is just like Eclipse, maybe a bit less complex on the user. If we would have the antlr grammar running, we could provide functionality on NetBeans analogous to your Eclipse package, David told me. Converting my JavaCC grammar to Antlr may be more work than it is worth, but I assume David or whoever is doing Net Beans stuff will download it and evaluate that possibility. Antlr requires the use of a runtime library and I wanted to avoid that. The choice to use the JavaCC / JFlex combination as opposed to Antlr was carefully considered, and in retrospect, I think the correct one for Eclipse. I don't have time to work on Net Beans now, but I'll try to help those who do. > 5) make > > make should not be ditched as it provides very quick builds, but more importantly the ability to quickly do stuff like this: > > NRX_COMPILE_COMMAND = java org.netrexx.process.NetRexxC > NRX_COMPILE_FLAGS = -comments -sourcedir -time -keepasjava -replace -format -warnexit0 -compact -nocrossref -nocompile > > JAVA_COMPILE_COMMAND = java org.eclipse.jdt.internal.compiler.batch.Main > JAVA_COMPILE_FLAGS = -warn:-unusedPrivate > > .nrx.class: > $(NRX_COMPILE_COMMAND) $< $(NRX_COMPILE_FLAGS) > $(JAVA_COMPILE_COMMAND) $(JAVA_COMPILE_FLAGS) $*.java > > NRX_SRC := $(wildcard *.nrx) > NRX_OBJS := $(NRX_SRC:.nrx=.class) > JAVA_SRC := $(wildcard *.java) > JAVA_OBJS := $(JAVA_SRC:.java=.class) > > .SUFFIXES: .nrx .nry .njp .class .skel .xsl .java .pl > > # > # target all compiles the netrexx and java code > # > all:: $(NRX_OBJS) $(JAVA_OBJS) > > this was done yesterday night in ten minutes because I decided that I had machine that did not have a compiler on it - but it does posess a Java runtime. In ant I would have to write an ant task in NetRexx or Java - and of course I would have liked the compiler to just work. But in this case I could just upload the eclipse compiler jar an be on my way, installing nothing. And I am not root on that machine, so it does count. > > I am happy to see make targets converted to ant, as not everyone is on Unix or has a windows make installed, but I generally think ant wastes my time in setup and execution. But again, I am very happy (and truly grateful) that others pick it up. I think pushing make over ant in the Java world is swimming up stream. But it's nice that it works well for you. No doubt there are those who are as comfortable with ant as you are with make. Good luck with Maven. > > 6) dependency issue > > yes. the forward reference issue - correct layering and interfaces are the best solution (these however are beyond a number of people, including architects, that I know or have met on projects), but a solution that NetRexx could offer should not include the specification of build sequence, it should look around for sources named alike to the missing classes - or it should believe a forward declaration, which would speed up compilation a lot; this however has been successfully done in GO and is probably not rexxish at all. Here it is actually a strong point of NetRexx not allowing more class specifications in one source file (although there is an exception for minor classes, which fortunately still can be found that way). I think this is a case of "The perfect is the enemy of the good". Saying "No loaf is better than half" may not be the answer that a starving programmer wants to hear. Personally I don't care if anyone uses my ant task since I wrote it to solve my own problem, not the worlds. That's why I didn't bother with sourceforge or kenai. It is a makeshift solution at best, but it is an available solution, not a virtual "should". "A bird in the hand...". As I said, the best solution may be a long time coming. Is anyone actually working on it? Is there even a conceptual design? By the way, isn't "correct layering" just another way of specifying the build order? Bill > > best regards, > > René Jansen. > > On Wed, 28 Sep 2011 03:07:52 -0400, [hidden email] wrote: >> I think it is ill advised to assume that the NetRexx translator should take >> on the task of locating Java compilers. >> >> Who knows what what operating systems and architectures will be using >> NetRexx? Do we really want to take on the job of modifying NetRexx for >> OS2, Android or who knows how many other operating systems or special Java >> environments? What do we do if we find more than one compiler? How do we >> handle changes? Should NetRexx really be searching for the compiler every >> time it compiles? >> >> I recommend that a more cautious and flexible (and easier) approach be >> taken: For now, simply tell the user that if he wants to compile the >> NetRexx source rather than interpret it, he must install the JDK and set >> the JAVA_HOME environment variable to the JDK directory. (A current common >> practice.) That satisfies the Java 1.5 requirement of using the old >> interface with minimal changes. >> >> The user will not be able to compile unless he installs a compiler anyway >> (unless you want NetRexx to take on the job of installing the JDK, janino, >> jikes, etc. as well, or turn NetRexx into a compiler, or include / >> integrate janino - all bad ideas in my opinion). Since he installed the >> compiler, he certainly knows where it is, and should be able to set the >> JAVA_HOME environment variable with proper instructions and documentation. >> I believe it is better to ask the user where the compiler is, while >> providing a reasonable default, than to assume that it can be easily found >> programmatically. >> >> Providing installers for the common operating systems (Windows, Mac and >> *nix) to do this should be straight forward. Then provide a NetRexx option >> which specifies that the compiler uses the standard API, and that the >> compiler is on the class path. Actually specifying the (standard API) >> compiler path as a NetRexx option or in another environment variable (as >> Rene suggested) is another alternative. >> >> There is a danger in assuming too little competence on the part of the user >> when he is compiling rather than interpreting. If you want to have the >> installer ask the user where the compiler he wants to use is, or somehow >> try to find it, that is one thing, but I definitely suggest that it should >> NOT be the job of the translator. I think the Unix philosophy of "Do a >> simple, well defined job, and do it well" applies here. >> >> As for the development of the installer(s), the 3 major system families >> have differences, and clearly the installer(s) must handle them. Where is >> the NetRexx jar to reside? Certainly putting it in one of Java's folders >> is a bad idea. In a Windows system it would be in something like >> C:\Program Files\NetRexx\, or whatever other directory the user specifies. >> Mac and *nix are obviously different. And what about all the other less >> used systems? The translator should be as environment independent as >> possible - the installer(s) should handle those differences. The >> installers should be system specific, and NetRexx should be system >> independent. >> >> As I suggested some time ago, I think the emphasis should be on the user >> experience and what installation process he is used to. A windows user >> wants the install process to be what he is used to. Mac and *nix users >> want what they are used to. Trying to provide something different may be >> universally disliked, unless it is as elementary as I described earlier: >> buttons on a web page and only a "click to install" instruction. >> >> I don't have much experience with Net Beans. How should NetRexx fit with >> that? >> >> As for the dependency resolution, I assume you mean the forward reference >> problem that currently (as far as I know) is not handled by NetRexx. I >> provided a general (but ad-hoc) solution for this some time ago in the >> netrexx3 ant task (as an attachment to issue 14) which allows sets of >> NetRexx files to be compiled by specifying the compilation order. Patric >> wants NetRexx to handle this automatically, and I agree that would be >> Unfortunately I suspect that may be a long time in coming. The netrexx3 >> task needs to be updated to allow and use the -keepasjava option, and I'll >> get to that when I can. But as far as I know, no one else is using it so >> that is low priority. It isn't a perfect solution but it does work for >> arbitrary sets of NetRexx files, not just the translator itself. >> >> For Java and NetRexx builds, I believe that Ant is the way of the future >> and all of the DOS bat/cmd and unix "make" stuff should be abandoned. If >> and when I have time, I'll tackle the possibility of an Eclipse incremental >> builder, but that only helps the Eclipse users, not the general population. >> >> Bill >> >> PS This is offered as food for thought - I don't claim to have all (or even >> any) of the right answers, although I obviously have opinions :) >> >> >> On 9/27/2011 8:11 PM, Kermit Kiser wrote: >>> It sounds like you have been thinking along the same lines that I have. >> If I understand correctly, the idea is that since we need to modify NetRexx >> to handle the compiler API and possibly other compiler interfaces, we might >> as well add all of the logic needed to locate the Java compiler to NetRexx >> itself, rather than bothering the installer with that task. That seems like >> a good idea to me. If no compiler can be located, we inform the user that >> he can only interpret programs until he installs a JDK or other Java >> compiler. Maybe if the compiler locator is a separate class module, the >> installer could also include it and give the user an option to set an >> environment variable if that is needed to locate a Java compiler? >>> >>> Could you explain the dependency issue? Is it something that can be >> handled by Ant or such? >>> >>> -- Kermit >>> >>> >>> On 9/27/2011 2:30 AM, rvjansen wrote: >>>> Kermit (and others) >>>> >>>> if we think about how translated NetRexx source is to be compiled by a >> Java compiler, and how the location thereof is sometimes a slight >> impediment to a quick installation, we should also consider other ways >> locating the needed components by the installer, being human or software >> agent. >>>> >>>> I can think of the following strategies. Implementing some of those and >> choosing a good interface to steer the process is a design process that we >> should carefully think through: >>>> >>>> 1) involving the shell >>>> a) saving translated source with -keepasjava -replace and then having >> javac as a step in a build procedure >>>> b) doing a system.exec of javac or its equivalents >>>> b1) javac >>>> b2) eclipse batch (ecj.jar) >>>> b3) jikes >>>> b4) janino >>>> >>>> 2) calling an API >>>> a) calling the (now deprecated) sun.tools compiler. This is where we >> now. >>>> b) calling the new 1.6 compiler api >>>> c) calling a compiler specific api - for the b2-b4 mentioned above >>>> d) calling a facade pattern like api of our design >>>> >>>> Safest would be a 'line-of-defence' approach that gradually falls back >> from most desirable to to less desirable options, following a >> classification of the above that needs to be made. Note that if we find a >> working javac on a system, it knows about its runtime and linking >> necessities, so we could leverage those if our own (human or software) >> location ability fails. >>>> >>>> An interface for this could consist of an environment variable, >> on the translator or in the source, a configuration file with an optional >> gui, or a completely automatic and built-in set of rules. >>>> >>>> Related is the dependency resolution, which is probably the next issue >> for building larger systems. It would be great if we could combine the two >> - but the dependency on what the java compiler does should be handled. >>>> >>>> This is a straw man, it is meant to be fired upon. >>>> >>>> best regards, >>>> >>>> René Jansen. >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> -------------------------------------------------------------------- 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/ |
|
|
Good effort!
I do *hope* we will keep in touch ... Thomas. =========================================== Am 28.09.2011 18:35, schrieb [hidden email]: > Rene, > > On 9/28/2011 5:58 AM, rvjansen wrote: >> Bill, >> >> 1) future operating environments >> >> We can speculate all we want, but the world seems to gradually converge > on Unix, and the parts of Java and NetRexx that do not give us grief follow > Unix conventions - even on Z we rely on these. When future tablets and > phones diverge there is probably work to do. I am not against NetRexx > having some knowledge of the outside world where this diverges from Unix > conventions. I am in agreemenet with Kermit that this knowledge should be > shared by the translator and the installer(s). > > While I have no love for that robber baron Gates, the reality is that > windows is not going away. Assuming a Unix convergence is ignoring the 800 > pound gorilla. The impending M$ takeover of the PC BIOS may cement windows > in the desktop and marginalize Linux there. To ignore the windows platform > is a mistake in my opinion, and tying NetRexx to Unix is even more so. > > I think corrupting the NetRexx translator with OS dependencies is a major > mistake, so we can agree to disagree on that one. The whole point of Java > is to be system independent. > > I find it particularly troublesome for my efforts - Eclipse runs on all 3 > of the major platforms and requires a degree of system independence in it's > applications. Adding Unix or other platform specific code to NetRexx may > force me to use a custom (forked) version, and I would prefer to not to > have to do that. Possibly a Net Beans solution would be affected as well. > I do hope you reconsider this issue. Clearly you fail to see what I think > is the wisdom in keeping system dependencies out of the NetRexx translator. > >> 2) netrexx taking on installation of compilers, libraries etc >> >> Actually, this is not such a bad idea, but it does not need to be done in > NetRexx, because maven can do it. I am working on a maven .pom that draws > everything in. It could also be the start of a CPAN-like library system. > > The issue on this one is priorities - how much effort should be devoted to > it, and when? > >> 3) assuming too little competence on the user's part >> >> Well, installation issues are real, as demonstrated by list traffic and > private emails, and are an impediment to adoption. I myself have lost a lot > of time on various configurations that I could have used better. z/Linux > had such an odd setup for the IBM J9 VM and compiler with library naming > that I had to phone someone in the know. I agree that the installers must > look like something the user knows, and fortunately the Java cross-platform > installers mostly do. Of course, these need GUI (native or X) so are not > universally usable. Again, I agree with Kermit that whatever the translator > can solve for the installer, can be left out of the installer. > > At what expense? The installers should solve system dependencies for the > translator, not the other way around. Which is the tail and which is the > dog? > >> 4) netbeans >> >> NetBeans is just like Eclipse, maybe a bit less complex on the user. If > we would have the antlr grammar running, we could provide functionality on > NetBeans analogous to your Eclipse package, David told me. > > Converting my JavaCC grammar to Antlr may be more work than it is worth, > but I assume David or whoever is doing Net Beans stuff will download it and > evaluate that possibility. Antlr requires the use of a runtime library and > I wanted to avoid that. The choice to use the JavaCC / JFlex combination > as opposed to Antlr was carefully considered, and in retrospect, I think > the correct one for Eclipse. I don't have time to work on Net Beans now, > but I'll try to help those who do. > >> 5) make >> >> make should not be ditched as it provides very quick builds, but more > importantly the ability to quickly do stuff like this: >> NRX_COMPILE_COMMAND = java org.netrexx.process.NetRexxC >> NRX_COMPILE_FLAGS = -comments -sourcedir -time -keepasjava -replace > -format -warnexit0 -compact -nocrossref -nocompile >> JAVA_COMPILE_COMMAND = java org.eclipse.jdt.internal.compiler.batch.Main >> JAVA_COMPILE_FLAGS = -warn:-unusedPrivate >> >> .nrx.class: >> $(NRX_COMPILE_COMMAND) $< $(NRX_COMPILE_FLAGS) >> $(JAVA_COMPILE_COMMAND) $(JAVA_COMPILE_FLAGS) $*.java >> >> NRX_SRC := $(wildcard *.nrx) >> NRX_OBJS := $(NRX_SRC:.nrx=.class) >> JAVA_SRC := $(wildcard *.java) >> JAVA_OBJS := $(JAVA_SRC:.java=.class) >> >> .SUFFIXES: .nrx .nry .njp .class .skel .xsl .java .pl >> >> # >> # target all compiles the netrexx and java code >> # >> all:: $(NRX_OBJS) $(JAVA_OBJS) >> >> this was done yesterday night in ten minutes because I decided that I had > enough of Windows XP in the workplace and I would like to switch to a Linux > machine that did not have a compiler on it - but it does posess a Java > runtime. In ant I would have to write an ant task in NetRexx or Java - and > of course I would have liked the compiler to just work. But in this case I > could just upload the eclipse compiler jar an be on my way, installing > nothing. And I am not root on that machine, so it does count. >> I am happy to see make targets converted to ant, as not everyone is on > Unix or has a windows make installed, but I generally think ant wastes my > time in setup and execution. But again, I am very happy (and truly > grateful) that others pick it up. > > I think pushing make over ant in the Java world is swimming up stream. But > it's nice that it works well for you. No doubt there are those who are as > comfortable with ant as you are with make. Good luck with Maven. > >> 6) dependency issue >> >> yes. the forward reference issue - correct layering and interfaces are > the best solution (these however are beyond a number of people, including > architects, that I know or have met on projects), but a solution that > NetRexx could offer should not include the specification of build sequence, > it should look around for sources named alike to the missing classes - or > it should believe a forward declaration, which would speed up compilation a > lot; this however has been successfully done in GO and is probably not > rexxish at all. Here it is actually a strong point of NetRexx not allowing > more class specifications in one source file (although there is an > exception for minor classes, which fortunately still can be found that > way). > > I think this is a case of "The perfect is the enemy of the good". Saying > "No loaf is better than half" may not be the answer that a starving > programmer wants to hear. Personally I don't care if anyone uses my ant > task since I wrote it to solve my own problem, not the worlds. That's why > I didn't bother with sourceforge or kenai. It is a makeshift solution at > best, but it is an available solution, not a virtual "should". "A bird in > the hand...". As I said, the best solution may be a long time coming. Is > anyone actually working on it? Is there even a conceptual design? > > By the way, isn't "correct layering" just another way of specifying the > build order? > > Bill > >> best regards, >> >> René Jansen. >> >> On Wed, 28 Sep 2011 03:07:52 -0400, [hidden email] wrote: >>> I think it is ill advised to assume that the NetRexx translator should > take >>> on the task of locating Java compilers. >>> >>> Who knows what what operating systems and architectures will be using >>> NetRexx? Do we really want to take on the job of modifying NetRexx for >>> OS2, Android or who knows how many other operating systems or special > Java >>> environments? What do we do if we find more than one compiler? How do > we >>> handle changes? Should NetRexx really be searching for the compiler > every >>> time it compiles? >>> >>> I recommend that a more cautious and flexible (and easier) approach be >>> taken: For now, simply tell the user that if he wants to compile the >>> NetRexx source rather than interpret it, he must install the JDK and set >>> the JAVA_HOME environment variable to the JDK directory. (A current > common >>> practice.) That satisfies the Java 1.5 requirement of using the old >>> interface with minimal changes. >>> >>> The user will not be able to compile unless he installs a compiler anyway >>> (unless you want NetRexx to take on the job of installing the JDK, > janino, >>> jikes, etc. as well, or turn NetRexx into a compiler, or include / >>> integrate janino - all bad ideas in my opinion). Since he installed the >>> compiler, he certainly knows where it is, and should be able to set the >>> JAVA_HOME environment variable with proper instructions and > documentation. >>> I believe it is better to ask the user where the compiler is, while >>> providing a reasonable default, than to assume that it can be easily > found >>> programmatically. >>> >>> Providing installers for the common operating systems (Windows, Mac and >>> *nix) to do this should be straight forward. Then provide a NetRexx > option >>> which specifies that the compiler uses the standard API, and that the >>> compiler is on the class path. Actually specifying the (standard API) >>> compiler path as a NetRexx option or in another environment variable (as >>> Rene suggested) is another alternative. >>> >>> There is a danger in assuming too little competence on the part of the > user >>> when he is compiling rather than interpreting. If you want to have the >>> installer ask the user where the compiler he wants to use is, or somehow >>> try to find it, that is one thing, but I definitely suggest that it > should >>> NOT be the job of the translator. I think the Unix philosophy of "Do a >>> simple, well defined job, and do it well" applies here. >>> >>> As for the development of the installer(s), the 3 major system families >>> have differences, and clearly the installer(s) must handle them. Where > is >>> the NetRexx jar to reside? Certainly putting it in one of Java's folders >>> is a bad idea. In a Windows system it would be in something like >>> C:\Program Files\NetRexx\, or whatever other directory the user > specifies. >>> Mac and *nix are obviously different. And what about all the other less >>> used systems? The translator should be as environment independent as >>> possible - the installer(s) should handle those differences. The >>> installers should be system specific, and NetRexx should be system >>> independent. >>> >>> As I suggested some time ago, I think the emphasis should be on the user >>> experience and what installation process he is used to. A windows user >>> wants the install process to be what he is used to. Mac and *nix users >>> want what they are used to. Trying to provide something different may be >>> universally disliked, unless it is as elementary as I described earlier: > 3 >>> buttons on a web page and only a "click to install" instruction. >>> >>> I don't have much experience with Net Beans. How should NetRexx fit with >>> that? >>> >>> As for the dependency resolution, I assume you mean the forward reference >>> problem that currently (as far as I know) is not handled by NetRexx. I >>> provided a general (but ad-hoc) solution for this some time ago in the >>> netrexx3 ant task (as an attachment to issue 14) which allows sets of >>> NetRexx files to be compiled by specifying the compilation order. Patric >>> wants NetRexx to handle this automatically, and I agree that would be > best. >>> Unfortunately I suspect that may be a long time in coming. The netrexx3 >>> task needs to be updated to allow and use the -keepasjava option, and > I'll >>> get to that when I can. But as far as I know, no one else is using it so >>> that is low priority. It isn't a perfect solution but it does work for >>> arbitrary sets of NetRexx files, not just the translator itself. >>> >>> For Java and NetRexx builds, I believe that Ant is the way of the future >>> and all of the DOS bat/cmd and unix "make" stuff should be abandoned. > If >>> and when I have time, I'll tackle the possibility of an Eclipse > incremental >>> builder, but that only helps the Eclipse users, not the general > population. >>> Bill >>> >>> PS This is offered as food for thought - I don't claim to have all (or > even >>> any) of the right answers, although I obviously have opinions :) >>> >>> >>> On 9/27/2011 8:11 PM, Kermit Kiser wrote: >>>> It sounds like you have been thinking along the same lines that I have. >>> If I understand correctly, the idea is that since we need to modify > NetRexx >>> to handle the compiler API and possibly other compiler interfaces, we > might >>> as well add all of the logic needed to locate the Java compiler to > NetRexx >>> itself, rather than bothering the installer with that task. That seems > like >>> a good idea to me. If no compiler can be located, we inform the user that >>> he can only interpret programs until he installs a JDK or other Java >>> compiler. Maybe if the compiler locator is a separate class module, the >>> installer could also include it and give the user an option to set an >>> environment variable if that is needed to locate a Java compiler? >>>> Could you explain the dependency issue? Is it something that can be >>> handled by Ant or such? >>>> -- Kermit >>>> >>>> >>>> On 9/27/2011 2:30 AM, rvjansen wrote: >>>>> Kermit (and others) >>>>> >>>>> if we think about how translated NetRexx source is to be compiled by a >>> Java compiler, and how the location thereof is sometimes a slight >>> impediment to a quick installation, we should also consider other ways > than >>> locating the needed components by the installer, being human or software >>> agent. >>>>> I can think of the following strategies. Implementing some of those > and >>> choosing a good interface to steer the process is a design process that > we >>> should carefully think through: >>>>> 1) involving the shell >>>>> a) saving translated source with -keepasjava -replace and then having >>> javac as a step in a build procedure >>>>> b) doing a system.exec of javac or its equivalents >>>>> b1) javac >>>>> b2) eclipse batch (ecj.jar) >>>>> b3) jikes >>>>> b4) janino >>>>> >>>>> 2) calling an API >>>>> a) calling the (now deprecated) sun.tools compiler. This is where we > are >>> now. >>>>> b) calling the new 1.6 compiler api >>>>> c) calling a compiler specific api - for the b2-b4 mentioned above >>>>> d) calling a facade pattern like api of our design >>>>> >>>>> Safest would be a 'line-of-defence' approach that gradually falls back >>> from most desirable to to less desirable options, following a >>> classification of the above that needs to be made. Note that if we find a >>> working javac on a system, it knows about its runtime and linking >>> necessities, so we could leverage those if our own (human or software) >>> location ability fails. >>>>> An interface for this could consist of an environment variable, > options >>> on the translator or in the source, a configuration file with an optional >>> gui, or a completely automatic and built-in set of rules. >>>>> Related is the dependency resolution, which is probably the next issue >>> for building larger systems. It would be great if we could combine the > two >>> - but the dependency on what the java compiler does should be handled. >>>>> This is a straw man, it is meant to be fired upon. >>>>> >>>>> best regards, >>>>> >>>>> René Jansen. >>>>> _______________________________________________ >>>>> Ibm-netrexx mailing list >>>>> [hidden email] >>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > -------------------------------------------------------------------- > 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/ > > -- 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 |
Re: design straw man for java compilation by NetRexx
|
|
In reply to this post by billfen
Bill -
I am not sure that I understand all of your concerns but I want to assure you of one thing: No matter what changes we make to NetRexx, things that work now will still work. That is not just my goal but the whole team's goal I think. I am including access to and control of the Java compilers used by NetRexx in that goal. (In my philosophy which seems to differ from most engineers, especially automotive engineers, there is no conflict between automation and precise manual control of processes.) That said, I am definitely looking into incorporating use of the Java compiler API into NetRexx. Although my main interest in that API is in being able to pass NetRexx code output to the Java compiler without having to create .java files, there is another consequence. Here is what the documentation for that API says: "This framework allows clients of the framework to locate and run compilers from programs." In other words, the official approach to programmatic access to Java compilers includes "locating" them as well as invoking them. Any currently developed Java compiler is going to support this approach eventually if it does not already. That means we WILL be in the business of dynamically locating and choosing a compiler. Ant tasks already have support for choosing a Java compiler so that idea is not something new. Whatever we do, it will increase, not decrease, the flexibility of NetRexx. The current compiler APIs will still work although there may be new options to prioritize compiler choice if multiple compilers are found. Granted I am assuming that I get time to develop these enhancements, but I think any other developer would follow the same approach. As for supporting different platforms, only the primary platforms will probably be supported initially by NetRexx and it's installers with others added later as needed and time allows. I can code and test for Windows and Linux. Others will have to help for platforms I don't have access to like Mac or Z. Again, we will make sure that platforms and things that now work do not get broken! I do suggest that you not work further on your Java coded Ant task because we now have a NetRexx coded version in the repository and I have been working on adding your features to that version. However I probably will not include the dependency subset code unless you can show me a distinct advantage over simply invoking the task two or three times from the Ant target like we currently do for the NetRexx build. Either way, the Ant task needs to know about and handle the dependencies currently. I agree with you that Ant is the best way to handle Java related development but some people seem to be more familiar with the old "make" system. I confess that even though I was once a Unix system admin who had to deal with those things, I can't make sense out of "make"! (yes, that was intentional. ;-) -- Kermit On 9/28/2011 12:07 AM, [hidden email] wrote: > I think it is ill advised to assume that the NetRexx translator should take > on the task of locating Java compilers. > > Who knows what what operating systems and architectures will be using > NetRexx? Do we really want to take on the job of modifying NetRexx for > OS2, Android or who knows how many other operating systems or special Java > environments? What do we do if we find more than one compiler? How do we > handle changes? Should NetRexx really be searching for the compiler every > time it compiles? > > I recommend that a more cautious and flexible (and easier) approach be > taken: For now, simply tell the user that if he wants to compile the > NetRexx source rather than interpret it, he must install the JDK and set > the JAVA_HOME environment variable to the JDK directory. (A current common > practice.) That satisfies the Java 1.5 requirement of using the old > interface with minimal changes. > > The user will not be able to compile unless he installs a compiler anyway > (unless you want NetRexx to take on the job of installing the JDK, janino, > jikes, etc. as well, or turn NetRexx into a compiler, or include / > integrate janino - all bad ideas in my opinion). Since he installed the > compiler, he certainly knows where it is, and should be able to set the > JAVA_HOME environment variable with proper instructions and documentation. > I believe it is better to ask the user where the compiler is, while > providing a reasonable default, than to assume that it can be easily found > programmatically. > > Providing installers for the common operating systems (Windows, Mac and > *nix) to do this should be straight forward. Then provide a NetRexx option > which specifies that the compiler uses the standard API, and that the > compiler is on the class path. Actually specifying the (standard API) > compiler path as a NetRexx option or in another environment variable (as > Rene suggested) is another alternative. > > There is a danger in assuming too little competence on the part of the user > when he is compiling rather than interpreting. If you want to have the > installer ask the user where the compiler he wants to use is, or somehow > try to find it, that is one thing, but I definitely suggest that it should > NOT be the job of the translator. I think the Unix philosophy of "Do a > simple, well defined job, and do it well" applies here. > > As for the development of the installer(s), the 3 major system families > have differences, and clearly the installer(s) must handle them. Where is > the NetRexx jar to reside? Certainly putting it in one of Java's folders > is a bad idea. In a Windows system it would be in something like > C:\Program Files\NetRexx\, or whatever other directory the user specifies. > Mac and *nix are obviously different. And what about all the other less > used systems? The translator should be as environment independent as > possible - the installer(s) should handle those differences. The > installers should be system specific, and NetRexx should be system > independent. > > As I suggested some time ago, I think the emphasis should be on the user > experience and what installation process he is used to. A windows user > wants the install process to be what he is used to. Mac and *nix users > want what they are used to. Trying to provide something different may be > universally disliked, unless it is as elementary as I described earlier: 3 > buttons on a web page and only a "click to install" instruction. > > I don't have much experience with Net Beans. How should NetRexx fit with > that? > > As for the dependency resolution, I assume you mean the forward reference > problem that currently (as far as I know) is not handled by NetRexx. I > provided a general (but ad-hoc) solution for this some time ago in the > netrexx3 ant task (as an attachment to issue 14) which allows sets of > NetRexx files to be compiled by specifying the compilation order. Patric > wants NetRexx to handle this automatically, and I agree that would be best. > Unfortunately I suspect that may be a long time in coming. The netrexx3 > task needs to be updated to allow and use the -keepasjava option, and I'll > get to that when I can. But as far as I know, no one else is using it so > that is low priority. It isn't a perfect solution but it does work for > arbitrary sets of NetRexx files, not just the translator itself. > > For Java and NetRexx builds, I believe that Ant is the way of the future > and all of the DOS bat/cmd and unix "make" stuff should be abandoned. If > and when I have time, I'll tackle the possibility of an Eclipse incremental > builder, but that only helps the Eclipse users, not the general population. > > Bill > > PS This is offered as food for thought - I don't claim to have all (or even > any) of the right answers, although I obviously have opinions :) > > > On 9/27/2011 8:11 PM, Kermit Kiser wrote: >> It sounds like you have been thinking along the same lines that I have. > If I understand correctly, the idea is that since we need to modify NetRexx > to handle the compiler API and possibly other compiler interfaces, we might > as well add all of the logic needed to locate the Java compiler to NetRexx > itself, rather than bothering the installer with that task. That seems like > a good idea to me. If no compiler can be located, we inform the user that > he can only interpret programs until he installs a JDK or other Java > compiler. Maybe if the compiler locator is a separate class module, the > installer could also include it and give the user an option to set an > environment variable if that is needed to locate a Java compiler? >> Could you explain the dependency issue? Is it something that can be > handled by Ant or such? >> -- Kermit >> >> >> On 9/27/2011 2:30 AM, rvjansen wrote: >>> Kermit (and others) >>> >>> if we think about how translated NetRexx source is to be compiled by a > Java compiler, and how the location thereof is sometimes a slight > impediment to a quick installation, we should also consider other ways than > locating the needed components by the installer, being human or software > agent. >>> I can think of the following strategies. Implementing some of those and > choosing a good interface to steer the process is a design process that we > should carefully think through: >>> 1) involving the shell >>> a) saving translated source with -keepasjava -replace and then having > javac as a step in a build procedure >>> b) doing a system.exec of javac or its equivalents >>> b1) javac >>> b2) eclipse batch (ecj.jar) >>> b3) jikes >>> b4) janino >>> >>> 2) calling an API >>> a) calling the (now deprecated) sun.tools compiler. This is where we are > now. >>> b) calling the new 1.6 compiler api >>> c) calling a compiler specific api - for the b2-b4 mentioned above >>> d) calling a facade pattern like api of our design >>> >>> Safest would be a 'line-of-defence' approach that gradually falls back > from most desirable to to less desirable options, following a > classification of the above that needs to be made. Note that if we find a > working javac on a system, it knows about its runtime and linking > necessities, so we could leverage those if our own (human or software) > location ability fails. >>> An interface for this could consist of an environment variable, options > on the translator or in the source, a configuration file with an optional > gui, or a completely automatic and built-in set of rules. >>> Related is the dependency resolution, which is probably the next issue > for building larger systems. It would be great if we could combine the two > - but the dependency on what the java compiler does should be handled. >>> This is a straw man, it is meant to be fired upon. >>> >>> best regards, >>> >>> René Jansen. >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > -------------------------------------------------------------------- > 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/ > > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: design straw man for java compilation by NetRexx
|
|
In reply to this post by billfen
Bill said:
> .... The impending M$ takeover of the PC BIOS may cement windows in the desktop and marginalize Linux there... Did I miss an announcement? What is this about? > ... The installers should solve system dependencies for the translator, not the other way around. Which is the tail and which is the dog? Surely part of the issue is that installation is a one-time process. But no-one's environment is static: One can guarantee that, if user X has just installed NetRexx, then before too long they'll be installing something else & possibly another java update-or-whatever. I was with Bill initially, but I can see the sense Rene's approach. > ... Bill Peter Sharp Ballarat Australia _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: design straw man for java compilation by NetRexx
|
|
In reply to this post by Kermit Kiser
Hi Kermit,
These are weighty issues indeed. I have no position on the matters being discussed (other than the one below) except to urge caution. Let's not fall in love with any particular approach until it has been thoroughly aired (of course a "pilot study" may well be in order to prove concepts). One small point. you remark "As for supporting different platforms, only the primary platforms will
probably be supported initially by NetRexx and it's installers with
others added later as needed and time allows." It seems to me that the moment you support a particular platform, you have contracted to support it indefinitely and in a timely manner, otherwise you face the possibility of unhappy users who will bad mouth NetRexx, and with some justice. In that vein, I am distrustful of jEdit plugins because their updating is often tardy (or nonexistent) after jEdit version changes, and have just now aired that bit of dirty linen before potential jEdit users.I hope our working assumption is that NetRexx users are not hobbyists. Such people will not take kindly to unresponsive maintenance. I think this argues for a cautious, conservative, minimalist approach. Regards, George On Wed, Sep 28, 2011 at 3:22 PM, Kermit Kiser <[hidden email]> wrote: Bill - _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |