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/[EMAIL > PROTECTED] > > > >> 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 <[EMAIL PROTECTED]>: >>> >>>> 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:[EMAIL PROTECTED] >>>>> Sent: Tuesday, March 14, 2006 8:04 PM >>>>> To: [email protected] >>>>> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
