harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: Solution for 5.0 language features in Eclipse(Re: And enum types (Re: API with generics))
Date Fri, 17 Mar 2006 09:45:38 GMT
Tim Ellison wrote:
> Hey, good find Oliver.  Sounds like a good idea to me.
>
> Using those compiler options would be quite a significant change for the
> project, I think we should have a vote on it first to ensure everyone is
> comfortable with the change.
>
>   
I'm looking forward to see this voting happening....if this compiler 
option is added into build system, it will introduce big convenience to 
current development and help to avoid mass repeating upgrade work to 
comply with Java 5 later (there are much in already).
> Regards,
> Tim
>
> Oliver Deakin wrote:
>   
>> Paulex Yang wrote:
>>     
>>> Hi,
>>>
>>> I just find a way to use Java 5 language features in Eclipse. You can
>>> set "Compiler compliance level" to 5.0, but set "Generated  .class
>>> files compatibility " to 1.4. So that most Java 5 language new
>>> features can be used, but the class file still can run on HarmonyVM!
>>>
>>>       
>> That's great! I was suspicious that this would probably not work using
>> the javac provided with IBMs JDK, so I gave it a try:
>>
>>   >javac -source 1.5 -target 1.4 Java5Test.java
>>   javac: source release 1.5 requires target release 1.5
>>
>> A little searching about turned up a message [1] in the Gump mail
>> archive that suggests using the "-target jsr14" option to compile
>> 1.5 code into 1.4 compatible bytecodes. Attempting to compile
>> Java5Test.java with this option completes successfully.
>> Having added your mocked-up Enum class to luni.jar I was able to run
>> Java5Test against Harmony code.
>>
>> Similar options can be passed to the Ant javac task:
>>
>>   <javac source="1.5" target="jsr14" ...>
>>
>> Regards,
>> Oliver
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/gump-general/200407.mbox/%3c40E5728E.70109@gmx.de%3e
>>
>>
>>
>>     
>>> At least 6 Java 5 features can be used in this way, because they all
>>> don't need enhance class file (in same reason, I don't expect
>>> annotation can be used):
>>>    generics
>>>    enhance for loop
>>>    enum
>>>    static import
>>>    auto boxing/unboxing
>>>    varargs
>>>
>>> I've tested the 6 Java 5 language features in the little test below,
>>> and this class can run HarmonyVM smoothly. Only one modification
>>> needed, you should add a java.lang.Enum implementation to LUNI
>>> component, I've attached a naive impl of Enum below, too.
>>>
>>> But I haven't investigated the Eclipse compiler document yet to find
>>> what's the options should be set in command line, so that the Ant as
>>> well as Harmony build system can work in this way. If this is
>>> feasible, we can free from Java 1.4 jail!
>>>
>>> <code>
>>> import static java.util.Locale.US;
>>>
>>> import java.util.ArrayList;
>>> import java.util.HashMap;
>>> import java.util.List;
>>>
>>> public class Java5Test {
>>>    public static void main(String[] args) {
>>>        List<String> slist = new ArrayList<String>();
>>>        slist.add("generics and enhance for loop test");
>>>        for(String s: slist){
>>>            System.out.println(s);
>>>        }
>>>        System.out.println(EnumTest.enum1);
>>>        variArgs(1,2,3);
>>>        System.out.println("static import test:"+US);
>>>        HashMap map = new HashMap();
>>>        map.put(1, "value1");
>>>        System.out.println("auto boxing/unboxing test:"+map.get(1));
>>>    }
>>>      enum EnumTest{
>>>        enum1, enum2, enum3
>>>    }
>>>      public static void variArgs(int... i){
>>>        System.out.println("variable args test");
>>>    }
>>> }
>>> </code>
>>>
>>> <code>
>>> package java.lang;
>>>
>>> public class Enum {
>>>      public Enum(String name, int ordinal){
>>>          }
>>> }
>>> </code>
>>>
>>> Mikhail Loenko wrote:
>>>       
>>>> Hi Paulex,
>>>>
>>>> We also had problem with enums while developing security package.
>>>> Finally, we made it 1.5 compliant, tested with BEA 1.5 and commented out
>>>>
>>>> See
>>>> modules/security/src/common/javasrc/java/security/KeyRep.java
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> 2006/3/15, Paulex Yang <paulex.yang@gmail.com>:
>>>>  
>>>>         
>>>>> Nathan Beyer wrote:
>>>>>   
>>>>>           
>>>>>> My approach has been to make the APIs as close to possible as the
>>>>>> Java 5
>>>>>> spec
>>>>>>       
>>>>>>             
>>>>> Agree.  Another issue is enum, for example,
>>>>>
>>>>> public enum SomeEnum{
>>>>>    enum1, enum2, enum3
>>>>> }
>>>>>
>>>>> I think the mimic will look like:
>>>>>
>>>>> public final class SomeEnum extends Enum{
>>>>>    public static final SomeEnum enum1 =  new SomeEnum("enum1", 0);
>>>>>    public static final SomeEnum enum2 = new SomeEnum("enum2", 1);
>>>>>    public static final SomeEnum enum3 = new SomeEnum("enum3", 2);
>>>>>
>>>>>    protected SomeEnum(String name, int |ordinal|){
>>>>>       super(name, ordinal).
>>>>>    }
>>>>> }
>>>>>
>>>>> and of course, the abstract class Enum(declaration without generics of
>>>>> course) must exist at first.
>>>>>
>>>>> Thoughts?  I will raise a jira about Enum abstract class and create a
>>>>> patch later to support this mimic if this approach is fine.
>>>>>   
>>>>>           
>>>>>> and then leave //TODO comments about what needs to be added and
>>>>>> what is
>>>>>> needed to fix it or what is preventing completion.
>>>>>>
>>>>>> The same condition applies to annotations and methods that take
>>>>>> advantage of
>>>>>> return type covariance.
>>>>>>
>>>>>> We could consider creating a comment practice to flag specific
>>>>>> changes.
>>>>>> Perhaps something like this:
>>>>>>
>>>>>> //HARMONY_GENERICS <Type> comment
>>>>>> //HARMONY_ANNOTATION @annotation comment
>>>>>> //HARMONY_COVARIANT_RETURN Type comment
>>>>>>
>>>>>> In Eclipse's Java editor you can add special meaning to comments
of a
>>>>>> certain format, so this could be taken advantage of there at least.
>>>>>>
>>>>>> -Nathan
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: karan malhi [mailto:karan.malhi@gmail.com]
>>>>>> Sent: Tuesday, March 14, 2006 8:04 PM
>>>>>> To: harmony-dev@incubator.apache.org
>>>>>> Subject: API with generics
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I might have missed out on it in earlier discussions so please
>>>>>> excuse me
>>>>>> for my ignorance. What is the strategy of harmony with regards to
>>>>>> Generics? To be more specific, I am right now implementing the
>>>>>> javax.accessibility.AccessibleStateSet class which has a protected
>>>>>> variable with the following signature:
>>>>>>
>>>>>>     protected Vector<AccessibleState> states
>>>>>>
>>>>>> My understanding is that currently generics are not supported. What
>>>>>> should I do in this case? Should I just implement it without generics?
>>>>>> Is there a webpage where we are listing api methods/fields which
>>>>>> involve
>>>>>> generics to later on update the code?
>>>>>>
>>>>>>
>>>>>>       
>>>>>>             
>>>>> -- 
>>>>> Paulex Yang
>>>>> China Software Development Lab
>>>>> IBM
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>           
>>>>   
>>>>         
>>>       
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



Mime
View raw message