NetRexx 3.04 JSR199 Compiler API and other enhancements.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

NetRexx 3.04 JSR199 Compiler API and other enhancements.

Kermit Kiser
René and other interested parties:

I have finished the enhancements for the 3.04 release unless you want to
add the optional JSR223 interfaces (Compilable and Invocable) before
release. (Those JSR223 enhancements could probably be coded and tested
in about two weeks although I will be tied up with Android and other
stuff for a while.)

In case you have not examined the tracking issue #120, here are the
latest translator changes:
----------------------------------------------------------------------------------------------------------------------------
"-javac" and "-ecj" options - the Java property nrx.compiler still works
but the compiler options override it.

NetRexC now uses the Java property nrx.compiler to pass options to the
Java compiler. Examples: -Dnrx.compiler="javac -source 1.6 -target 1.6"
or -Dnrx.compiler="-nowarn"

Note that specifying a compiler is now a "preference" - if that compiler
is not available, the other will be used if present. Also, if no
compiler is present in the classpath received by the translator at
start-up, a search will be made of the current directory and the Java
directories to locate a jar file containing a Java compiler which can be
used. Candidate files are: "tools.jar", "NetRexxF.jar", "ecj*.jar"

Translator API users requesting return of classes in memory now get
"JavaFileObject" objects in the return List along with the custom
classloader for the compiled classes. This associates program names with
the class code in contrast to the previous byte-code arrays.

"loop over" constructs are now removed from the jsr199 support code for
performance reasons.
-----------------------------------------------------------------------------------------------------------------------------

With these changes, NetRexx version 3 is complete. (Except for bug fixes
and doc updates of course.) Further enhancements will require
significant changes to the NetRexx language itself to support major Java
language changes and should belong to NetRexx version 4 I think. Some
changes, like the pre-read elimination will not be completely compatible
with existing programs.

Here is a list of NetRexx version 4 possible enhancements:
-----------------------------------------------------------------------------
Enum
Generics
Lambda
Annotations
Regexp
Anonymous classes
Eliminate jar pre-read requirement
Nested classes (required for some of above features)
-----------------------------------------------------------------------------

-- Kermit

PS for René -

Although I have not specifically looked at this yet, I accidentally
discovered that the NetRexx build is noticeably faster with the new
translator version even though we still have the kludge we did to get
-target capability. I suspect that it is because the .java files are
written much more efficiently now. What do you think? The property
enhancement should allow us to remove the kludge and get much better
build performance, I hope.
I did a little testing on Ubuntu because the directory searching and
classpath stuff is a little different between Windows and Linux but it
would be good to have further testing there and also on Mac OS X. Let me
know if you spot any more bugs and I will try to fix them quickly. Also
would you like me to update the Eclipse compiler to the latest version?


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.04 JSR199 Compiler API and other enhancements.

rvjansen
Hi Kermit,

yes, please do. I would like to build on the new one - it is production already for me and my work, because of this. Also, the earlier the better for testing a new level of ecj - we can always rollback if we tested and found things wanting.


best regards,

René.


>
> PS for René -
>
> Although I have not specifically looked at this yet, I accidentally discovered that the NetRexx build is noticeably faster with the new translator version even though we still have the kludge we did to get -target capability. I suspect that it is because the .java files are written much more efficiently now. What do you think? The property enhancement should allow us to remove the kludge and get much better build performance, I hope.
> I did a little testing on Ubuntu because the directory searching and classpath stuff is a little different between Windows and Linux but it would be good to have further testing there and also on Mac OS X. Let me know if you spot any more bugs and I will try to fix them quickly. Also would you like me to update the Eclipse compiler to the latest version?
>
>
> _______________________________________________
> 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/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.04 JSR199 Compiler API and other enhancements.

Kermit Kiser
Odd how the simplest tasks become major projects!

