You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Paulex Yang <pa...@gmail.com> on 2006/03/15 08:38:39 UTC
And enum types (Re: API with generics)
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
Re: Solution for 5.0 language features in Eclipse(Re: And enum types (Re: API with generics))
Posted by Ashish Ranjan <as...@gmail.com>.
>
> >>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).
+1 from me too.
I don't forsee any negative vote for this, atleast.
bye :-)
Ashish Ranjan
Scientist,CSIR,India
ashishwave@yahoo.com
ashishwave@gmail.com
Re: Solution for 5.0 language features in Eclipse(Re: And enum types
(Re: API with generics))
Posted by Paulex Yang <pa...@gmail.com>.
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 <pa...@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
Re: Solution for 5.0 language features in Eclipse(Re: And enum types (Re: API with generics))
Posted by Karan Malhi <ka...@gmail.com>.
This is pretty cool. +1 for it
On 3/16/06, Tim Ellison <t....@gmail.com> 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.
>
> 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 <pa...@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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
--
Karan Malhi
Re: Solution for 5.0 language features in Eclipse(Re: And enum types
(Re: API with generics))
Posted by Tim Ellison <t....@gmail.com>.
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.
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 <pa...@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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Solution for 5.0 language features in Eclipse(Re: And enum types
(Re: API with generics))
Posted by Richard Liang <ri...@gmail.com>.
That's great, Paulex. Then we can implement Java 5 language features for
Harmony.
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 <pa...@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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
--
Richard Liang
China Software Development Lab, IBM
Re: Solution for 5.0 language features in Eclipse(Re: And enum types
(Re: API with generics))
Posted by Oliver Deakin <ol...@googlemail.com>.
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 <pa...@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
>>>
>>>
>>>
>>>
>>
>>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
Solution for 5.0 language features in Eclipse(Re: And enum types
(Re: API with generics))
Posted by Paulex Yang <pa...@gmail.com>.
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!
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 <pa...@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
Re: And enum types (Re: API with generics)
Posted by Mikhail Loenko <ml...@gmail.com>.
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 <pa...@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
>
>
>