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/[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









--
Richard Liang
China Software Development Lab, IBM


Reply via email to