harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Gandara" <danielgand...@neosur.com>
Subject Re: [rmi] getting 1.4 bytecode
Date Tue, 11 Apr 2006 18:47:20 GMT
I have uploaded java.rmi  -modified for getting 1.4 bytecode- to JIRA 
HARMONY-211

Daniel

----- Original Message ----- 
From: "Daniel Gandara (JIRA)" <jira@apache.org>
To: <danielgandara@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" <danielgandara@neosur.com>
To: <harmony-dev@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


Mime
View raw message