Ad upcoming Java 9 ...
Locked
Ad upcoming Java 9 ...
 
|
Hi there, my original posting did not get through, possibly
because I used a wrong e-mail address, therefore retrying.
Regards, ---rony --- Hi there, one major effort that will materialize with the next version of
Java (named Java "9", not "1.9" internally anymore, cf. <http://openjdk.java.net/jeps/223>)
is the modularization of the Java runtime environment. Sloppyly: a "module" defines the packages it consists of and
optionally other modules it may require. JSR 376 home-page: <http://openjdk.java.net/projects/jigsaw/spec/>.
Some sort of a bird eye's view/introduction at: <http://openjdk.java.net/projects/jigsaw/spec/sotms/>.
Another interesting feature set can be found in the package
"java.lang.invoke", cf.
<http://download.java.net/java/jdk9/docs/api/java/lang/invoke/package-summary.html>,
where the invokedynamic instruction can now be excercised fully
from pure Java code. It is possible to download the "jigsaw" version of Java 9 and to test these features in person. As currently the Java tool communities start to explore the modularity concepts of Java 9, it may be the case that still some details may be changed before it goes GA (cf. <http://openjdk.java.net/projects/jdk9/>, where the release date may be changed depending on the discussions about module implementations; this particular page is also interesting in learning about everything that gets introduced into Java 9, also about various aspects of the new module system). So this is a bit of preparing "food-for-thoughts" w.r.t. the
NetRexx compiler/interpreter, which may elicit the one or the
other idea/discussion. ---rony P.S.: The new Java 9 JavaDocs have a very nice new feature: a search field! Just enter e.g. "compile" and you'll get ajumplist of all JavaDoc entries that contain "compile"!
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Hi Rony,
one of the more acute results of this reworking is that NetRexx is not working at all with Java 9. We have to change the implementation on Java 8 (we need a working compiler to compile NetRexx with itself) to use reflection instead of the reading of all .jar (and .zip) files on the classpath, as it is doing now. I have cleared trunk some months ago so we can branch off for work on this. Thanks for the links in your email which will save us some time to look up all this. As this is some major restructuring of the translator, it will probably land in version 5 of it; 4 (when it is finished) will be for Java 6-8 and ends there. During the symposium you mentioned there were fallback api’s defined. I did not find these; and as NetRexx physically opens files to decompress and inspect the classes/method signatures in them, I have great doubts there will be something there that supports our effort. Kermit, did you have time to look into this? Do we need to schedule a call to divide up the work? The idea would be to change the ‘eager’ and complete looking up of signatures with a ‘lazy’, just-in-time and caching lookup scheme based on the reflection api. So the initial effort would be to trap the ‘signature not found’ exception and retrofit it in the structure it looks for it. best regards, René.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Rony, René - Yes, I have a plan to fix the jar pre-read issue. I hope to work
on that after finishing some changes Google insists are needed
right now (they like to change Android in non compatible ways). I have been worried that we would lose the "branch import" capability (called partial package name in the reference) from NetRexx with Java 9 since that comes from the pre-read of the entire class name space. However on thinking about it now, it occurs to me that the complete namespace for the Java base and library will be documented somewhere and if we capture that data and add it to an internal module of the compiler we can still preserve most of the branch import capability. What do you think? I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system. -- Kermit On 9/30/2016 7:01 AM, René Jansen
wrote:
Hi Rony, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Kermit,
re: branch imports I think we should not have to resort to import documentation - and it would not work for own libraries, which are plenty. I have to read more about the module system; my hope is that it will assist. And yes, migrating the repositories will be next - but that is just work and needs consensus first. I plan to migrate the whole history of the source code repository. I am not sure we need the whole history of the issue tracker, but I will have a look when we get that dump. Having worked with sccs, rcs, pvcs, sourcesafe, endevor, svn, rts etc, I am a fulltime Git bigot - that must have been clear from my symposium presentation on how to handle the jGit library with NetRexx. Both SourceForge (where we have other RexxLA code) and Github (duh) support git. I do not want a take a decision that you do not agree with. I think we still have a few months. best regards, René.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
René; Let me know if you find a way to scan the class namespace without reading jar files. I understand that we have a few months still to migrate the
repositories but I don't know how long we will be working on Java9
and other changes before release and I would actually rather be
working with the new format/location rather than having to
co-ordinate a complicated changeover in the middle of that work. I
suggest that we move the repository to GitHub and set up developer
accounts there now. We can then take more time to figure out how
to move the issue database to another tracker later. Re Git - I still have no experience with it but I am studying it
and I see that there are 4 code levels (remote, local, stage,
working) rather than the two (repository and working copy) of SVN
and that it requires 3 transactions (add, commit, and push) for a
basic Git update equivalent to an SVN commit. I am guessing that
Git is about three times as complex as SVN to work with. I trust
there are advantages to the added complexity but I will have to
learn them over time. I have no problem with switching over and I
think most of the other developers already have some Git
experience or can grok the switch. -- Kermit On 10/1/2016 2:00 AM, René Jansen
wrote:
Kermit, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
On Sat, Oct 1, 2016 at 5:42 AM, Kermit Kiser <[hidden email]> wrote: I don't mean to hijack this thread however I do suggest that our highest priority at the moment is to migrate the repositories and issue database from Kenai to somewhere else as we are quickly running out of time. This requires a command decision soon (GitHub? Sourceforge? etc.) so that we can begin to work on that project. Moving the repositories should be fairly straightforward but the issues database will probably require some conversion code to change to a new format for import to a new tracking system. +1 for sourceforge. they are under new management and have got rid of the wrongdoings of the previous owners. I recently had to report a bug on github as an end user and was astonished to find its very basic issues reporting interface. https://t.co/Q5yZ2uDCSw Or perhaps a third option: keeping a presence on both systems? SF.net for downloads, bug triage, and github for CVS? You know, two windows attract more visitors than a single one... FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
If I can summarize the views up until now:
Kermit has no problems switching to Git (thank you!); Fernando prefers SourceForce as its bug reporter is better. I have no preference but note that we have ooRexx at SourceForge. We did decide to move it, but that was under previous SF management and they seem to have played square lately. I now see a possibility to move to SourceForge and use Git as SCCM. This is also an attractive option for me. So I have claimed https://sourceforge.net/projects/netrexx/ and have configured it with Git. This is not definitive; Tom already has a NetRexx on Github, and it seems wise to mirror these, at least for the code repository. Thankfully, this is easy and can be automated. I will share admin of the SF site with chosen RexxLA board members and volunteers. First I will preserve history in an svn-git conversion; after that, I will request a dump from the Kenai metadata and see how much we can convert/import. So for the moment, as the project manager, I have decided to run the project on SourceForge and on GitHub, with a preference of having the bug tracker and other project-meta objects on SourceForge. I will provide a short intro to Git for NetRexx, with the corresponding svn command equivalents. best regards, René.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: code repository choice (was: java 9 ...)
|
|
That sounds like a good plan!
Perhaps ooRexx should be mirrored on GitHub also? -- Kermit On October 6, 2016 1:20:56 AM PDT, "René Jansen" <[hidden email]> wrote: If I can summarize the views up until now: -- Sent from my Android device with K-9 Mail. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
yes, certainly. but git-git mirroring is easier than svn-git mirroring, so someone should invest some time - it can certainly be done René.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by Rony G. Flatscher (wu-wien)
Hello there, after the RexxLA 2017 Symposium, and Rene's statement that Java 9 is still an issue for NetRexx, I did now watch the Videos and the other materials thanksfully provided by Prof. Dr. Rony G. Flatscher, some time ago. Am I lucky that I don't know Java too much :-) I think that the step of introducing *modules* is a GREAT STEP forward. That's what I did learn 50 Years ago, by now, at the technical university of Vienna, at least ;-) For sure, Rene, when I can help You to get NetRexx 4 running under Java 9 ... Just Say so ... As a retired IT-Consultant, this job might be interesting ;-) Kindly, as always, Thomas Schneider. PS: Am I not lucky that my limited Java knowledge did never allow me to use internal API's ? PPS: Sorry for the interruption of this quiet-ness on ibm-netrexx
;-) ================================================================================== Am 30.09.2016 um 15:43 schrieb Rony G.
Flatscher (wu-wien):
_______________________________________________ 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 |
| Free forum by Nabble | Edit this page |