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/[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
--
Paulex Yang
China Software Development Lab
IBM
