You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Daniel Gandara <da...@neosur.com> on 2006/04/07 22:28:54 UTC
[rmi] getting 1.4 bytecode
Hi,
As discussed with Oliver, I built the rmi code with the
-target jsr14 option and I got a 1.4 bytecode for the package.
I run our test suit against the package and it seems to work ok.
This is a sum up of the experience:
1) -target jsr14 option only worked with Sun's compiler, I
could not make it work on Eclipse...
2) I had to make changes to the code, basically I had to
change enums and change/remove java.util.concurrent
classes we use (ConcurrentHashMap and
ThreadPoolExecutor)
note: there is obviously a performance penalty due to 2).
The question I have now is if I should send this modified code
to be used in Harmony during this transitional phase or not.
What do you think?
I'll be waitting for comments,
Daniel
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [rmi] getting 1.4 bytecode
Posted by Daniel Gandara <da...@neosur.com>.
I have uploaded java.rmi -modified for getting 1.4 bytecode- to JIRA
HARMONY-211
Daniel
----- Original Message -----
From: "Daniel Gandara (JIRA)" <ji...@apache.org>
To: <da...@neosur.com>
Sent: Tuesday, April 11, 2006 2:52 PM
Subject: [jira] Updated: (HARMONY-211) Contribution of java.rmi
> [ http://issues.apache.org/jira/browse/HARMONY-211?page=all ]
>
> Daniel Gandara updated HARMONY-211:
> -----------------------------------
>
> Attachment: antRMI-142.tar.bz2
>
> This is a modified version of java.rmi to generate 1.4 bytecode
> (using -target jsr14 option); the file is prepared to be compiled using
> ant.
> Under "[rmi] getting 1.4 bytecode" thread I have explained the changes
> made to the original 5.0 version of the code
>
----- Original Message -----
From: "Daniel Gandara" <da...@neosur.com>
To: <ha...@incubator.apache.org>
Sent: Monday, April 10, 2006 4:11 PM
Subject: Re: [rmi] getting 1.4 bytecode
> Oliver Deakin wrote:
>> Daniel Gandara wrote:
>>> Hi, As discussed with Oliver, I built the rmi code with the -target
>>> jsr14 option and I got a 1.4 bytecode for the package. I run our test
>>> suit against the package and it seems to work ok.
>>
>> That's great news!
>>
>>> This is a sum up of the experience:
>>> 1) -target jsr14 option only worked with Sun's compiler, I could not
>>> make it work on Eclipse...
>>
>> Tim described in [1] that the Eclipse batch compiler unfortunately does
>> not support this kind of 1.5 to 1.4 compilation. There has been further
>> discussion in that thread as to which solution is best for us - Sun
>> compiler using -target jsr14, and/or Eclipse compiler at 1.5 level and
>> then use a tool called Retroweaver to alter the bytecodes to work on 1.4.
>
> yes I read the thread, I believe the goal is to find the way to automate
> the use of Retroweaver within Eclipse... anyway I see no big deal
> using the compiler with options to get 1.4 bytecode since this should
> be done for a short time while harmony gets 1.5
>
>>> 2) I had to make changes to the code, basically I had to change enums
>>> and change/remove java.util.concurrent classes we use
>>> (ConcurrentHashMap and ThreadPoolExecutor)
>>
>> I got some enum examples working by just adding a basic Enumeration class
>> to the java.lang package in luni, but I only trialled fairly simple
>> cases. What kind of alterations did you need to make? It will be
>> interesting to know some of the limits of this compiler option.
>>
> From my POV the limits of using this compiler option is basically to
> classes or methods which do not exist on 1.4, and cases like enums
> which are also new on 5.0.
> One problem we did found is getting errors at runtime, since the code
> compiles ok, but at run time there is a call to a method that is
> not on 1.4, then you and had to go back and change to give 1.4
> compatibility.
>
> Here is a complete list of the changes made to the code:
> a) Changing enum with classes, there was just one enum, and
> was changed by classes with static attributes (we had enum
> HttpHeaders and we changed it for class HttpHeaders holding
> a HashSet)
> b) Call to method Timer(String, boolean) was replaced by
> Timer(boolean)
> c) Call to method Timer.purge() was commented
> d) Call to method System.currentTimeMillis() was replaced by
> new Long(System.currentTimeMillis())
> e) ThreadPoolExectutor was removed, so we always launch
> new threads
> f) ConcurrentHashMap was replaced by a HashTable
> g) Call to method Thread.getId() was replaced by
> Thread.hashcode()
>
>>> note: there is obviously a performance penalty due to 2).
>>>
>>> The question I have now is if I should send this modified code to be
>>> used in Harmony during this transitional phase or not. What do you
>>> think?
>>
>> I think it's probably a good thing to get the code out there so we can
>> start to use it, even if this means making some temporary modifications.
>
> I agree with you, I believe I willl upload the 1.4 jar to the JIRA
> HARMONY-211 issue so the java.rmi package can go through the
> process of acceptance and be used.
>
> Regards,
> Daniel
>
>>
>> Regards,
>> Oliver
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c4433A197.8030305@gmail.com%3e
>>
>>>
>>> I'll be waitting for comments,
>>> Daniel
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [rmi] getting 1.4 bytecode
Posted by Daniel Gandara <da...@neosur.com>.
Oliver Deakin wrote:
> Daniel Gandara wrote:
>> Hi, As discussed with Oliver, I built the rmi code with the -target
>> jsr14 option and I got a 1.4 bytecode for the package. I run our test
>> suit against the package and it seems to work ok.
>
> That's great news!
>
>> This is a sum up of the experience:
>> 1) -target jsr14 option only worked with Sun's compiler, I could not
>> make it work on Eclipse...
>
> Tim described in [1] that the Eclipse batch compiler unfortunately does
> not support this kind of 1.5 to 1.4 compilation. There has been further
> discussion in that thread as to which solution is best for us - Sun
> compiler using -target jsr14, and/or Eclipse compiler at 1.5 level and
> then use a tool called Retroweaver to alter the bytecodes to work on 1.4.
yes I read the thread, I believe the goal is to find the way to automate
the use of Retroweaver within Eclipse... anyway I see no big deal
using the compiler with options to get 1.4 bytecode since this should
be done for a short time while harmony gets 1.5
>> 2) I had to make changes to the code, basically I had to change enums
>> and change/remove java.util.concurrent classes we use
>> (ConcurrentHashMap and ThreadPoolExecutor)
>
> I got some enum examples working by just adding a basic Enumeration class
> to the java.lang package in luni, but I only trialled fairly simple cases.
> What kind of alterations did you need to make? It will be interesting to
> know some of the limits of this compiler option.
>
>From my POV the limits of using this compiler option is basically to
classes or methods which do not exist on 1.4, and cases like enums
which are also new on 5.0.
One problem we did found is getting errors at runtime, since the code
compiles ok, but at run time there is a call to a method that is
not on 1.4, then you and had to go back and change to give 1.4
compatibility.
Here is a complete list of the changes made to the code:
a) Changing enum with classes, there was just one enum, and
was changed by classes with static attributes (we had enum
HttpHeaders and we changed it for class HttpHeaders holding
a HashSet)
b) Call to method Timer(String, boolean) was replaced by
Timer(boolean)
c) Call to method Timer.purge() was commented
d) Call to method System.currentTimeMillis() was replaced by
new Long(System.currentTimeMillis())
e) ThreadPoolExectutor was removed, so we always launch
new threads
f) ConcurrentHashMap was replaced by a HashTable
g) Call to method Thread.getId() was replaced by
Thread.hashcode()
>> note: there is obviously a performance penalty due to 2).
>>
>> The question I have now is if I should send this modified code to be used
>> in Harmony during this transitional phase or not. What do you think?
>
> I think it's probably a good thing to get the code out there so we can
> start to use it, even if this means making some temporary modifications.
I agree with you, I believe I willl upload the 1.4 jar to the JIRA
HARMONY-211 issue so the java.rmi package can go through the
process of acceptance and be used.
Regards,
Daniel
>
> Regards,
> Oliver
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c4433A197.8030305@gmail.com%3e
>
>>
>> I'll be waitting for comments,
>> Daniel
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [rmi] getting 1.4 bytecode
Posted by Oliver Deakin <ol...@googlemail.com>.
Daniel Gandara wrote:
> Hi, As discussed with Oliver, I built the rmi code with the -target
> jsr14 option and I got a 1.4 bytecode for the package. I run our
> test suit against the package and it seems to work ok.
That's great news!
> This is a sum up of the experience:
> 1) -target jsr14 option only worked with Sun's compiler, I could
> not make it work on Eclipse...
Tim described in [1] that the Eclipse batch compiler unfortunately does
not support this kind of 1.5 to 1.4 compilation. There has been further
discussion in that thread as to which solution is best for us - Sun
compiler using -target jsr14, and/or Eclipse compiler at 1.5 level and
then use a tool called Retroweaver to alter the bytecodes to work on 1.4.
> 2) I had to make changes to the code, basically I had to change
> enums and change/remove java.util.concurrent classes we use
> (ConcurrentHashMap and ThreadPoolExecutor)
I got some enum examples working by just adding a basic Enumeration
class to the java.lang package in luni, but I only trialled fairly
simple cases. What kind of alterations did you need to make? It will be
interesting to know some of the limits of this compiler option.
>
> note: there is obviously a performance penalty due to 2).
>
> The question I have now is if I should send this modified code to be
> used in Harmony during this transitional phase or not. What do you
> think?
I think it's probably a good thing to get the code out there so we can
start to use it, even if this means making some temporary modifications.
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c4433A197.8030305@gmail.com%3e
>
> I'll be waitting for comments,
> Daniel
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org