NetRexx 3.03RC1
Locked
 
|
Dear NetRexx users,
It has been 5 days since 3.03RC1 became available. With blocking issues absent, I am planning to release RC1 unchanged as 3.03 in about two days. Please let me know if anything needs to change before we do that. best regards, René Jansen. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
René --
I need a little more time. I would have responded sooner but my eyes were too blurry after I finished my initial testing at 2AM this morning! I have only run a few test cases so far but I do not anticipate problems in that area as changes are minimal there. I have been mostly investigating the repository and the build environment and I have some issues and questions for you: 1) The current repository content will only build with Java8, not Java7 or Java6 due to some new Java 8 specific code introduced into Rexx.nrx and RexxComparator.nrx. I could not understand your comments about why the code was changed and there should be no requirement for those changes as far as I can tell. While researching this and modifying the build.xml to allow specification of the source/target options, I discovered early this morning the likely cause of the problems that I suspect you encountered: The Eclipse compiler included in the distribution is a broken early development build! As soon as I replaced it with the current Eclipse release version of the compiler (4.3.2) or even the newer 4.4RC1 version, the build problems while using ECJ vanished and the code changes were not needed. There were no problems when using the regular (Oracle) Java compiler. That should have alerted us to the broken ECJ compiler but it took a while to get to that point! Have I correctly understood this issue? 2) I did not understand why the new streamdemo.nrx example in the repository added overrides for the default methods since it runs fine for me without them, but now I suspect that the cause was the same as above. Do you agree with this assessment? 3) The Ant build file needs to be updated to handle the target option for Java compilations so that builds are not dependent on Java levels. I have no way to run the "makefile" (which I am sure does about the same thing as the build.bat/build.sh scripts we provide) and it does not seem like a good way to handle the current problems. 4) I thought we had agreed that the repository tags would reflect unchanging snapshots of the code base as per standard SVN usage, yet the tag we created to snapshot the 3.02GA release from last year has been altered. Maintenance changes to 3.02 were intended to be directed to the 3.02 branch as we had discussed previously. Do you recall this? 5) I recommend that the new translator logic diagrams document be excluded from the user distribution and only included in source distributions to save space and avoid confusing end users which don't need it. 6) Some of the documentation seems to be out of date, for example changes to the Eclipse compiler are not reflected. If there are no objections, I will update the repository soon to correct the above issues. The specific changes will be these: 1) "build.xml" will be updated to allow source/target specification for Javac or ECJ compiles and to include the new NetRexxF.jar in the build. (I am not sure where that module is documented). The latest Eclipse batch compiler (ecj-4.4RC1.jar) will be added to replace the broken one. This will move to the ant directory in the repository as required by the Eclipse Ant compiler adapter API. 2) Extraneous Java 8 code will be removed from Rexx.nrx, RexxComparator.nrx, and streamdemo.nrx source files. 3) Repository tag 3.02GA will be reverted to the original state. 4) I don't know how to directly update the documents, so I will post individual change requests for outdated sections I find. -- Kermit On 5/20/2014 10:20 AM, René Jansen wrote: > Dear NetRexx users, > > It has been 5 days since 3.03RC1 became available. With blocking issues absent, I am planning to release RC1 unchanged as 3.03 in about two days. > > Please let me know if anything needs to change before we do that. > > 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/ |
|
|
Hi Kermit,
good that you caught this. I had picked up the compiler from a link on this list, mainly because eclipse cannot seem to stop rearranging their websites continually and I lacked the time, until now, to go hunt around for it again. I did not find that it was broken, because it worked for me all the time *until I removed that hardcoded reference to classes.jar on MacOSX*. As you might know the -until recently- dependable conventions where to find things in Java have changed now that Oracle maintains the installers for this platform. I saw this problem of having to implement interfaces first on the windows builds, and again after linking to the right JVM8 jars on the Mac, at no time I suspected ecj, though I was rather disgruntled towards Oracle that seemed to have broken so many things in Java 8 in a late stage. I should have known better, but google searches indicated that other people had encountered this problem. Until now I was sure to have seen the same issues in the javac build. 1) it seems that we need to vet the ecj release also before pulling it into our repository. Otherwise, I would not have any problem to have the build Java 8 only, as long as it runs on 6 and greater. 2) I agree, must be the same cause 3) The solution of the separate build for the packaging in the makefile was born out of necessity because the ant build does not support it. I might move to Cmake as ooRexx is doing the same, but it would be great if the ant build can do everything. As you know, I see the need to write classes for every change to the ant build as a definite downside. 4) Yes, this was not intended and came about through time constraints - I think, because I do not remember it well. 5) That is OK with me, I'll cut them out of the user package 6) I'll have a look at those, and any other suggestions people will come up with Go ahead with the repository updates. This means we will have to have a Release Candidate 2 before we can release. Maybe we want to keep the signatures in the Rexx class in a later release so we can implement them to fit with general Java usage. Did you have any further look at the windows issue with the RxVarpool/UTF8 fix? Now that we are postponing, and I am hopefully running with correct compiler and JVM jars again, I will also have a look at what happens there. best regards, René. On 20 mei 2014, at 15:12, Kermit Kiser <[hidden email]> wrote: > René -- > > I need a little more time. I would have responded sooner but my eyes were too blurry after I finished my initial testing at 2AM this morning! > > I have only run a few test cases so far but I do not anticipate problems in that area as changes are minimal there. I have been mostly investigating the repository and the build environment and I have some issues and questions for you: > > 1) The current repository content will only build with Java8, not Java7 or Java6 due to some new Java 8 specific code introduced into Rexx.nrx and RexxComparator.nrx. I could not understand your comments about why the code was changed and there should be no requirement for those changes as far as I can tell. While researching this and modifying the build.xml to allow specification of the source/target options, I discovered early this morning the likely cause of the problems that I suspect you encountered: The Eclipse compiler included in the distribution is a broken early development build! As soon as I replaced it with the current Eclipse release version of the compiler (4.3.2) or even the newer 4.4RC1 version, the build problems while using ECJ vanished and the code changes were not needed. There were no problems when using the regular (Oracle) Java compiler. That should have alerted us to the broken ECJ compiler but it took a while to get to that point! Have I correctly understood this issue? > > 2) I did not understand why the new streamdemo.nrx example in the repository added overrides for the default methods since it runs fine for me without them, but now I suspect that the cause was the same as above. Do you agree with this assessment? > > 3) The Ant build file needs to be updated to handle the target option for Java compilations so that builds are not dependent on Java levels. I have no way to run the "makefile" (which I am sure does about the same thing as the build.bat/build.sh scripts we provide) and it does not seem like a good way to handle the current problems. > > 4) I thought we had agreed that the repository tags would reflect unchanging snapshots of the code base as per standard SVN usage, yet the tag we created to snapshot the 3.02GA release from last year has been altered. Maintenance changes to 3.02 were intended to be directed to the 3.02 branch as we had discussed previously. Do you recall this? > > 5) I recommend that the new translator logic diagrams document be excluded from the user distribution and only included in source distributions to save space and avoid confusing end users which don't need it. > > 6) Some of the documentation seems to be out of date, for example changes to the Eclipse compiler are not reflected. > > If there are no objections, I will update the repository soon to correct the above issues. The specific changes will be these: > > 1) "build.xml" will be updated to allow source/target specification for Javac or ECJ compiles and to include the new NetRexxF.jar in the build. (I am not sure where that module is documented). The latest Eclipse batch compiler (ecj-4.4RC1.jar) will be added to replace the broken one. This will move to the ant directory in the repository as required by the Eclipse Ant compiler adapter API. > > 2) Extraneous Java 8 code will be removed from Rexx.nrx, RexxComparator.nrx, and streamdemo.nrx source files. > > 3) Repository tag 3.02GA will be reverted to the original state. > > 4) I don't know how to directly update the documents, so I will post individual change requests for outdated sections I find. > > -- Kermit > > On 5/20/2014 10:20 AM, René Jansen wrote: >> Dear NetRexx users, >> >> It has been 5 days since 3.03RC1 became available. With blocking issues absent, I am planning to release RC1 unchanged as 3.03 in about two days. >> >> Please let me know if anything needs to change before we do that. >> >> 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/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by rvjansen
It seems to me that the NetRexx source code and builds should be compilable
and runnable under Java 7 until after April 2015 when formal support for that release ends. Since support for Java 6 ended earlier this year, is there any reason to require that the builds work on it or that it be current supported? Wouldn't a flat statement that "NetRexx code (including builds, source and user code) is supported and functional for all (and only) officially supported Java versions" be a good NetRexx policy? Asking users to update to Java 8 before that time is unwise, and probably unnecessary? See http://www.oracle.com/technetwork/java/eol-135779.html for the Oracle statement of support. Original email: ----------------- From: René Jansen [hidden email] Date: Tue, 20 May 2014 16:38:30 -0400 To: [hidden email] Subject: Re: [Ibm-netrexx] NetRexx 3.03RC1 Hi Kermit, good that you caught this. I had picked up the compiler from a link on this list, mainly because eclipse cannot seem to stop rearranging their websites continually and I lacked the time, until now, to go hunt around for it again. I did not find that it was broken, because it worked for me all the time *until I removed that hardcoded reference to classes.jar on MacOSX*. As you might know the -until recently- dependable conventions where to find things in Java have changed now that Oracle maintains the installers for this platform. I saw this problem of having to implement interfaces first on the windows builds, and again after linking to the right JVM8 jars on the Mac, at no time I suspected ecj, though I was rather disgruntled towards Oracle that seemed to have broken so many things in Java 8 in a late stage. I should have known better, but google searches indicated that other people had encountered this problem. Until now I was sure to have seen the same issues in the javac build. 1) it seems that we need to vet the ecj release also before pulling it into our repository. Otherwise, I would not have any problem to have the build Java 8 only, as long as it runs on 6 and greater. 2) I agree, must be the same cause 3) The solution of the separate build for the packaging in the makefile was born out of necessity because the ant build does not support it. I might move to Cmake as ooRexx is doing the same, but it would be great if the ant build can do everything. As you know, I see the need to write classes for every change to the ant build as a definite downside. 4) Yes, this was not intended and came about through time constraints - I think, because I do not remember it well. 5) That is OK with me, I'll cut them out of the user package 6) I'll have a look at those, and any other suggestions people will come up with Go ahead with the repository updates. This means we will have to have a Release Candidate 2 before we can release. Maybe we want to keep the signatures in the Rexx class in a later release so we can implement them to fit with general Java usage. Did you have any further look at the windows issue with the RxVarpool/UTF8 fix? Now that we are postponing, and I am hopefully running with correct compiler and JVM jars again, I will also have a look at what happens there. best regards, René. On 20 mei 2014, at 15:12, Kermit Kiser <[hidden email]> wrote: > René -- > > I need a little more time. I would have responded sooner but my eyes were too blurry after I finished my initial testing at 2AM this morning! > > I have only run a few test cases so far but I do not anticipate problems in that area as changes are minimal there. I have been mostly investigating the repository and the build environment and I have some issues and questions for you: > > 1) The current repository content will only build with Java8, not Java7 or Java6 due to some new Java 8 specific code introduced into Rexx.nrx and RexxComparator.nrx. I could not understand your comments about why the code was changed and there should be no requirement for those changes as far as I can tell. While researching this and modifying the build.xml to allow specification of the source/target options, I discovered early this morning the likely cause of the problems that I suspect you encountered: The Eclipse compiler included in the distribution is a broken early development build! As soon as I replaced it with the current Eclipse release version of the compiler (4.3.2) or even the newer 4.4RC1 version, the build problems while using ECJ vanished and the code changes were not needed. There were no problems when using the regular (Oracle) Java compiler. That should have alerted us to the broken ECJ compiler but it took a while to get to that point! Have I correctly understood this issue? > > 2) I did not understand why the new streamdemo.nrx example in the repository added overrides for the default methods since it runs fine for me without them, but now I suspect that the cause was the same as above. Do you agree with this assessment? > > 3) The Ant build file needs to be updated to handle the target option for Java compilations so that builds are not dependent on Java levels. I have no way to run the "makefile" (which I am sure does about the same thing as the build.bat/build.sh scripts we provide) and it does not seem like a good way to handle the current problems. > > 4) I thought we had agreed that the repository tags would reflect unchanging snapshots of the code base as per standard SVN usage, yet the tag we created to snapshot the 3.02GA release from last year has been altered. Maintenance changes to 3.02 were intended to be directed to the 3.02 branch as we had discussed previously. Do you recall this? > > 5) I recommend that the new translator logic diagrams document be excluded from the user distribution and only included in source distributions to save space and avoid confusing end users which don't need it. > > 6) Some of the documentation seems to be out of date, for example changes to the Eclipse compiler are not reflected. > > If there are no objections, I will update the repository soon to correct the above issues. The specific changes will be these: > > 1) "build.xml" will be updated to allow source/target specification for Javac or ECJ compiles and to include the new NetRexxF.jar in the build. (I am not sure where that module is documented). The latest Eclipse batch compiler (ecj-4.4RC1.jar) will be added to replace the broken one. This will move to the ant directory in the repository as required by the Eclipse Ant compiler adapter API. > > 2) Extraneous Java 8 code will be removed from Rexx.nrx, RexxComparator.nrx, and streamdemo.nrx source files. > > 3) Repository tag 3.02GA will be reverted to the original state. > > 4) I don't know how to directly update the documents, so I will post individual change requests for outdated sections I find. > > -- Kermit > > On 5/20/2014 10:20 AM, René Jansen wrote: >> Dear NetRexx users, >> >> It has been 5 days since 3.03RC1 became available. With blocking issues absent, I am planning to release RC1 unchanged as 3.03 in about two days. >> >> Please let me know if anything needs to change before we do that. >> >> 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/ > _______________________________________________ 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/ |
|
|
Bill,
this sounds like a misunderstanding. NetRexx runs guaranteed on 1.6 and later (with JVM 8 support completed in 3.03, to be released). Due to a compiler error in the ecj compiler, there was JVM 8-only code added (could have been conditionally compiled, but will be taken out for now) - to the source, in order to safeguard the running with 1.6. The level of bytecode compatibility is that of 1.5, and with some research it can probably being coaxed into running on even earlier releases. We are asking nobody to upgrade to JVM 8. Having JVM 8 as a prereq for building the compiler is another matter, to be discussed when the need will arise again. 1.5 and 1.6 are regularly seen at customer sites, so continuing support for those seems indicated, especially as long as that support is for free. best regards, René. On 20 mei 2014, at 16:53, [hidden email] wrote: > It seems to me that the NetRexx source code and builds should be compilable > and runnable under Java 7 until after April 2015 when formal support for > that release ends. > > Since support for Java 6 ended earlier this year, is there any reason to > require that the builds work on it or that it be current supported? > > Wouldn't a flat statement that "NetRexx code (including builds, source and > user code) is supported and functional for all (and only) officially > supported Java versions" be a good NetRexx policy? > > Asking users to update to Java 8 before that time is unwise, and probably > unnecessary? > > See http://www.oracle.com/technetwork/java/eol-135779.html for the Oracle > statement of support. > > > Original email: > ----------------- > From: René Jansen [hidden email] > Date: Tue, 20 May 2014 16:38:30 -0400 > To: [hidden email] > Subject: Re: [Ibm-netrexx] NetRexx 3.03RC1 > > > Hi Kermit, > > good that you caught this. I had picked up the compiler from a link on this > list, mainly because eclipse cannot seem to stop rearranging their websites > continually and I lacked the time, until now, to go hunt around for it > again. I did not find that it was broken, because it worked for me all the > time *until I removed that hardcoded reference to classes.jar on MacOSX*. > As you might know the -until recently- dependable conventions where to find > things in Java have changed now that Oracle maintains the installers for > this platform. I saw this problem of having to implement interfaces first > on the windows builds, and again after linking to the right JVM8 jars on > the Mac, at no time I suspected ecj, though I was rather disgruntled > towards Oracle that seemed to have broken so many things in Java 8 in a > late stage. I should have known better, but google searches indicated that > other people had encountered this problem. Until now I was sure to have > seen the same issues in the javac build. > > 1) it seems that we need to vet the ecj release also before pulling it into > our repository. Otherwise, I would not have any problem to have the build > Java 8 only, as long as it runs on 6 and greater. > 2) I agree, must be the same cause > 3) The solution of the separate build for the packaging in the makefile was > born out of necessity because the ant build does not support it. I might > move to Cmake as ooRexx is doing the same, but it would be great if the ant > build can do everything. As you know, I see the need to write classes for > every change to the ant build as a definite downside. > 4) Yes, this was not intended and came about through time constraints - I > think, because I do not remember it well. > 5) That is OK with me, I'll cut them out of the user package > 6) I'll have a look at those, and any other suggestions people will come up > with > > Go ahead with the repository updates. This means we will have to have a > Release Candidate 2 before we can release. Maybe we want to keep the > signatures in the Rexx class in a later release so we can implement them to > fit with general Java usage. > > Did you have any further look at the windows issue with the RxVarpool/UTF8 > fix? Now that we are postponing, and I am hopefully running with correct > compiler and JVM jars again, I will also have a look at what happens there. > > best regards, > > René. > > On 20 mei 2014, at 15:12, Kermit Kiser <[hidden email]> wrote: > >> René -- >> >> I need a little more time. I would have responded sooner but my eyes were > too blurry after I finished my initial testing at 2AM this morning! >> >> I have only run a few test cases so far but I do not anticipate problems > in that area as changes are minimal there. I have been mostly investigating > the repository and the build environment and I have some issues and > questions for you: >> >> 1) The current repository content will only build with Java8, not Java7 > or Java6 due to some new Java 8 specific code introduced into Rexx.nrx and > RexxComparator.nrx. I could not understand your comments about why the code > was changed and there should be no requirement for those changes as far as > I can tell. While researching this and modifying the build.xml to allow > specification of the source/target options, I discovered early this morning > the likely cause of the problems that I suspect you encountered: The > Eclipse compiler included in the distribution is a broken early development > build! As soon as I replaced it with the current Eclipse release version of > the compiler (4.3.2) or even the newer 4.4RC1 version, the build problems > while using ECJ vanished and the code changes were not needed. There were > no problems when using the regular (Oracle) Java compiler. That should have > alerted us to the broken ECJ compiler but it took a while to get to that > point! Have I correctly understood this issue? >> >> 2) I did not understand why the new streamdemo.nrx example in the > repository added overrides for the default methods since it runs fine for > me without them, but now I suspect that the cause was the same as above. Do > you agree with this assessment? >> >> 3) The Ant build file needs to be updated to handle the target option for > Java compilations so that builds are not dependent on Java levels. I have > no way to run the "makefile" (which I am sure does about the same thing as > the build.bat/build.sh scripts we provide) and it does not seem like a good > way to handle the current problems. >> >> 4) I thought we had agreed that the repository tags would reflect > unchanging snapshots of the code base as per standard SVN usage, yet the > tag we created to snapshot the 3.02GA release from last year has been > altered. Maintenance changes to 3.02 were intended to be directed to the > 3.02 branch as we had discussed previously. Do you recall this? >> >> 5) I recommend that the new translator logic diagrams document be > excluded from the user distribution and only included in source > distributions to save space and avoid confusing end users which don't need > it. >> >> 6) Some of the documentation seems to be out of date, for example changes > to the Eclipse compiler are not reflected. >> >> If there are no objections, I will update the repository soon to correct > the above issues. The specific changes will be these: >> >> 1) "build.xml" will be updated to allow source/target specification for > Javac or ECJ compiles and to include the new NetRexxF.jar in the build. (I > am not sure where that module is documented). The latest Eclipse batch > compiler (ecj-4.4RC1.jar) will be added to replace the broken one. This > will move to the ant directory in the repository as required by the Eclipse > Ant compiler adapter API. >> >> 2) Extraneous Java 8 code will be removed from Rexx.nrx, > RexxComparator.nrx, and streamdemo.nrx source files. >> >> 3) Repository tag 3.02GA will be reverted to the original state. >> >> 4) I don't know how to directly update the documents, so I will post > individual change requests for outdated sections I find. >> >> -- Kermit >> >> On 5/20/2014 10:20 AM, René Jansen wrote: >>> Dear NetRexx users, >>> >>> It has been 5 days since 3.03RC1 became available. With blocking issues > absent, I am planning to release RC1 unchanged as 3.03 in about two days. >>> >>> Please let me know if anything needs to change before we do that. >>> >>> 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/ >> > > _______________________________________________ > 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/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by rvjansen
OK, the repository is fixed now I think. I went too far back on the
first try and lost the fix for issue 68 but then caught that and
updated Rexx.nrx to the 403 revision with the patch. All looks good
now.
A warning - When you build with ecj now it is not obvious from the output that you are using the Eclipse compiler because of the separation of the NetRexx translate and the Java compiles and the way the Eclipse Ant adapter works. However the build is slightly faster with ecj and there are different warning messages issued in places. I will check later if there is a good way to make it clear which compiler is being used. (I also noticed that the Eclipse compiler seems to support JSR199 now which will be a great help when we add that to NetRexx as javac and ecj can be treated the same then.) The package task in the build.xml file now includes the NetRexxF.jar module in the zip so no extra steps are needed. The NetRexxF module needs to be tested. Don't worry about the diagram file - I did not include it in the zip. Building with Java 8 will automatically add the signatures you mentioned in Rexx.nrx I think. I am not familiar with the UTF8 problem. Is there an open issue describing it? -- Kermit PS: Here is the first documentation issue - the quickstart user guide has a section (5.1) describing the Eclipse compiler that says the following: "Currently, the 4.2 level of the core compiler jar is delivered with NetRexx." That version number is incorrect and will likely change with each release. I recommend changing the text to something like this: "The latest version of the Eclipse compiler jar is delivered with NetRexx." On 5/20/2014 1:38 PM, René Jansen
wrote:
Hi Kermit, good that you caught this. I had picked up the compiler from a link on this list, mainly because eclipse cannot seem to stop rearranging their websites continually and I lacked the time, until now, to go hunt around for it again. I did not find that it was broken, because it worked for me all the time *until I removed that hardcoded reference to classes.jar on MacOSX*. As you might know the -until recently- dependable conventions where to find things in Java have changed now that Oracle maintains the installers for this platform. I saw this problem of having to implement interfaces first on the windows builds, and again after linking to the right JVM8 jars on the Mac, at no time I suspected ecj, though I was rather disgruntled towards Oracle that seemed to have broken so many things in Java 8 in a late stage. I should have known better, but google searches indicated that other people had encountered this problem. Until now I was sure to have seen the same issues in the javac! build. 1) it seems that we need to vet the ecj release also before pulling it into our repository. Otherwise, I would not have any problem to have the build Java 8 only, as long as it runs on 6 and greater. 2) I agree, must be the same cause 3) The solution of the separate build for the packaging in the makefile was born out of necessity because the ant build does not support it. I might move to Cmake as ooRexx is doing the same, but it would be great if the ant build can do everything. As you know, I see the need to write classes for every change to the ant build as a definite downside. 4) Yes, this was not intended and came about through time constraints - I think, because I do not remember it well. 5) That is OK with me, I'll cut them out of the user package 6) I'll have a look at those, and any other suggestions people will come up with Go ahead with the repository updates. This means we will have to have a Release Candidate 2 before we can release. Maybe we want to keep the signatures in the Rexx class in a later release so we can implement them to fit with general Java usage. Did you have any further look at the windows issue with the RxVarpool/UTF8 fix? Now that we are postponing, and I am hopefully running with correct compiler and JVM jars again, I will also have a look at what happens there. best regards, René. On 20 mei 2014, at 15:12, Kermit Kiser [hidden email] wrote:René -- I need a little more time. I would have responded sooner but my eyes were too blurry after I finished my initial testing at 2AM this morning! I have only run a few test cases so far but I do not anticipate problems in that area as changes are minimal there. I have been mostly investigating the repository and the build environment and I have some issues and questions for you: 1) The current repository content will only build with Java8, not Java7 or Java6 due to some new Java 8 specific code introduced into Rexx.nrx and RexxComparator.nrx. I could not understand your comments about why the code was changed and there should be no requirement for those changes as far as I can tell. While researching this and modifying the build.xml to allow specification of the source/target options, I discovered early this morning the likely cause of the problems that I suspect you encountered: The Eclipse compiler included in the distribution is a broken early development build! As soon as I replaced it with the current Eclipse release version of the compiler (4.3.2) or even the newer 4.4RC1 version, the build problems while using ECJ vanished and the code changes were not needed. There were no problems when using the regular (Oracle) Java compiler. That should have alerted us to the broken ECJ compiler but it took a while to get to that point! Have I correctly u! nderstoo d this issue? 2) I did not understand why the new streamdemo.nrx example in the repository added overrides for the default methods since it runs fine for me without them, but now I suspect that the cause was the same as above. Do you agree with this assessment? 3) The Ant build file needs to be updated to handle the target option for Java compilations so that builds are not dependent on Java levels. I have no way to run the "makefile" (which I am sure does about the same thing as the build.bat/build.sh scripts we provide) and it does not seem like a good way to handle the current problems. 4) I thought we had agreed that the repository tags would reflect unchanging snapshots of the code base as per standard SVN usage, yet the tag we created to snapshot the 3.02GA release from last year has been altered. Maintenance changes to 3.02 were intended to be directed to the 3.02 branch as we had discussed previously. Do you recall this? 5) I recommend that the new translator logic diagrams document be excluded from the user distribution and only included in source distributions to save space and avoid confusing end users which don't need it. 6) Some of the documentation seems to be out of date, for example changes to the Eclipse compiler are not reflected. If there are no objections, I will update the repository soon to correct the above issues. The specific changes will be these: 1) "build.xml" will be updated to allow source/target specification for Javac or ECJ compiles and to include the new NetRexxF.jar in the build. (I am not sure where that module is documented). The latest Eclipse batch compiler (ecj-4.4RC1.jar) will be added to replace the broken one. This will move to the ant directory in the repository as required by the Eclipse Ant compiler adapter API. 2) Extraneous Java 8 code will be removed from Rexx.nrx, RexxComparator.nrx, and streamdemo.nrx source files. 3) Repository tag 3.02GA will be reverted to the original state. 4) I don't know how to directly update the documents, so I will post individual change requests for outdated sections I find. -- Kermit On 5/20/2014 10:20 AM, René Jansen wrote:Dear NetRexx users, It has been 5 days since 3.03RC1 became available. With blocking issues absent, I am planning to release RC1 unchanged as 3.03 in about two days. Please let me know if anything needs to change before we do that. 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/_______________________________________________ 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/ |
|
|
Kermit,
thank you for this. I will continue with this tomorrow, as the laptop is also the television set nowadays. About the doc issue: this category of errors is good to find, because these all need to be automated - generated from the current situation. I do that already in a number of cases, and there is no reason to not have these numbers correct - only a bit of implementation in NetRexx scripts, that are called by the document when it is processed. The UTF-8 problem is where it does not build on Windows only when the fix for utf-8 in the bean-generated methods is applied - the one that does work on Unix. best regards, René. On 20 mei 2014, at 19:37, Kermit Kiser <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
I had another thought - since this 3.03 release is being expedited
partly by the desire to support Java 8 and we are doing another RC
anyway, how would it be if I added the support for default and
static methods in interfaces that Java 8 allows? The code is already
on the x2014 test branch.
-- Kermit On 5/20/2014 5:47 PM, René Jansen
wrote:
Kermit, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Kermit,
well, don't hold back - that would be excellent. best regards, René. On 21 mei 2014, at 15:25, Kermit Kiser <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Sorry for the delay in responding - some plumbing emergency here. The code for issue 108 has been added to trunk. You can do rc2 anytime.
On May 22, 2014 6:16:59 AM PDT, "René Jansen" <[hidden email]> wrote: Kermit, -- Sent from my Android tablet with K-9 Mail. _______________________________________________ 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 |