I have updated the Eclipse compiler in trunk to 4.4.2 which is GA. It
was at 4.4RC1 level previously.
I also updated the NetRexx build to use the new translator version with
jsr199 but in the process I discovered something that disconcerted me.
It seems that the jsr199 compilers use a newer class file format than
the old interface. The class files produced are now larger. There is
more debug code or tags or something in them. That should not be a
problem normally but in the case of the NetRexx jar files which contain
hundreds of class files, the size is much increased. For example;
NetRexxC.jar goes from 355KB to 421KB. I don't know if that is an issue
although NetRexxR.jar may be. Anyway, I kept the old build commands and
xml file as an option: "buildsmall" will create the smaller classes/jar
files.

I also forgot to mention earlier that I did some research and developed
a possible approach to the jar pre-read issue. It is noted on a new
graphic diagram page in the translator logic diagrams I committed.
NetRexxC reads and analyzes class files in two modules and also builds
them in another. One of those modules, RxClassImage will need to be
replaced with something that uses reflection. However that is a minor
part of the complete change I think.

-- Kermit


On 5/9/2015 3:20 AM, René Jansen wrote:

> Hi Kermit,
>
> yes, please do. I would like to build on the new one - it is production already for me and my work, because of this. Also, the earlier the better for testing a new level of ecj - we can always rollback if we tested and found things wanting.
>
>
> best regards,
>
> René.
>
>
>> PS for René -
>>
>> Although I have not specifically looked at this yet, I accidentally discovered that the NetRexx build is noticeably faster with the new translator version even though we still have the kludge we did to get -target capability. I suspect that it is because the .java files are written much more efficiently now. What do you think? The property enhancement should allow us to remove the kludge and get much better build performance, I hope.
>> I did a little testing on Ubuntu because the directory searching and classpath stuff is a little different between Windows and Linux but it would be good to have further testing there and also on Mac OS X. Let me know if you spot any more bugs and I will try to fix them quickly. Also would you like me to update the Eclipse compiler to the latest version?
>>
>>
>> _______________________________________________
>> 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/

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx 3.04 JSR199 Compiler API and other enhancements.

Dave Woodman
Perhaps the StackMapTable introduced for the split-verifier?

        Dave.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Kermit Kiser
Sent: 10 May 2015 08:31
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] NetRexx 3.04 JSR199 Compiler API and other enhancements.

Odd how the simplest tasks become major projects!

I have updated the Eclipse compiler in trunk to 4.4.2 which is GA. It was at 4.4RC1 level previously.
I also updated the NetRexx build to use the new translator version with
jsr199 but in the process I discovered something that disconcerted me.
It seems that the jsr199 compilers use a newer class file format than the old interface. The class files produced are now larger. There is more debug code or tags or something in them. That should not be a problem normally but in the case of the NetRexx jar files which contain hundreds of class files, the size is much increased. For example; NetRexxC.jar goes from 355KB to 421KB. I don't know if that is an issue although NetRexxR.jar may be. Anyway, I kept the old build commands and xml file as an option: "buildsmall" will create the smaller classes/jar files.

I also forgot to mention earlier that I did some research and developed a possible approach to the jar pre-read issue. It is noted on a new graphic diagram page in the translator logic diagrams I committed.
NetRexxC reads and analyzes class files in two modules and also builds them in another. One of those modules, RxClassImage will need to be replaced with something that uses reflection. However that is a minor part of the complete change I think.

-- Kermit


On 5/9/2015 3:20 AM, René Jansen wrote:

> Hi Kermit,
>
> yes, please do. I would like to build on the new one - it is production already for me and my work, because of this. Also, the earlier the better for testing a new level of ecj - we can always rollback if we tested and found things wanting.
>
>
> best regards,
>
> René.
>
>
>> PS for René -
>>
>> Although I have not specifically looked at this yet, I accidentally discovered that the NetRexx build is noticeably faster with the new translator version even though we still have the kludge we did to get -target capability. I suspect that it is because the .java files are written much more efficiently now. What do you think? The property enhancement should allow us to remove the kludge and get much better build performance, I hope.
>> I did a little testing on Ubuntu because the directory searching and classpath stuff is a little different between Windows and Linux but it would be good to have further testing there and also on Mac OS X. Let me know if you spot any more bugs and I will try to fix them quickly. Also would you like me to update the Eclipse compiler to the latest version?
>>
>>
>> _______________________________________________
>> 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/



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/