Re: svn commit: r412928 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/Collections.java
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to /pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure, yet
neither overrides the other
[javac] private static class UnmodifiableEntrySetK, V extends
UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
=
=
--- incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java (original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java Thu Jun 8 21:59:15 2006
@@ -27,15 +27,15 @@
*/
public class Collections {
- private static final class CopiesList extends AbstractList implements
+ private static final class CopiesListE extends AbstractListE implem
ents
Serializable {
private static final long serialVersionUID = 273909926839871180
0L;
private final int n;
- private final Object element;
+ private final E element;
- CopiesList(int length, Object object) {
+ CopiesList(int length, E object) {
if (length 0) {
throw new IllegalArgumentException();
}
@@ -51,7 +51,7 @@
return n;
}
- public Object get(int location) {
+ public E get(int location) {
if (0 = location location n)
return element;
throw new IndexOutOfBoundsException();
@@ -162,13 +162,13 @@
}
}
- private static final class SingletonSet extends AbstractSet implements
+ private static final class SingletonSetE extends AbstractSetE imple
ments
Serializable {
private static final long serialVersionUID = 319368720755043167
9L;
- final Object element;
+ final E element;
- SingletonSet(Object object) {
+ SingletonSet(E object) {
element = object;
}
@@ -180,15 +180,15 @@
return 1;
}
- public Iterator iterator() {
- return new Iterator() {
+ public IteratorE iterator() {
+ return new IteratorE() {
boolean hasNext = true;
public boolean hasNext() {
return hasNext;
}
- public Object next() {
+ public E next() {
if (hasNext) {
hasNext = false;
return element;
@@ -203,13 +203,13 @@
}
}
- private static final class SingletonList extends AbstractList implement
s
+ private static final class SingletonListE extends AbstractListE imp
lements
Serializable {
private static final long serialVersionUID = 309373661874065295
1L;
- final Object element;
+ final E element;
- SingletonList(Object object) {
+ SingletonList(E object) {
element = object;
}
@@ -217,7 +217,7 @@
return element == null ? object == null : element.equal
s(object);
}
- public Object get(int location) {
+ public E get(int location) {
if (location == 0)
return element;
throw new IndexOutOfBoundsException();
@@ -228,13 +228,14 @@
}
}
- private static final class SingletonMap extends AbstractMap implements
+ private
[DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
All, I am hoping someone who has worked on compilers can actually do the JIT modifications. I don't have much experience in compilers. I am trying to get MMTk write barriers integrated into Harmony DRLVM. I came up with the following scheme. I don't know if it is correct. It would be great if someone from the MMTk crowd looked at it. If it helps, I can also post this message on Jikes/MMTk mailing list. Build a shim between the DRLVM class loader and Jitrino.JET. The shim would contain a lookup table that would map _local_ variables of specific types to int. In particular, the shim would re-map local variables of the below types to int: Address Extent Offset Word The reason for the shim is to avoid modifying the class loader. This should reduce the maintenance burden. Java source code that creates objects of the above classes is a now a problem. For example, Java source code that does: int xx = 33; Address a1 = new Address(xx); Translates to the following bytecode: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 Basically the JIT needs to special case new. If it is a new of class Address/Extent/Offset/Word, substitute nop for the new bytecode. If new has been substituted, then replace the following dup with a nop. Leave iload_1 alone. Nop invokespecial. If the new was nop'ed, replace astore_2 with istore_2. The bytecode sequence the JIT really sees is now: bipush 33 istore_1 nop //new //class Address nop // dup iload_1 nop //invokespecial //Method init: (I)V istore_2//astore_2 Another example: int xx = 33; Address a1 = new Address(xx); int kk = a1.toInt(); Translates to bytecode that looks like: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 new code starts here aload_2 invokevirtual //Method toInt(V)I istore_3 All the bytecode down to astore_2 has already been described in the first example. The additional bytecode would be magically remapped by the JIT to: iload_2 // aload_2 nop // invokevirtual//Method toInt(V)I istore_3 Equivalent mappings will be needed for the rest of the methods of class Address as well as Extent, Offset and Word. Will the above work? Thoughts? -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
hi, guys
The way to use gen_invoke to call a Java write barrier should work, and
the better way may be inlining the barrier code. Maybe jet can not do
inlining, but jitrino.opt should do it.
Alex's idea is not so bad. It is right that the cost will be high if
we'll have a JNI call on every PUFIELD/PUTSTATIC/AASTORE, but I think
the performance for jet is not very critical, becasue it is not an
optimized jit. If we realy care about some methods' performance, we
should recompile it using some more powerful jit such as jitrino.opt.
In fact, Alex's idea can be implemented as something like a root GC
which can dynamically manage the different GC with the same interface.
The idea of root GC will actually incur many overhead of indirect
calling. I think, if we only care about the static situation with
certain information about what gc we use, whether we have write
barriers .etc, the direct solution is sure to be the best. But when we
consider some dynamic situations, it is not the case. For example, when
we change a gc without needs for write barrier to another gc with the
needs during runtime, if we do not have help of root GC, we should
recompile the method using jet, and if we have root GC, we do not have
to recompile it, the changing to a new write barrier function can be
finished by root GC interface during the process of loading of the new
gc. Of course, recompiling for more powerful optimization is necessary,
but it should only be done on some hot methods, and we may not need to
recompile all the methods using jet.
The above is just a consideration for infrastructure. I have already
implemented the write barrier code in jet for some GC developed in C.
It has already been tested and attached file is the patch.
thanks
-ming
diff -BburN vm/jitrino/src/jet/cg_ia32.cpp vm-write-barriers/jitrino/src/jet/cg_ia32.cpp
--- vm/jitrino/src/jet/cg_ia32.cpp 2006-03-28 22:33:21.0 +0800
+++ vm-write-barriers/jitrino/src/jet/cg_ia32.cpp 2006-06-04 11:16:21.0 +0800
@@ -2080,6 +2080,12 @@
voper(typeInfo[jt].mov, phi, vstack(1));
}
//
+ if (jt == jobj) {
+ void *helper = vm_get_rt_support_addr(VM_RT_WRITE_BARRIER_FASTCALL);
+ gen_mem(MEM_STACK|MEM_VARS|MEM_TO_MEM|MEM_UPDATE);
+ voper(Mnemonic_MOV, RegName_ECX, rref);
+ vcall(helper);
+ }
vpop(jt);
vpop(jobj);
}
diff -BburN vm/vmcore/src/jit/jit_runtime_support.cpp vm-write-barriers/vmcore/src/jit/jit_runtime_support.cpp
--- vm/vmcore/src/jit/jit_runtime_support.cpp 2006-03-28 22:53:28.0 +0800
+++ vm-write-barriers/vmcore/src/jit/jit_runtime_support.cpp 2006-06-04 11:17:36.0 +0800
@@ -1657,6 +1657,8 @@
#endif
switch(f) {
+ case VM_RT_WRITE_BARRIER_FASTCALL:
+return NULL;
// Object creation
case VM_RT_NEW_RESOLVED_USING_VTABLE_AND_SIZE:
return NULL;
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
Clever trick. But I don't understand why you want to create the Address object at all. You can probably just invoke a method of Address to generate an Address object reference, and the method invoke bytecode can be identified by the JIT compiler easily and replaced by a nop or whatever proper. In this way, the Address object reference can be used directly as an object reference, i.e., object pointer. Thanks, xiaofeng On 6/9/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, I am hoping someone who has worked on compilers can actually do the JIT modifications. I don't have much experience in compilers. I am trying to get MMTk write barriers integrated into Harmony DRLVM. I came up with the following scheme. I don't know if it is correct. It would be great if someone from the MMTk crowd looked at it. If it helps, I can also post this message on Jikes/MMTk mailing list. Build a shim between the DRLVM class loader and Jitrino.JET. The shim would contain a lookup table that would map _local_ variables of specific types to int. In particular, the shim would re-map local variables of the below types to int: Address Extent Offset Word The reason for the shim is to avoid modifying the class loader. This should reduce the maintenance burden. Java source code that creates objects of the above classes is a now a problem. For example, Java source code that does: int xx = 33; Address a1 = new Address(xx); Translates to the following bytecode: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 Basically the JIT needs to special case new. If it is a new of class Address/Extent/Offset/Word, substitute nop for the new bytecode. If new has been substituted, then replace the following dup with a nop. Leave iload_1 alone. Nop invokespecial. If the new was nop'ed, replace astore_2 with istore_2. The bytecode sequence the JIT really sees is now: bipush 33 istore_1 nop //new //class Address nop // dup iload_1 nop //invokespecial //Method init: (I)V istore_2//astore_2 Another example: int xx = 33; Address a1 = new Address(xx); int kk = a1.toInt(); Translates to bytecode that looks like: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 new code starts here aload_2 invokevirtual //Method toInt(V)I istore_3 All the bytecode down to astore_2 has already been described in the first example. The additional bytecode would be magically remapped by the JIT to: iload_2 // aload_2 nop // invokevirtual//Method toInt(V)I istore_3 Equivalent mappings will be needed for the rest of the methods of class Address as well as Extent, Offset and Word. Will the above work? Thoughts? -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committer : Mark Hindess
Congratulations! On 09.06.2006, at 05:51, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Mark Hindess. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and some amazing ability in creating build systems :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r412928 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/Collections.java
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to /pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure, yet
neither overrides the other
[javac] private static class UnmodifiableEntrySetK, V
extends UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
=
=
--- incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java (original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java Thu Jun 8 21:59:15 2006
@@ -27,15 +27,15 @@
*/
public class Collections {
-private static final class CopiesList extends AbstractList implements
+private static final class CopiesListE extends AbstractListE implem
ents
Serializable {
private static final long serialVersionUID = 273909926839871180
0L;
private final int n;
-private final Object element;
+private final E element;
-CopiesList(int length, Object object) {
+CopiesList(int length, E object) {
if (length 0) {
throw new IllegalArgumentException();
}
@@ -51,7 +51,7 @@
return n;
}
-public Object get(int location) {
+public E get(int location) {
if (0 = location location n)
return element;
throw new IndexOutOfBoundsException();
@@ -162,13 +162,13 @@
}
}
-private static final class SingletonSet extends AbstractSet implements
+private static final class SingletonSetE extends AbstractSetE imple
ments
Serializable {
private static final long serialVersionUID = 319368720755043167
9L;
-final Object element;
+final E element;
-SingletonSet(Object object) {
+SingletonSet(E object) {
element = object;
}
@@ -180,15 +180,15 @@
return 1;
}
-public Iterator iterator() {
-return new Iterator() {
+public IteratorE iterator() {
+return new IteratorE() {
boolean hasNext = true;
public boolean hasNext() {
return hasNext;
}
-public Object next() {
+public E next() {
if (hasNext) {
hasNext = false;
return element;
@@ -203,13 +203,13 @@
}
}
-private static final class SingletonList extends AbstractList implement
s
+private static final class SingletonListE extends AbstractListE imp
lements
Serializable {
private static final long serialVersionUID = 309373661874065295
1L;
-final Object element;
+final E element;
-SingletonList(Object object) {
+SingletonList(E object) {
element = object;
}
@@ -217,7 +217,7 @@
return element == null ? object == null : element.equal
s(object);
}
-public Object get(int location) {
+public E get(int location) {
if (location == 0)
return element;
throw new IndexOutOfBoundsException();
@@ -228,13 +228,14 @@
}
}
-private static final class SingletonMap extends AbstractMap implements
+private static
[classlib] build failure (was: Re: svn commit: r412928 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/Collections.java)
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I am happy to take a look at the error, and if it is not a quick fix I
think we can roll back Collections without trouble.
Regards,
Tim
Geir Magnusson Jr wrote:
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to /pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure, yet
neither overrides the other
[javac] private static class UnmodifiableEntrySetK, V
extends UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
=
=
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java Thu Jun 8 21:59:15 2006
@@ -27,15 +27,15 @@
*/
public class Collections {
- private static final class CopiesList extends AbstractList implements
+ private static final class CopiesListE extends AbstractListE implem
ents
Serializable {
private static final long serialVersionUID = 273909926839871180
0L;
private final int n;
- private final Object element;
+ private final E element;
- CopiesList(int length, Object object) {
+ CopiesList(int length, E object) {
if (length 0) {
throw new IllegalArgumentException();
}
@@ -51,7 +51,7 @@
return n;
}
- public Object get(int location) {
+ public E get(int location) {
if (0 = location location n)
return element;
throw new IndexOutOfBoundsException();
@@ -162,13 +162,13 @@
}
}
- private static final class SingletonSet extends AbstractSet implements
+ private static final class SingletonSetE extends AbstractSetE imple
ments
Serializable {
private static final long serialVersionUID = 319368720755043167
9L;
- final Object element;
+ final E element;
- SingletonSet(Object object) {
+ SingletonSet(E object) {
element = object;
}
@@ -180,15 +180,15 @@
return 1;
}
- public Iterator iterator() {
- return new Iterator() {
+ public IteratorE iterator() {
+ return new IteratorE() {
boolean hasNext = true;
public boolean hasNext() {
return hasNext;
}
- public Object next() {
+ public E next() {
if (hasNext) {
hasNext = false;
return element;
@@ -203,13 +203,13 @@
}
}
- private static final class SingletonList extends AbstractList implement
s
+ private static final class SingletonListE extends AbstractListE imp
lements
Serializable {
private static final long serialVersionUID = 309373661874065295
1L;
- final Object element;
+ final E element;
- SingletonList(Object object) {
+ SingletonList(E object) {
element = object;
}
@@ -217,7 +217,7 @@
return element == null ? object == null : element.equal
s(object);
}
- public Object get(int location) {
+ public E get(int location) {
if (location == 0)
Re: [announce] New Apache Harmony Committer : Mark Hindess
welcome and well done. Tim Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Mark Hindess. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and some amazing ability in creating build systems :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
If it isn't really quick, roll it back and let Nathan fix it...
geir
Tim Ellison wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I am happy to take a look at the error, and if it is not a quick fix I
think we can roll back Collections without trouble.
Regards,
Tim
Geir Magnusson Jr wrote:
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to /pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure,
yet neither overrides the other
[javac] private static class UnmodifiableEntrySetK, V
extends UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
=
=
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java Thu Jun 8 21:59:15 2006
@@ -27,15 +27,15 @@
*/
public class Collections {
- private static final class CopiesList extends AbstractList implements
+ private static final class CopiesListE extends AbstractListE implem
ents
Serializable {
private static final long serialVersionUID = 273909926839871180
0L;
private final int n;
- private final Object element;
+ private final E element;
- CopiesList(int length, Object object) {
+ CopiesList(int length, E object) {
if (length 0) {
throw new IllegalArgumentException();
}
@@ -51,7 +51,7 @@
return n;
}
- public Object get(int location) {
+ public E get(int location) {
if (0 = location location n)
return element;
throw new IndexOutOfBoundsException();
@@ -162,13 +162,13 @@
}
}
- private static final class SingletonSet extends AbstractSet implements
+ private static final class SingletonSetE extends AbstractSetE imple
ments
Serializable {
private static final long serialVersionUID = 319368720755043167
9L;
- final Object element;
+ final E element;
- SingletonSet(Object object) {
+ SingletonSet(E object) {
element = object;
}
@@ -180,15 +180,15 @@
return 1;
}
- public Iterator iterator() {
- return new Iterator() {
+ public IteratorE iterator() {
+ return new IteratorE() {
boolean hasNext = true;
public boolean hasNext() {
return hasNext;
}
- public Object next() {
+ public E next() {
if (hasNext) {
hasNext = false;
return element;
@@ -203,13 +203,13 @@
}
}
- private static final class SingletonList extends AbstractList implement
s
+ private static final class SingletonListE extends AbstractListE imp
lements
Serializable {
private static final long serialVersionUID = 309373661874065295
1L;
- final Object element;
+ final E element;
- SingletonList(Object object) {
+ SingletonList(E object) {
element = object;
}
@@ -217,7 +217,7 @@
return element == null ? object == null : element.equal
s(object);
}
- public Object get(int location) {
+ public E get(int location) {
Re: [offlist] Re: [classlib] logging from within our implementation
On Mon, Jun 05, 2006 at 11:17:50AM +0100, Tim Ellison wrote: [Eek! ok so you can see that wasn't intended to go onto the list] FWIW and IMVHO, this kind of thing is entirely appropriate on-list :-) Apologies for embarrassing George (... but buy the book anywayg) I just might! Tim Ellison wrote: Talk to George, he's a world expert on Aspects (and co-author of a book on the subject) http://www.amazon.com/gp/product/0321245873/qid=1149502393/sr=1-1/ref=sr_1_1/102-7435876-8007311?s=booksv=glancen=283155 Regards, Tim Geir Magnusson Jr wrote: Stefano Mazzocchi wrote: Maybe we should start thinking more with that in mind and think about scratching our own itches in terms of development... we might find some serious innovation on the way to there. I think the disagreement boils down to defining the itch. I'm not interested in the overhead because while we will own the VM for our distro, it's still overhead and additionally, we want others w/ VMs to use our classlibrary too (like Sun, BEA, IBM, Apple... ) I'm going to dork around w/ aspects to see if we can make the addition of debugging a pre-processing step used by people that want to debug... geir -- LSD - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committer : Nathan Beyer
*cheer*! Keep it up, Nathan! On Mon, Jun 05, 2006 at 08:55:37PM -0400, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Nathan Beyer. - LSD - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
Yep, that was the plan, but it was a trivial fix (in repo = r412990).
Just wondering how Mikhail/Stepan got it to build? It may be a
consequence of different compiler versions again since I did not see a
compiler error on the Eclipse compiler either.
Regards,
Tim
Geir Magnusson Jr wrote:
If it isn't really quick, roll it back and let Nathan fix it...
geir
Tim Ellison wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I am happy to take a look at the error, and if it is not a quick fix I
think we can roll back Collections without trouble.
Regards,
Tim
Geir Magnusson Jr wrote:
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to
/pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure,
yet neither overrides the other
[javac] private static class UnmodifiableEntrySetK, V
extends UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
=
=
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java (original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java Thu Jun 8 21:59:15 2006
@@ -27,15 +27,15 @@
*/
public class Collections {
- private static final class CopiesList extends AbstractList implements
+ private static final class CopiesListE extends AbstractListE implem
ents
Serializable {
private static final long serialVersionUID = 273909926839871180
0L;
private final int n;
- private final Object element;
+ private final E element;
- CopiesList(int length, Object object) {
+ CopiesList(int length, E object) {
if (length 0) {
throw new IllegalArgumentException();
}
@@ -51,7 +51,7 @@
return n;
}
- public Object get(int location) {
+ public E get(int location) {
if (0 = location location n)
return element;
throw new IndexOutOfBoundsException();
@@ -162,13 +162,13 @@
}
}
- private static final class SingletonSet extends AbstractSet implements
+ private static final class SingletonSetE extends AbstractSetE imple
ments
Serializable {
private static final long serialVersionUID = 319368720755043167
9L;
- final Object element;
+ final E element;
- SingletonSet(Object object) {
+ SingletonSet(E object) {
element = object;
}
@@ -180,15 +180,15 @@
return 1;
}
- public Iterator iterator() {
- return new Iterator() {
+ public IteratorE iterator() {
+ return new IteratorE() {
boolean hasNext = true;
public boolean hasNext() {
return hasNext;
}
- public Object next() {
+ public E next() {
if (hasNext) {
hasNext = false;
return element;
@@ -203,13 +203,13 @@
}
}
- private static final class SingletonList extends AbstractList implement
s
+ private static final class SingletonListE extends AbstractListE imp
lements
Serializable {
private static final long serialVersionUID = 309373661874065295
1L;
- final Object element;
+ final E element;
- SingletonList(Object object) {
+ SingletonList(E object) {
element = object;
Re: [announce] New Apache Harmony Committer : Mark Hindess
Whoohooh! Go, Mark, go! On Thu, Jun 08, 2006 at 11:51:09PM -0400, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Mark Hindess. Look, two footers: - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] :-) LSD - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I didn't update this particular file because I work separately with
security module only.
But I think that you are right - it'd better to stop putting new code once
we get notification that the build is broken.
BTW, where is classlib build status emails? I didn't get any notification.
Thanks,
Stepan.
I am happy to take a look at the error, and if it is not a quick fix I
think we can roll back Collections without trouble.
Regards,
Tim
Geir Magnusson Jr wrote:
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to
/pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure,
yet neither overrides the other
[javac] private static class UnmodifiableEntrySetK, V
extends UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
SNIP
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] proposal - resolution to java.util.concurrent issue
Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: I had a nice chat with Doug today to try to reach a conclusion regarding j.u.c Given that everyone else (Sun, IBM, BEA...) seems to use j.u.c, found here http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ I think that we'd be well-served to do so as well. It's the RI, it's complicated, it goes w/o saying that Doug is committed to this being right, and I'd like to have the same bugs as everyone else for now :) The summary of what I think we should do is simple - we take the code from j.u.c from the above link (w/ 1 exception) into our SVN repo and track any changes made by Doug and the jsr166 EG going forward. So I understand correctly, are you talking about taking the source code into Harmony SVN, or creating a dependency on a binary version of that code (stored in our SVN)? Into our SVN, simply for ease of use, oversight, and control. Can you expand on that for me? Why isn't a binary dependency sufficient? Just trying to figure the rationale of taking source if the goal is to be in lock-step. Are you imagining that there may be patches created here that are ALv2'd only (and maybe therefore do not go back into Doug's copy)? It could be, although given how it seems to be working, I would guess we'd work with Doug if there were problems, and see if he'd do it into the RI. All the code is under the following terms, which are acceptable to the ASF : /* * Written by Doug Lea with assistance from members of JCP JSR-166 * Expert Group and released to the public domain, as explained at * http://creativecommons.org/licenses/publicdomain */ except for one file : http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java for which I understand we can get a clean replacement from the backport. Now, there is an issue of our clean-room rules, and I think there's a very neat solution that would allow us to use this code w/o getting an ACQ from the authors of j.u.c (which Doug claims is himself, assisted by the JSR166 EG) The premise of our ACQ structure is that we want to ensure that people who have worked on a non-open/non-free implementation of a portion/module/component of Java not work on our implementation of that portion/module/component. Now, given that j.u.c in Java SE 5 is the first time this functionality has existed, it must be the case that the contributors are not contaminated by working on another implementation, since there are no other implementations. We can't be contaminated because there's nothing with which to contaminate us with. AIUI (and hypothetically) people could take a copy of the public domain code and create a proprietary derivative couldn't they? And the spec is out there for all to see, how do you know there are no other implementations? There could be implementations out there now, but there weren't before, and we'd just have to watch to see what gets added down the road... I assume that the authors (jsr166-group) have a good knowledge of all sorts of code that is in our ACQ CORE bucket. The need not only be 'contaminated' by concurrent. (I would like to see this, I'm still just thinking it through). Regards, Tim That is the gate I was talking about - we are still overseeing what we're distributing... Of course, this needs VM support, so there is work to do, but this seems like a sane and clean way to add this functionality to Harmony classlib, as well as build a bridge to another part of the Java SE ecosystem. Don't get me wrong, I think we should build the bridge -- just working things out in my head. Comments? Things that I missed? Invite the j.u.concurrent expert group to move in g. That would be cool :) geir Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
Stepan Mishura wrote:
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I didn't update this particular file because I work separately with
security module only.
But I think that you are right - it'd better to stop putting new code once
we get notification that the build is broken.
BTW, where is classlib build status emails? I didn't get any notification.
AFAIK they are still being sent out -- possibly a problem with them
being accepted on the commit list?.
Regards,
Tim
I am happy to take a look at the error, and if it is not a quick fix I
think we can roll back Collections without trouble.
Regards,
Tim
Geir Magnusson Jr wrote:
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to
/pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V
and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure,
yet neither overrides the other
[javac] private static class
UnmodifiableEntrySetK, V
extends UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
SNIP
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrote: Hi Tim, On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: I see it too. Stepan / Mikhail, do you get build failures? Shouldn't we stop putting in new code until this is resolved? I didn't update this particular file because I work separately with security module only. But I think that you are right - it'd better to stop putting new code once we get notification that the build is broken. BTW, where is classlib build status emails? I didn't get any notification. I think they are failing to get to the list because they are too large. I tried changing the envelope sender to my gmail account - which is subscribed to the -commits list, but they still don't make the list or generate any bounce messages. I've changed the sender back to [EMAIL PROTECTED] as it was originally. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] proposal - resolution to java.util.concurrent issue
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: I had a nice chat with Doug today to try to reach a conclusion regarding j.u.c Given that everyone else (Sun, IBM, BEA...) seems to use j.u.c, found here http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ I think that we'd be well-served to do so as well. It's the RI, it's complicated, it goes w/o saying that Doug is committed to this being right, and I'd like to have the same bugs as everyone else for now :) The summary of what I think we should do is simple - we take the code from j.u.c from the above link (w/ 1 exception) into our SVN repo and track any changes made by Doug and the jsr166 EG going forward. So I understand correctly, are you talking about taking the source code into Harmony SVN, or creating a dependency on a binary version of that code (stored in our SVN)? Into our SVN, simply for ease of use, oversight, and control. Can you expand on that for me? Why isn't a binary dependency sufficient? It would be if there was one. As far as I can tell, there isn't. There also may be small mods required to work w/ our VMI. Dunno - hopefully Nathan or others can tell us. What's the problem with having the source around? It makes it easier for people to look at, debug, etc... Just trying to figure the rationale of taking source if the goal is to be in lock-step. Are you imagining that there may be patches created here that are ALv2'd only (and maybe therefore do not go back into Doug's copy)? It could be, although given how it seems to be working, I would guess we'd work with Doug if there were problems, and see if he'd do it into the RI. All the code is under the following terms, which are acceptable to the ASF : /* * Written by Doug Lea with assistance from members of JCP JSR-166 * Expert Group and released to the public domain, as explained at * http://creativecommons.org/licenses/publicdomain */ except for one file : http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java for which I understand we can get a clean replacement from the backport. Now, there is an issue of our clean-room rules, and I think there's a very neat solution that would allow us to use this code w/o getting an ACQ from the authors of j.u.c (which Doug claims is himself, assisted by the JSR166 EG) The premise of our ACQ structure is that we want to ensure that people who have worked on a non-open/non-free implementation of a portion/module/component of Java not work on our implementation of that portion/module/component. Now, given that j.u.c in Java SE 5 is the first time this functionality has existed, it must be the case that the contributors are not contaminated by working on another implementation, since there are no other implementations. We can't be contaminated because there's nothing with which to contaminate us with. AIUI (and hypothetically) people could take a copy of the public domain code and create a proprietary derivative couldn't they? And the spec is out there for all to see, how do you know there are no other implementations? There could be implementations out there now, but there weren't before, and we'd just have to watch to see what gets added down the road... I assume that the authors (jsr166-group) have a good knowledge of all sorts of code that is in our ACQ CORE bucket. The need not only be 'contaminated' by concurrent. Right, but unless you believe that by knowing about code in our CORE bucket that isn't j.u.c yet somehow tainted j.u.c, shouldn't we just add a new 'bucket' for j.u.c to solve what would then simply be a paper problem? (I would like to see this, I'm still just thinking it through). This is a good and reasonable discussion to have. I'm just working the Pragmatic Devil's Advocate line here... geir Regards, Tim That is the gate I was talking about - we are still overseeing what we're distributing... Of course, this needs VM support, so there is work to do, but this seems like a sane and clean way to add this functionality to Harmony classlib, as well as build a bridge to another part of the Java SE ecosystem. Don't get me wrong, I think we should build the bridge -- just working things out in my head. Comments? Things that I missed? Invite the j.u.concurrent expert group to move in g. That would be cool :) geir Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
I checked the allow list, and
[EMAIL PROTECTED]
is still there.
I'm assuming that this isn't a real account. Any chance you could
switch to one to test, so you can see the bounceback if there is one?
geir
Tim Ellison wrote:
Stepan Mishura wrote:
Hi Tim,
On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote:
I see it too.
Stepan / Mikhail, do you get build failures? Shouldn't we stop putting
in new code until this is resolved?
I didn't update this particular file because I work separately with
security module only.
But I think that you are right - it'd better to stop putting new code once
we get notification that the build is broken.
BTW, where is classlib build status emails? I didn't get any notification.
AFAIK they are still being sent out -- possibly a problem with them
being accepted on the commit list?.
Regards,
Tim
I am happy to take a look at the error, and if it is not a quick fix I
think we can roll back Collections without trouble.
Regards,
Tim
Geir Magnusson Jr wrote:
and the beer flowed
Mark Hindess wrote:
This breaks the build. I'm getting:
compile:
[javac] Compiling 1839 source files to
/pbuilder/tmp/Harmony.clean/build
[javac]
/pbuilder/tmp/Harmony.clean/modules/luni/src/main/java/java/util/Collections.java:1074:
name clash: add(java.lang.Object) in
java.util.Collections.UnmodifiableCollectionjava.util.Map.EntryK,V
and
add(E) in java.util.Setjava.util.Map.EntryK,V have the same erasure,
yet neither overrides the other
[javac] private static class
UnmodifiableEntrySetK, V
extends UnmodifiableSetMap.EntryK, V {
[javac]^
w/sun 1.5 javac on linux.
Regards,
Mark.
On 9 June 2006 at 4:59, [EMAIL PROTECTED] wrote:
Author: ndbeyer
Date: Thu Jun 8 21:59:15 2006
New Revision: 412928
URL: http://svn.apache.org/viewvc?rev=412928view=rev
Log:
Generification of methods.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java
/util/Collections.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/jav
a/java/util/Collections.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/src/main/java/java/util/Collections.java?rev=412928r1=412927r2=
412928view=diff
SNIP
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
A large message should still generate a bounce... I'll go look to see what the size is. How large are these messages? Mark Hindess wrote: On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrote: Hi Tim, On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: I see it too. Stepan / Mikhail, do you get build failures? Shouldn't we stop putting in new code until this is resolved? I didn't update this particular file because I work separately with security module only. But I think that you are right - it'd better to stop putting new code once we get notification that the build is broken. BTW, where is classlib build status emails? I didn't get any notification. I think they are failing to get to the list because they are too large. I tried changing the envelope sender to my gmail account - which is subscribed to the -commits list, but they still don't make the list or generate any bounce messages. I've changed the sender back to [EMAIL PROTECTED] as it was originally. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] building...
Garrett Rooney wrote: SNIP Now sometimes you do need to have a totally different implementation for a new platform, but a lot of the time, there can be some minor ifdefs (based on availability of FEATURES, not platform) that allow the same file to work on multiple platforms. Just splitting up into two implementations (or really N implementations, since eventually Harmony will run on more than just Linux and Windows) is a bit of a waste, and ifdefing based on platform is just as bad, since the stuff that works on FreeBSD or OpenBSD or Solaris is often the same as the stuff that works on Linux... What we ended up with in APR is something like this: There's a base implementation of each file that is designed to work on any unix system. These go in unix/ subdirectories. If it's feasable to make that file work elsewhere (Netware, Windows, OS/2, BeOS, whatever) then it's done via ifdefs. If the ifdefs get out of control, or the platform is really that different then you start splitting off into platform specific implementations, but that's a last resort. We actually had some discussion about doing exactly that kind of thing a while back [1] and more recently [2]. The basic ideas were: - Make the code as shared as possible, by using IFDEFs where it makes sense. We've made some progress in this area, with a lot of our code shared, but as you say there is still more to do. Im working on moving the native code around at the moment, so more unification is probably something I will look at at the same time. - Where IFDEFs are starting to make the code difficult to read, split the source up into platform specific files. The kind of layout that could be used for this is described in [2]. I think this matches what you're describing for APR. Do you agree? Im interested to know what kind of build system is used in APR - previous suggestions for picking up platform specific code have included using clever Ant scripts to figure out which file versions are needed, or using gmake and its vpath variable to pick them up (they are described more extensively in [1]). What does APR use to deal with building platform specific versions of files over shared ones? So in the end, the main things to keep in mind are to make your unix implemenation try to work across as many systems as possible, ifdefing based on availability of features as much as you can, not based on specific platforms, and only as a last resort split out into totally different platform specific implementations. IIRC Mark suggested ifdef'ing on features as opposed to platforms before [3], and it seems like a good idea to me, providing a more obvious reason for the existence of the ifdef and allowing us to use ifdefs that describe more than just a ballpark platform distinction. I think in general we have similar ideas to those you describe, but we're not at a point yet where they have been completely embodied in the codebase, or even summarised in a single post/page. Perhaps I will put these ideas together into a page for the classlib section of the Harmony website, so we have something concrete to talk about without digging back into the mail archives. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] building...
Answering Geir's question #3:
compiler, linker and define arguments are specified via compilerarg,
linkerarg, defineset tags respectively
in .xml subcomponents descriptors depending on OS, compiler, configuration.
You can find DRL VM subcomponent descriptors at
enhanced/drlvm/trunk/build/make/components/vm/*.xml
Here're some example extracts from jitrino.xml:
!-- linux specific --
select os=lnx
defineset define=PLATFORM_POSIX /
select cxx=gcc arch=ia32,em64t
compilerarg value=-msse2 /
/select
select cxx=gcc
compilerarg value=-fmessage-length=0 /
compilerarg value=-Wall /
compilerarg value=-Werror /
/select
compilerarg value=-x /
compilerarg value=c++ /
compilerarg value=-fPIC /
select cxx=icc
compilerarg value=-wd68 /
compilerarg value=-wd654 /
compilerarg value=-wd854 /
compilerarg value=-wd470 /
compilerarg value=-wd1572 /
compilerarg value=-wd1125 /
!--
# 470 - 'qualified name is not allowed in member
declaration'
# warning #1125: function xxx is hidden by yyy
- virtual function override intended
# warning #1572: floating-point equality and
inequality comparisons are unreliable
--
/select
select cfg=debug
compilerarg value=-g /
compilerarg value=-O0 /
/select
select cfg=release
compilerarg value=-O /
/select
/select
linker name=${build.cxx} id=linker
select os=win
select arch=ipf
linkerarg value=/MACHINE:IA64 /
/select
select arch=em64t
linkerarg value=/MACHINE:AMD64 /
/select
select arch=ia32
linkerarg value=/MACHINE:X86 /
/select
linkerarg value=/DLL /
linkerarg value=/SUBSYSTEM:WINDOWS /
linkerarg value=/DEBUG /
linkerarg value=/NOLOGO /
linkerarg value=/FIXED:NO /
linkerarg value=/OPT:REF /
linkerarg value=/OUT:${libdir}/ /
libset libs=${vm.vmcore.lib} dir=${vm.vmcore.libdir} /
libset libs=${vm.encoder.lib} dir=${vm.encoder.libdir}
/
/select
select os=lnx
linkerarg value=-shared /
linkerarg value=-ldl /
linkerarg value=-lm /
/select
/linker
--
Denis Sharypov,
Intel Middleware Products Division
Re: [drlvm] building...
Thanks - I figured that out.
It's an interesting difference from makefiles, as they tend to be more
explicit and local - I can go into a directory and look at the
makefile for the params used for building stuff local to that directory.
geir
Denis Sharypov wrote:
Answering Geir's question #3:
compiler, linker and define arguments are specified via compilerarg,
linkerarg, defineset tags respectively
in .xml subcomponents descriptors depending on OS, compiler, configuration.
You can find DRL VM subcomponent descriptors at
enhanced/drlvm/trunk/build/make/components/vm/*.xml
Here're some example extracts from jitrino.xml:
!-- linux specific --
select os=lnx
defineset define=PLATFORM_POSIX /
select cxx=gcc arch=ia32,em64t
compilerarg value=-msse2 /
/select
select cxx=gcc
compilerarg value=-fmessage-length=0 /
compilerarg value=-Wall /
compilerarg value=-Werror /
/select
compilerarg value=-x /
compilerarg value=c++ /
compilerarg value=-fPIC /
select cxx=icc
compilerarg value=-wd68 /
compilerarg value=-wd654 /
compilerarg value=-wd854 /
compilerarg value=-wd470 /
compilerarg value=-wd1572 /
compilerarg value=-wd1125 /
!--
# 470 - 'qualified name is not allowed in member
declaration'
# warning #1125: function xxx is hidden by yyy
- virtual function override intended
# warning #1572: floating-point equality and
inequality comparisons are unreliable
--
/select
select cfg=debug
compilerarg value=-g /
compilerarg value=-O0 /
/select
select cfg=release
compilerarg value=-O /
/select
/select
linker name=${build.cxx} id=linker
select os=win
select arch=ipf
linkerarg value=/MACHINE:IA64 /
/select
select arch=em64t
linkerarg value=/MACHINE:AMD64 /
/select
select arch=ia32
linkerarg value=/MACHINE:X86 /
/select
linkerarg value=/DLL /
linkerarg value=/SUBSYSTEM:WINDOWS /
linkerarg value=/DEBUG /
linkerarg value=/NOLOGO /
linkerarg value=/FIXED:NO /
linkerarg value=/OPT:REF /
linkerarg value=/OUT:${libdir}/ /
libset libs=${vm.vmcore.lib} dir=${vm.vmcore.libdir} /
libset libs=${vm.encoder.lib} dir=${vm.encoder.libdir}
/
/select
select os=lnx
linkerarg value=-shared /
linkerarg value=-ldl /
linkerarg value=-lm /
/select
/linker
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
The most recent success message was 343k at approximately Fri, 09 Jun 06 11:26:34 +0100. -Mark. On 9 June 2006 at 6:33, Geir Magnusson Jr [EMAIL PROTECTED] wrote: A large message should still generate a bounce... I'll go look to see what the size is. How large are these messages? Mark Hindess wrote: On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrote: Hi Tim, On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: I see it too. Stepan / Mikhail, do you get build failures? Shouldn't we stop putting in new code until this is resolved? I didn't update this particular file because I work separately with security module only. But I think that you are right - it'd better to stop putting new code once we get notification that the build is broken. BTW, where is classlib build status emails? I didn't get any notification. I think they are failing to get to the list because they are too large. I tried changing the envelope sender to my gmail account - which is subscribed to the -commits list, but they still don't make the list or generate any bounce messages. I've changed the sender back to [EMAIL PROTECTED] as it was originally. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] what I'm doing...
I'm doing a few things. I've set aside my drive to replace the build for now, and just want to get it using current classlib as a start. To that end, I'm : - tweaking the build to accommodate the structural changes recently made to classlib (hdk et al) - trying to normalize the use of apr (some expect to do apr-/foo.h and some seem to do foo.h - removing the classlib patching and JIRA additions I'll commit once I get it back to stable and we can look at next steps... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
any clue about how big a failed message is (if you can figure that out...)? geir Mark Hindess wrote: The most recent success message was 343k at approximately Fri, 09 Jun 06 11:26:34 +0100. -Mark. On 9 June 2006 at 6:33, Geir Magnusson Jr [EMAIL PROTECTED] wrote: A large message should still generate a bounce... I'll go look to see what the size is. How large are these messages? Mark Hindess wrote: On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrote: Hi Tim, On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: I see it too. Stepan / Mikhail, do you get build failures? Shouldn't we stop putting in new code until this is resolved? I didn't update this particular file because I work separately with security module only. But I think that you are right - it'd better to stop putting new code once we get notification that the build is broken. BTW, where is classlib build status emails? I didn't get any notification. I think they are failing to get to the list because they are too large. I tried changing the envelope sender to my gmail account - which is subscribed to the -commits list, but they still don't make the list or generate any bounce messages. I've changed the sender back to [EMAIL PROTECTED] as it was originally. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what I'm doing...
The patch that accommodate the structural changes recently made to classlib and removing the classlib patching and JIRA additions is ready and will be sent soon. -- Denis Sharypov, Intel Middleware Products Division On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm doing a few things. I've set aside my drive to replace the build for now, and just want to get it using current classlib as a start. To that end, I'm : - tweaking the build to accommodate the structural changes recently made to classlib (hdk et al) - trying to normalize the use of apr (some expect to do apr-/foo.h and some seem to do foo.h - removing the classlib patching and JIRA additions I'll commit once I get it back to stable and we can look at next steps... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
Just about to go offline, but I'd guess smaller since not as much works! ;-) -Mark. On 9 June 2006 at 7:01, Geir Magnusson Jr [EMAIL PROTECTED] wrote: any clue about how big a failed message is (if you can figure that out...)? geir Mark Hindess wrote: The most recent success message was 343k at approximately Fri, 09 Jun 06 11:26:34 +0100. -Mark. On 9 June 2006 at 6:33, Geir Magnusson Jr [EMAIL PROTECTED] wrote: A large message should still generate a bounce... I'll go look to see what the size is. How large are these messages? Mark Hindess wrote: On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrot e: Hi Tim, On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: I see it too. Stepan / Mikhail, do you get build failures? Shouldn't we stop putting in new code until this is resolved? I didn't update this particular file because I work separately with security module only. But I think that you are right - it'd better to stop putting new code on ce we get notification that the build is broken. BTW, where is classlib build status emails? I didn't get any notificatio n. I think they are failing to get to the list because they are too large. I tried changing the envelope sender to my gmail account - which is subscribed to the -commits list, but they still don't make the list or generate any bounce messages. I've changed the sender back to [EMAIL PROTECTED] as it was originally. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what I'm doing...
Sorry, I'm already wading through it. I'll be happy to see it to use for reference though. If someone is going to work on something, please speak up here first. geir Denis Sharypov wrote: The patch that accommodate the structural changes recently made to classlib and removing the classlib patching and JIRA additions is ready and will be sent soon. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] build failure
do you mean larger? I was wondering what the size is so I can see if it's the threshold set on the list, or something else... geir Mark Hindess wrote: Just about to go offline, but I'd guess smaller since not as much works! ;-) -Mark. On 9 June 2006 at 7:01, Geir Magnusson Jr [EMAIL PROTECTED] wrote: any clue about how big a failed message is (if you can figure that out...)? geir Mark Hindess wrote: The most recent success message was 343k at approximately Fri, 09 Jun 06 11:26:34 +0100. -Mark. On 9 June 2006 at 6:33, Geir Magnusson Jr [EMAIL PROTECTED] wrote: A large message should still generate a bounce... I'll go look to see what the size is. How large are these messages? Mark Hindess wrote: On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrot e: Hi Tim, On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: I see it too. Stepan / Mikhail, do you get build failures? Shouldn't we stop putting in new code until this is resolved? I didn't update this particular file because I work separately with security module only. But I think that you are right - it'd better to stop putting new code on ce we get notification that the build is broken. BTW, where is classlib build status emails? I didn't get any notificatio n. I think they are failing to get to the list because they are too large. I tried changing the envelope sender to my gmail account - which is subscribed to the -commits list, but they still don't make the list or generate any bounce messages. I've changed the sender back to [EMAIL PROTECTED] as it was originally. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] building...
On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Thanks - I figured that out. It's an interesting difference from makefiles, as they tend to be more explicit and local - I can go into a directory and look at the makefile for the params used for building stuff local to that directory. Yeah, when I was trying to disect the vm build when it was first released I had similar problems. I wanted to run some of the build commands by hand to see a particular error without running the whole build, but it was very difficult to tell what the final string of arguments were, and once I had them it was difficult to tell what I would have to change to alter them. The other major problem was that when build problems occurred, compiles didn't stop. So if one file blows up because of an issue, the set of warnings in it immediately scroll off the screen and are replaced by hundreds more. On make based systems I'm used to it would stop after the first file, which is much more approachable when debugging. -garrett - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jchevm+classlibadapter] Running classlib tests
Yes, I have done this in VMThread.run() method for newly created threads. But I have seen no way to do this in JNI's ThreadAttach(). Looks like gnu classpath doesn't require any callbacks (like thread_attach()) to be called on the attached thread, so the jchevm doesn't do this. That is why in order to use classlib, this place needs changes in jchevm and it looks like the same applies to all other VMs which use gnu classpath interfaces. That is the problem I am talking about. -- Ivan On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Yes, there are a lot of functions without implementation. I have inserted this exceptions there to fast detect this places. It will also be a few UnsatisfiedLinkErrors for some missing functions in java.lang.reflect.Array. Security is just no-op for now. I have almost zero knowledge in this area. Most probable reason for the hang in two luni tests is bug or unimplemented functionality in Thread.java One of problems in the Thread.java I have no clue how to solve is: Classlib implementation uses its own thread manager implementation, jchevm has also its own. Some classlib's native methods implementation rely on thread_attach() call before them, otherwise they crash. I have implemented this in VMThread.run(). But JNI ThreadAttach in jchevm doesn't call classlib's thread_attach(), so threads attached via JNI will crash classlib. There are requirements on the VM in order to run the classlib native code, like setting up the port library and playing nicely with the thread library. For example, native's monitor operations require that the thread has been attached via hythread_attach() [1]. I don't know the JCHEVM code well enough to point to the right place, but performing an hythread_attach() when a JCHEVM thread is created/attached -- and a matching detach -- would be the answer. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hythread_8c.html?view=co Regards, Tim -- Ivan On 6/8/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 June 2006 at 20:50, Mark Hindess [EMAIL PROTECTED] wrote: With HARMONY-569, HARMONY-572 and a couple of simple hacks - like removing the -showversion jvm arguments from test runs - I've been able to run 63% of the classlib tests. I should get more running with a little more effort. The test results were: Tests FailuresErrors Success rate 5601 360 744 80.29% which is v. impressive. I've improved my wrapper script (linux only sorry) to ignore -showversion and handle -Xbootclasspath/[ap] appropriately. I've attached this to HARMONY-583. I had to exclude two luni tests which were causing the vm to hang: tests/api/java/lang/IllegalThreadStateExceptionTest.java tests/api/java/lang/ThreadTest.java But the new test results are: Tests FailuresErrors Success rate 8348 1295892 73.80% which is progress even though the success rate went down. Many of the failures share the same root causes so I think this figure could improved pretty quickly. I wish there was a tool to summarise the root failures out of 2000+ junit test reports! Just scanning at random, the most common errors seem to be: 1) not implemented java.lang.RuntimeException: not implemented at java.lang.ClassLoader.getResources(ClassLoader.java:224) at org.apache.harmony.jndi.internal.EnvironmentReader.readMultipleResourceFiles (EnvironmentReader.java:227) at org.apache.harmony.jndi.internal.EnvironmentReader$2.run (EnvironmentReader.java:280) at java.security.AccessController.doPrivileged (AccessController.java:241) at org.apache.harmony.jndi.internal.EnvironmentReader.readApplicationResourceFiles (EnvironmentReader.java:278) at javax.naming.InitialContext.internalInit (InitialContext.java:207) at javax.naming.InitialContext.init (InitialContext.java:151) at org.apache.harmony.jndi.tests.javax.naming.InitialContextMockTest.setUp (InitialContextMockTest.java:50) 2) not implemented java.lang.RuntimeException: not implemented at org.apache.harmony.kernel.vm.VM.getNonBootstrapClassLoader(VM.java:77) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1901) at javax.security.auth.SubjectTest.test_PrincipalSetInvalidSerForm (SubjectTest.java:1297) at java.lang.reflect.Method.invokeNative (Method.java) at org.apache.harmony.auth.internal.SecurityTest.runTest (SecurityTest.java:109) 3) Many of the crypto/auth/security tests are failing with implementation not found type errors. 4) META-INF/ALICE.SF has invalid digest for Test.class in /var/tmp/ hyts_resources45209/TestCodeSigners.jar java.lang.SecurityException: META-INF/ALICE.SF has invalid digest for Test.class in /var/tmp/hyts_resources45209/TestCodeSigners.jar at
Re: [classlib] moving to 1.5 for real - discuss
Alexey Petrenko wrote: 2006/6/8, Tim Ellison [EMAIL PROTECTED]: Alexey Petrenko wrote: 2006/6/8, Mikhail Loenko [EMAIL PROTECTED]: what are the benefits? The main benefit for me is to have possibility to use all the 1.5 extensions without any problems. We will need to make this step somewhen anyway since we are going to create 1.5 implementation. The only question from me for now: does all the Harmony VMs (DRLVM, j9, jchevm) support 1.5 version of class files? Exactly. So to answer part of your question : there would need to be a new IBM VME download put on developerworks, but I do not expect that to be a problem. Great! So we need answers from DRLVM and jchevm guys... Archie has expressed the jchevm opinion in favour of the change -- anyone familiar with DRLVM care to comment? (Of course this would be after Geir's VM build work, just asking) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Thanks for this. I'm figuring it out. It's pretty logical once you
start to figure it out in that you can start to guess where things might
be. There seem to be multiple places that would be valid w/
parent-child relationships, but that's no different than make. I don't
like what I'm guessing are constructed properties, like the includes
property in the extra.apr project appears as 'extra.apr.includes
later, which makes searching for where props are originally set somewhat
of a easter-egg hunt...
more inline...
Denis Sharypov wrote:
I would like to give the background on how the build system is designed and
then
give answers for the specific questions.
The build system provided with the VM is designed to be able to build the
whole harmony codebase
no matter how many modules it contains. The intent was to propose it later
as a unified build system
for the Harmony project after receiving the community feedback.
Speaking for myself, I'd personally prefer a much more loosely coupled
build framework, to allow the individual parts of Harmony (drlvm,
jchevm, classlib, tools, etc) the freedom to build in the way best
suited for that part, as determined by the people working on that part.
There has to be some overall federation, such as where generated
artifacts are to be placed when generating a JDK, but I'm hoping that
coupling doesn't have to be tight.
Others agree, disagree?
The main notion the build operates with is a component - a more or less
distinct part of product (vm, classlib, tools, etc).
The benefits are:
- A component can contain several types of source:
C++ sources, C sources, assembler sources, Java* sources, smoke
and unit tests.
- A component can be processed in several ways in the build:
produce native output (shared or static library or executable)
and/or Java* classes in .jar file, produce and run smoke and/or unit
tests.
- One can switch between the different compilers and modes by using
the environment variables, as follows:
On Windows*: | On
Linux*:
-+
MSVC compiler : set CXX=msvc | N/A
Intel(R) compiler : set CXX=icl| export
CXX=icc
GCC compiler : N/A | export
CXX=gcc
Release : set BUILD_CFG=release | export
BUILD_CFG=release
Debug: set BUILD_CFG=debug | export
BUILD_CFG=debug
The build dynamically produces a build_${component}.xml file for
each specific component by taking its descriptor, performing the
attribute-based filtering on it, and then applying target templates
and settings on it.
The README describing how to write a component descriptor can be found at:
harmony/enhanced/drlvm/trunk/README.txt
Now, as a build system for the drlvm (alone), I do think it's a pretty
interesting system - very slick - but I do wonder about the ease at
which we can adapt it to new things as they come along, and how easy new
people can grok it and help out. That last factor is critical.
Here are the answers on questions:
Component-oriented build system is designed to support project layout this
way :
/drlvm/
/classlib/
/tools/
/deploy/
The external resources such as APR, ECLIPSE, CPPTASKS, ZLIB, etc are
described in enhanced/drlvm/trunk/build/make/win.properties and
enhanced/drlvm/trunk/build/make/linux.properties for each system
respectively.
yep - that I know
Each network resource location is configured as follows:
remote.resource name.archive=Resource URL or local path to zip
archive
Which can be overridden through the system environment as follows:
resource name_HOME=extracted archive location
For example, the build takes Eclipse from it's default location on Windows:
remote.ECLIPSE.archive=http://mirrors.cat.pdx.edu/eclipse/eclipse/downloads/drops/R-3.1.1-200509290840/eclipse-JDT-3.1.1.zip
unless the ECLIPSE_HOME is set and points to the Eclipse installation
directory.
The build update command downloads resources only once. It may be
overridden by setting resource name_HOME=extracted archive location
variables.
The build is invokable from above by calling build.bat or build.sh
depending
on the operating system.
It is possible to specify only certain compnent(s) to build:
build.bat -DCOMPONENTS=vm extra classlib
However, currently vm component is rigidly dependent on classlib and will
initiate classlib building. I can't provide the patch to unhook vm and
class
libs today, but please allow a bit more time, and the patch will appear.
Ok - but if we can turn this into a conversation/tutorial here on the
list, that would be better than a patch thrown over the wall. It will
help people learn more about this system...
Re: [jchevm+classlibadapter] Running classlib tests
Ivan Volosyuk wrote: Yes, I have done this in VMThread.run() method for newly created threads. But I have seen no way to do this in JNI's ThreadAttach(). Ah, ok got it. Looks like gnu classpath doesn't require any callbacks (like thread_attach()) to be called on the attached thread, so the jchevm doesn't do this. and to be fair you wouldn't expect them to without reason. That is why in order to use classlib, this place needs changes in jchevm and it looks like the same applies to all other VMs which use gnu classpath interfaces. That is the problem I am talking about. So you either have to think of ways to subvert ThreadAttach() or delay the classlib attachment until it comes into (classlib) native code. Either way sounds like grubby hacks required. Regards, Tim -- Ivan On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Yes, there are a lot of functions without implementation. I have inserted this exceptions there to fast detect this places. It will also be a few UnsatisfiedLinkErrors for some missing functions in java.lang.reflect.Array. Security is just no-op for now. I have almost zero knowledge in this area. Most probable reason for the hang in two luni tests is bug or unimplemented functionality in Thread.java One of problems in the Thread.java I have no clue how to solve is: Classlib implementation uses its own thread manager implementation, jchevm has also its own. Some classlib's native methods implementation rely on thread_attach() call before them, otherwise they crash. I have implemented this in VMThread.run(). But JNI ThreadAttach in jchevm doesn't call classlib's thread_attach(), so threads attached via JNI will crash classlib. There are requirements on the VM in order to run the classlib native code, like setting up the port library and playing nicely with the thread library. For example, native's monitor operations require that the thread has been attached via hythread_attach() [1]. I don't know the JCHEVM code well enough to point to the right place, but performing an hythread_attach() when a JCHEVM thread is created/attached -- and a matching detach -- would be the answer. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hythread_8c.html?view=co Regards, Tim -- Ivan On 6/8/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 June 2006 at 20:50, Mark Hindess [EMAIL PROTECTED] wrote: With HARMONY-569, HARMONY-572 and a couple of simple hacks - like removing the -showversion jvm arguments from test runs - I've been able to run 63% of the classlib tests. I should get more running with a little more effort. The test results were: Tests FailuresErrors Success rate 5601 360 744 80.29% which is v. impressive. I've improved my wrapper script (linux only sorry) to ignore -showversion and handle -Xbootclasspath/[ap] appropriately. I've attached this to HARMONY-583. I had to exclude two luni tests which were causing the vm to hang: tests/api/java/lang/IllegalThreadStateExceptionTest.java tests/api/java/lang/ThreadTest.java But the new test results are: Tests FailuresErrors Success rate 8348 1295892 73.80% which is progress even though the success rate went down. Many of the failures share the same root causes so I think this figure could improved pretty quickly. I wish there was a tool to summarise the root failures out of 2000+ junit test reports! Just scanning at random, the most common errors seem to be: 1) not implemented java.lang.RuntimeException: not implemented at java.lang.ClassLoader.getResources(ClassLoader.java:224) at org.apache.harmony.jndi.internal.EnvironmentReader.readMultipleResourceFiles (EnvironmentReader.java:227) at org.apache.harmony.jndi.internal.EnvironmentReader$2.run (EnvironmentReader.java:280) at java.security.AccessController.doPrivileged (AccessController.java:241) at org.apache.harmony.jndi.internal.EnvironmentReader.readApplicationResourceFiles (EnvironmentReader.java:278) at javax.naming.InitialContext.internalInit (InitialContext.java:207) at javax.naming.InitialContext.init (InitialContext.java:151) at org.apache.harmony.jndi.tests.javax.naming.InitialContextMockTest.setUp (InitialContextMockTest.java:50) 2) not implemented java.lang.RuntimeException: not implemented at org.apache.harmony.kernel.vm.VM.getNonBootstrapClassLoader(VM.java:77) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:1901) at javax.security.auth.SubjectTest.test_PrincipalSetInvalidSerForm (SubjectTest.java:1297) at java.lang.reflect.Method.invokeNative (Method.java) at
Re: [classlib] build failure
Geir Magnusson Jr wrote: do you mean larger? It may be larger if the last test fails with a walkback ;-) but generally the build fails part way through, with a message, and the rest of the log is not written, so it is smaller overall. Regards, Tim I was wondering what the size is so I can see if it's the threshold set on the list, or something else... geir Mark Hindess wrote: Just about to go offline, but I'd guess smaller since not as much works! ;-) -Mark. On 9 June 2006 at 7:01, Geir Magnusson Jr [EMAIL PROTECTED] wrote: any clue about how big a failed message is (if you can figure that out...)? geir Mark Hindess wrote: The most recent success message was 343k at approximately Fri, 09 Jun 06 11:26:34 +0100. -Mark. On 9 June 2006 at 6:33, Geir Magnusson Jr [EMAIL PROTECTED] wrote: A large message should still generate a bounce... I'll go look to see what the size is. How large are these messages? Mark Hindess wrote: On 9 June 2006 at 16:55, Stepan Mishura [EMAIL PROTECTED] wrot e: Hi Tim, On 6/9/06, Tim Ellison [EMAIL PROTECTED] wrote: I see it too. Stepan / Mikhail, do you get build failures? Shouldn't we stop putting in new code until this is resolved? I didn't update this particular file because I work separately with security module only. But I think that you are right - it'd better to stop putting new code on ce we get notification that the build is broken. BTW, where is classlib build status emails? I didn't get any notificatio n. I think they are failing to get to the list because they are too large. I tried changing the envelope sender to my gmail account - which is subscribed to the -commits list, but they still don't make the list or generate any bounce messages. I've changed the sender back to [EMAIL PROTECTED] as it was originally. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Currently two VM subcomponents - vmi and kernel_classes - explicitly depend on classlibs. It's needed to get rid of this and then bootstrap prebuilt harmony classlib while building vm subcomponents. Here're the extracts from the correponding xml descriptors describing dependency: project name=vm.vmi target name=init depends=common_vm property name=build.depends value=classlib.vmi_includes, extra.apr, vm.vmcore, classlib.pool, classlib.zip, classlib.port / project name=vm.kernel_classes target name=init depends=common_vm property name=build.java.depends value=classlib.luni,classlib.security,classlib.archive, classlib.regex,classlib.nio,classlib.nio_char/ -- Denis Sharypov, Intel Middleware Products Division It is possible to specify only certain compnent(s) to build: build.bat -DCOMPONENTS=vm extra classlib However, currently vm component is rigidly dependent on classlib and will initiate classlib building. I can't provide the patch to unhook vm and class libs today, but please allow a bit more time, and the patch will appear. Ok - but if we can turn this into a conversation/tutorial here on the list, that would be better than a patch thrown over the wall. It will help people learn more about this system... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] build -unhook the classlib build and point to the existing in-tree one
Geir Magnusson Jr wrote: snip Denis Sharypov wrote: I would like to give the background on how the build system is designed and then give answers for the specific questions. The build system provided with the VM is designed to be able to build the whole harmony codebase no matter how many modules it contains. The intent was to propose it later as a unified build system for the Harmony project after receiving the community feedback. Speaking for myself, I'd personally prefer a much more loosely coupled build framework, to allow the individual parts of Harmony (drlvm, jchevm, classlib, tools, etc) the freedom to build in the way best suited for that part, as determined by the people working on that part. There has to be some overall federation, such as where generated artifacts are to be placed when generating a JDK, but I'm hoping that coupling doesn't have to be tight. Others agree, disagree? Agreed - IMHO using a build system for each VM or classlib that most suits that particular component makes sense. Classlib currently has a fairly straightforward build system (which could probably be simplified further with some work), and this is good enough for it - it suits all the requirements of that component and is easy to use. DRLVM has a more complex build system, but probably with some justification due to the complexity of the project it is compiling. As long as they produce binaries that can be combined (adhere to the VMI, produced JDK 'shape' is standard etc.) then I dont think it matters if the underlying build systems are the same. Regards, Oliver -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
On 6/9/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Clever trick. But I don't understand why you want to create the Address object at all. hmm... please read my example again. I do not create an Address object. And the call to invokespecial is nop'ed. You can probably just invoke a method of Address to generate an Address object reference, and the method invoke bytecode can be identified by the JIT compiler easily and replaced by a nop or whatever proper. In this way, the Address object reference can be used directly as an object reference, i.e., object pointer. Well actually in what I propose, instances of Address are always an int. Note that the JIT never has GC maps for ints. If I understand vmmagic correctly, instances of Address are only used for pointer arithmetic. They are never used as reference pointers. To use an Address as a reference pointer, you must convert it back to an ObjectReference. Thanks, xiaofeng On 6/9/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, I am hoping someone who has worked on compilers can actually do the JIT modifications. I don't have much experience in compilers. I am trying to get MMTk write barriers integrated into Harmony DRLVM. I came up with the following scheme. I don't know if it is correct. It would be great if someone from the MMTk crowd looked at it. If it helps, I can also post this message on Jikes/MMTk mailing list. Build a shim between the DRLVM class loader and Jitrino.JET. The shim would contain a lookup table that would map _local_ variables of specific types to int. In particular, the shim would re-map local variables of the below types to int: Address Extent Offset Word The reason for the shim is to avoid modifying the class loader. This should reduce the maintenance burden. Java source code that creates objects of the above classes is a now a problem. For example, Java source code that does: int xx = 33; Address a1 = new Address(xx); Translates to the following bytecode: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 Basically the JIT needs to special case new. If it is a new of class Address/Extent/Offset/Word, substitute nop for the new bytecode. If new has been substituted, then replace the following dup with a nop. Leave iload_1 alone. Nop invokespecial. If the new was nop'ed, replace astore_2 with istore_2. The bytecode sequence the JIT really sees is now: bipush 33 istore_1 nop //new //class Address nop // dup iload_1 nop //invokespecial //Method init: (I)V istore_2//astore_2 Another example: int xx = 33; Address a1 = new Address(xx); int kk = a1.toInt(); Translates to bytecode that looks like: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 new code starts here aload_2 invokevirtual //Method toInt(V)I istore_3 All the bytecode down to astore_2 has already been described in the first example. The additional bytecode would be magically remapped by the JIT to: iload_2 // aload_2 nop // invokevirtual//Method toInt(V)I istore_3 Equivalent mappings will be needed for the rest of the methods of class Address as well as Extent, Offset and Word. Will the above work? Thoughts? -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
Ok, actually I meant to write: int xx = 33; Address a1 = Address.creat(xx); so that the bytecode sequence has no stuff for object new. JIT only needs to recognize Address.creat() as an intrinsic for compilation without bytecode rewrite. And yes, I agree that an Address can be only an address in semantics if that's desirable. Thanks, xiaofeng On 6/9/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 6/9/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Clever trick. But I don't understand why you want to create the Address object at all. hmm... please read my example again. I do not create an Address object. And the call to invokespecial is nop'ed. You can probably just invoke a method of Address to generate an Address object reference, and the method invoke bytecode can be identified by the JIT compiler easily and replaced by a nop or whatever proper. In this way, the Address object reference can be used directly as an object reference, i.e., object pointer. Well actually in what I propose, instances of Address are always an int. Note that the JIT never has GC maps for ints. If I understand vmmagic correctly, instances of Address are only used for pointer arithmetic. They are never used as reference pointers. To use an Address as a reference pointer, you must convert it back to an ObjectReference. Thanks, xiaofeng On 6/9/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, I am hoping someone who has worked on compilers can actually do the JIT modifications. I don't have much experience in compilers. I am trying to get MMTk write barriers integrated into Harmony DRLVM. I came up with the following scheme. I don't know if it is correct. It would be great if someone from the MMTk crowd looked at it. If it helps, I can also post this message on Jikes/MMTk mailing list. Build a shim between the DRLVM class loader and Jitrino.JET. The shim would contain a lookup table that would map _local_ variables of specific types to int. In particular, the shim would re-map local variables of the below types to int: Address Extent Offset Word The reason for the shim is to avoid modifying the class loader. This should reduce the maintenance burden. Java source code that creates objects of the above classes is a now a problem. For example, Java source code that does: int xx = 33; Address a1 = new Address(xx); Translates to the following bytecode: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 Basically the JIT needs to special case new. If it is a new of class Address/Extent/Offset/Word, substitute nop for the new bytecode. If new has been substituted, then replace the following dup with a nop. Leave iload_1 alone. Nop invokespecial. If the new was nop'ed, replace astore_2 with istore_2. The bytecode sequence the JIT really sees is now: bipush 33 istore_1 nop //new //class Address nop // dup iload_1 nop //invokespecial //Method init: (I)V istore_2//astore_2 Another example: int xx = 33; Address a1 = new Address(xx); int kk = a1.toInt(); Translates to bytecode that looks like: bipush 33 istore_1 new //class Address dup iload_1 invokespecial //Method init: (I)V astore_2 new code starts here aload_2 invokevirtual //Method toInt(V)I istore_3 All the bytecode down to astore_2 has already been described in the first example. The additional bytecode would be magically remapped by the JIT to: iload_2 // aload_2 nop // invokevirtual//Method toInt(V)I istore_3 Equivalent mappings will be needed for the rest of the methods of class Address as well as Extent, Offset and Word. Will the above work? Thoughts? -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [classlib] moving to 1.5 for real - discuss
So we need answers from DRLVM and jchevm guys... Archie has expressed the jchevm opinion in favour of the change -- anyone familiar with DRLVM care to comment? (Of course this would be after Geir's VM build work, just asking) Regards, Tim DRLVM needs some (minor) changes to support 1.5-targeted classfiles, this is quite easy. Full-fledged implementation of 1.5 kernel classes (annotations, reflection, etc) requires some more efforts but also should not take too long. So +1 from me. Regards, Alexey Varlamov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jchevm+classlibadapter] Running classlib tests
As far as I can see classlib uses port library libprt.so which is intended to be used by VM as low level layer above OS threading system. Some kind of abstraction of underlying OS primitives. The port library is widely used in classlib. The port library data is accessible via TLS (it is done imho to support multi VM environments). To initialize each thread's TLS pointer to the port library the thread_attach() function is needed. -- Ivan On 6/9/06, Archie Cobbs [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Yes, I have done this in VMThread.run() method for newly created threads. But I have seen no way to do this in JNI's ThreadAttach(). Looks like gnu classpath doesn't require any callbacks (like thread_attach()) to be called on the attached thread, so the jchevm doesn't do this. That is why in order to use classlib, this place needs changes in jchevm and it looks like the same applies to all other VMs which use gnu classpath interfaces. That is the problem I am talking about. I haven't looked at the code so these may be questions arising from ignorance.. What native code in classlib requires special thread support and why? Could we simply override those classes and eliminate this need, and just remove (or ignore) the classlib thread stuff? Why can't whatever code uses thread_attach() use the normal JNI methods for thread management instead? JCHEVM should be compatible with any native library that adheres to the JNI spec.. but if it requires other backdoor functions to be supplied by the JVM, then in theory we can eliminate that requirement, because after all normal Classpath doesn't require it and it works just fine. Thanks, -Archie - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] moving to 1.5 for real - discuss
Tim Ellison wrote: Alexey Petrenko wrote: 2006/6/8, Tim Ellison [EMAIL PROTECTED]: Alexey Petrenko wrote: 2006/6/8, Mikhail Loenko [EMAIL PROTECTED]: what are the benefits? The main benefit for me is to have possibility to use all the 1.5 extensions without any problems. We will need to make this step somewhen anyway since we are going to create 1.5 implementation. The only question from me for now: does all the Harmony VMs (DRLVM, j9, jchevm) support 1.5 version of class files? Exactly. So to answer part of your question : there would need to be a new IBM VME download put on developerworks, but I do not expect that to be a problem. Great! So we need answers from DRLVM and jchevm guys... Archie has expressed the jchevm opinion in favour of the change -- anyone familiar with DRLVM care to comment? (Of course this would be after Geir's VM build work, just asking) My intention is to not hold anything up and always have the old build system work, so no need to serialize. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM] one more gc
While some works going on to properly integrate DRLVM in harmony build system... I would like to start development of new garbage collector. I know about Weldon's work related to MMTk. I am not sure that it is the right way. Instead of doing GC based on java, I would concentrate on the one written in C. I think that the VM written in C (or C++ ) should have GC written the same way. I have some experience in garbage collectors (stop-the-world ones for now) and want to extend my knowledge in this area. That is one of the reasons I want to make the GC, but do not port the existing one. I hope I will eventually produce something which is better then existing implementations or at least a few new ideas. I would like to start implementing something similar to Train algorithm, then possibly modify it in direction to Garbage First collector. I want to create something with high performance and low pauses. At the beginning it will not even compile. I do not expect this to be interesting to anyone for some time, but as Geir always suggests I going to do this in public to avoid surprises. All required VM functionality (for GC written in C) is already in place. DRLVM's interfaces for GC is ok for me and should be quite portable. Write barriers implementation is already in place, suitable for C-based Gc: (Harmony-504 (me), Harmony-581 (Ming Wu)). As I don't have commiter account, I going to create one JIRA and start to fill it with patches. In the patches I will create directory enhanced/drlvm/trunk/vm/gcx and will start to fill it with stubs and implementation. I am going to do it mostly at spare time. I hope this doesn't bother anyone. :) -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA summaries
Is there any interest in having summaries of JIRA activity sent to the list once a week? Something like the following perhaps sent to the commits list every Sunday at midnight or something? Regards, Mark Summary of JIRA activity since 2006-06-02 = New --- 11 Fixed 23 Unresolved Updated --- 26 Fixed 4 Unresolved New === Fixed - [HARMONY-554] [classlib][luni-kernel] Java 5 Updates for Class, Package and Thread [HARMONY-555] Missing s/w for linux build of harmony [HARMONY-556] [classlib][luni] TreeMap and TreeSet generification [HARMONY-559] [classlib][luni] new classes java.util.AbstractQueue [HARMONY-561] Modularise native include directories [HARMONY-562] [rmi2.1.4] removing commented out call now we have Timer.purge [HARMONY-563] Java 5 Enhancement: java.util.Properties should implement methods loadFromXML, storeToXML. [HARMONY-567] [classlib][luni] java.util.Scanner constructors not implemented [HARMONY-571] [classlib] [beans] [HARMONY-576] Keytool - first contribution. Files with stubs. [HARMONY-577] [classlib][util] java.util.zip.ZipOutputStream.write(byte[] ) doesn't throw IOException if an entry is not set Unresolved -- [HARMONY-557] [classlib] Update build scripts to use JUnit 3.8.1 [HARMONY-558] [classlib] Update build scripts to use Eclipse JDT 3.2RC7 compiler [HARMONY-560] Use mx4j for javax.management [HARMONY-564] Scripts to generate test coveragte report using Emma and Ant [HARMONY-565] Application class coverage checking scripts [HARMONY-566] NASM port of assembly parts of win32 code in hythreads [HARMONY-568] Bug in java.net.InetSocketAddress serialization [HARMONY-569] [classlibadapter] System.setOut/setErr implementation [HARMONY-570] [classlib] HttpURLConnection does not use proxy [HARMONY-572] [classlibadapter] implement Package.isSealed methods [HARMONY-573] Implementation of ThreadLocal support in Thread [HARMONY-574] [classlib][util] Java 5 Enhancement:new class java.util.PriorityQueue [HARMONY-575] [classlib][tesing] Refactor ByteBuffer testcases in org.apache.harmony.tests.java.nio [HARMONY-578] [classlib][nio] NIO should provide some utility classes for the JNI 1.4 enhancement [HARMONY-579] [jchevm] trivial memory leak when command line arguments are replaced/ignored [HARMONY-580] [classlib][regex][perf] Lookaround matching is slow [HARMONY-581] Write barrier patch for jet in drlvm [HARMONY-582] java.nio.channels.Selector.open() returns null [HARMONY-583] [classlibadapter] fake java wrapper to enable classlib tests to be run [HARMONY-584] missing descriptions in @param tags [HARMONY-585] [jchevm] minimal 1.5 class file support [HARMONY-586] Keytool - added parameter and options declarations and commands enum. [HARMONY-587] [classlib][security] Split impl vs. api tests Updated === Fixed - [HARMONY-199] Contribution of javax.crypto and java.math [HARMONY-421] java.beans.VetoableChangeSupport.readObject() throws unexpected ClassCastException [HARMONY-438] DRL Virtual Machine contribution [HARMONY-481] PKCS7 SignedData is not designed to be encoded [HARMONY-515] [classlib][luni] java.io: missing 8 methods and 4 constructors in PrintWriter and PrintStream. [HARMONY-516] [classlib] [beans] java.beans.PropertyEditorSupport.getAsText() throws unexpected ClassCastException [HARMONY-522] java.util.Scanner is not implemented in Harmony [HARMONY-524] [classlib][luni-kernel] java.lang.reflect Field and Method generification [HARMONY-525] [classlib][luni] Misc Collections Generification [HARMONY-527] [classlib][text] java.text.AttributedString.addAttribute() incorrectly handles null value. [HARMONY-531] [classlib] CertificateFactory source files are poorly documented [HARMONY-533] Java 5 Enhancement: util.Arrays should implement deepHashCode, deepEquals, hashCode(*) methods. [HARMONY-537] [classlib] X.509 CertificateFactory implementation does not support PKCS7 Data [HARMONY-538] Windows native clean target does not clean all produced files [HARMONY-539] ArrayList.addAll(0, ...) index out of bounds exception [HARMONY-540] [classlib][text] Method applyPattern(String) of java.text.ChoiceFormat incorrectly throws IllegalArgumentException. [HARMONY-542] [classlib][luni] Misc java.util Generifications [HARMONY-543] javax.naming.spi generifications [HARMONY-544] javax.naming.ldap generifications [HARMONY-545] javax.naming.directory generifications [HARMONY-546] javax.naming generifications [HARMONY-548] upgrade to xerces 2.8.0 and xalan 2.7.0 [HARMONY-549] [classlib][nio-channels]
Re: svn commit: r413113 - in /incubator/harmony/enhanced/drlvm/trunk/build/make: components/extra/apr.xml components/extra/aprutil.xml components/extra/log4cxx.xml targets/common_classlib.xml
On 9 June 2006 at 18:06, [EMAIL PROTECTED] wrote:
Author: geirm
Date: Fri Jun 9 11:06:17 2006
New Revision: 413113
URL: http://svn.apache.org/viewvc?rev=413113view=rev
Log:
tweaks to stop the apr-1/foo.h stuff, and
just do foo.h for APR includes. Not a big deal
but let me get more comfortable w/ the build.
No functional changes.
Code change commit will follow
[ snipped, good stuff cleaning up includes. ]
There are issues like this with the awt/swing contribution (see
HARMONY-534) doing includes in non-standard and even in a way that broke
the build for me. I think it is a big deal to use header files in the
way that is intended/common.
...
Modified: incubator/harmony/enhanced/drlvm/trunk/build/make/targets/common_cl
asslib.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/buil
d/make/targets/common_classlib.xml?rev=413113r1=413112r2=413113view=diff
=
=
--- incubator/harmony/enhanced/drlvm/trunk/build/make/targets/common_classlib
.xml (original)
+++ incubator/harmony/enhanced/drlvm/trunk/build/make/targets/common_classlib
.xml Fri Jun 9 11:06:17 2006
@@ -75,6 +75,13 @@
compiler id=common.compiler
!--common for cpp and c--
includepath
+
+!-- $$$ geirm for what's coming...
+pathelement location=${build.CLASSLIB.home}/deploy/include
/
+pathelement location=${build.CLASSLIB.home}/deploy/jdk/inc
lude /
+pathelement location=${build.CLASSLIB.home}/modules/luni/s
rc/main/native/include/shared /
I don't think you should need this last one. Any header is intended to
define a public interface to the luni module should have been copied to
deploy/include by the build. If you need to point in to the module,
then we might have a discrepancy about what is public/private that needs
addressing.
-Mark.
+--
pathelement location=${os.native.dir}/include /
pathelement location=${shared.dir}/include /
pathelement location=${common.src} /
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] moving to 1.5 for real - discuss
Alexey Varlamov wrote: So we need answers from DRLVM and jchevm guys... Archie has expressed the jchevm opinion in favour of the change -- anyone familiar with DRLVM care to comment? (Of course this would be after Geir's VM build work, just asking) Regards, Tim DRLVM needs some (minor) changes to support 1.5-targeted classfiles, this is quite easy. Full-fledged implementation of 1.5 kernel classes (annotations, reflection, etc) requires some more efforts but also should not take too long. Understood, I wasn't expecting those to be working -- just the effort to let DRLVM grok the v49 files. So +1 from me. Well it isn't a formal vote, but glad to see you are in favor too. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] update - removed apr-1 in includes
I just did a small checkin of minor mods of the current build system and VM source that changes how the APR headers are treated. It's a simple, minor change #include apr-1/apr.h becomes #include apr.h the real benefit is that I learned a bit more about how the build stuff works :) I've only tested under windows - it builds and passes all tests. I'll try linux too at some point unless someone beats me to it. Next, I'm going to try to switch to the current version of classlib. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
I promise that if we need logging then I'll personally volunteer to uncomment those same lines, and let Alexei make fun of me while saying 'I told you so'. in Russian. I can do it in several languages of your choice (Russian, English, Japanese) if this helps to resolve the situation with logging. :) 2006/6/9, Geir Magnusson Jr [EMAIL PROTECTED]: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Resurrecting this thread, with some trepidation... We went round the houses a bit, but did we reach a conclusion to the questions you posed? Sadly, no, it doesn't seem so. I was hoping that Aspect-Master-George might give us some hints... I'm eager to fix-up the DNS provider code. Is there something driving that other than the desire to put it to bed? (Just curious) Can you just comment the stuff out? (or I can - I'll be happy to) Ok, so here goes... I shall leave the logging statements in place but comment them out (so they are easy to replace if we decide we can't live without them, or indeed that all classlib code should contain logging) and I will remove the o.a.h.util.logging.LogConst type from the JNDI module. Oh, o.a.h.util.logging.LogConst... we barely knew ye I promise that if we need logging then I'll personally volunteer to uncomment those same lines, and let Alexei make fun of me while saying 'I told you so'. in Russian. geir Regards, Tim -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r413114 - in /incubator/harmony/enhanced/drlvm/trunk/vm: em/src/ gc/src/ include/ include/open/ port/include/ port/include/tl/ port/src/disasm/linux/ port/src/disasm/win/ port/src/file
Oh geeze. How embarassing. I assume you fixed?
(I was going to flip to my VMWare Ubuntu VMM but it's too slow. I have
a second laptop I will install Ubuntu on, but don't have enough Round
Tuits...)
geir
Mark Hindess wrote:
On 9 June 2006 at 18:09, [EMAIL PROTECTED] wrote:
Author: geirm
Date: Fri Jun 9 11:09:16 2006
New Revision: 413114
URL: http://svn.apache.org/viewvc?rev=413114view=rev
Log:
tweaks to stop the apr-1/foo.h stuff, and
just do foo.h for APR includes. Not a big deal
but let me get more comfortable w/ the build.
No functional changes.
Tests pass on winxp. Linux not tested yet
Testing at the moment... I did find ...
Modified: incubator/harmony/enhanced/drlvm/trunk/vm/port/src/misc/linux/dso.c
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/p
ort/src/misc/linux/dso.c?rev=413114r1=413113r2=413114view=diff
=
=
--- incubator/harmony/enhanced/drlvm/trunk/vm/port/src/misc/linux/dso.c (orig
inal)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/port/src/misc/linux/dso.c Fri J
un 9 11:09:16 2006
@@ -19,9 +19,9 @@
*/
#include dlfcn.h
-#include stdlib.h
-#include apr-1/apr_dso.h
-#include apr-1/apr_strings.h
+#include stdliapr_dso.h
+#include b.h
+#include apr_strings.h
#include port_dso.h
struct apr_dso_handle_t {
which I fixed.
Still compiling ... will let you know if there are any other issues.
-Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problems with builth path!
After you've got everything built and you have the PDE's Target Platform pointing at the 'deploy\jdk\jre\lib\boot' folder you should just need to add the luni-kernel-stubs.jar to your build path. Most of the dependencies should be resolved as Plug-in Dependencies. You'll also need to add the 'build\tests' as a class folder so that the tests can compile. I usually do this by creating a new linked folder. -Nathan -Original Message- From: Bidea Cristian [mailto:[EMAIL PROTECTED] Sent: Friday, June 09, 2006 4:11 PM To: harmony-dev@incubator.apache.org Subject: Problems with builth path! Hello to everyone I've tried setting up my Eclipse environment for working on Harmony (at list trying) and I faced a problem. I've compiled the classpath and I've installed the VM from IBM. After that I've started Eclipse, after putting the required options in eclipse.ini, setting everything and checking it twice. When I checkout a module from repository I keep getting the same error at build: Severity and Description The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Object. Fix the build path then try building this project I'm not sure what should I include in the path or what am I doing wrong. In Eclipse in the Java Build Path menu I have only the option to include jars. I even tried to put everything from the Harmony/build directory into a jar and after that including it into java build path but it generated even more errors. I'm using Eclipse 3.2RC7. Thanks, Cristian - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] proposal - resolution to java.util.concurrent issue
-Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: I had a nice chat with Doug today to try to reach a conclusion regarding j.u.c Given that everyone else (Sun, IBM, BEA...) seems to use j.u.c, found here http://gee.cs.oswego.edu/cgi- bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ I think that we'd be well-served to do so as well. It's the RI, it's complicated, it goes w/o saying that Doug is committed to this being right, and I'd like to have the same bugs as everyone else for now :) The summary of what I think we should do is simple - we take the code from j.u.c from the above link (w/ 1 exception) into our SVN repo and track any changes made by Doug and the jsr166 EG going forward. So I understand correctly, are you talking about taking the source code into Harmony SVN, or creating a dependency on a binary version of that code (stored in our SVN)? Into our SVN, simply for ease of use, oversight, and control. Can you expand on that for me? Why isn't a binary dependency sufficient? It would be if there was one. As far as I can tell, there isn't. There also may be small mods required to work w/ our VMI. Dunno - hopefully Nathan or others can tell us. There was one binary, but it seemed more like an experimental build of new stuff. As for the code, there will have to be some modifications to work with our VMI. The java.util.concurrent classes are clean, but the 'atomic' and 'locks' packages are filled with references to a Sun proprietary class, that we would have to replace. For example, check out the AtomicBoolean class [1]. [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/atomic/AtomicBoolean.java?rev=1.20content-type=text/vnd.viewcvs-marku p What's the problem with having the source around? It makes it easier for people to look at, debug, etc... Just trying to figure the rationale of taking source if the goal is to be in lock-step. Are you imagining that there may be patches created here that are ALv2'd only (and maybe therefore do not go back into Doug's copy)? It could be, although given how it seems to be working, I would guess we'd work with Doug if there were problems, and see if he'd do it into the RI. All the code is under the following terms, which are acceptable to the ASF : /* * Written by Doug Lea with assistance from members of JCP JSR-166 * Expert Group and released to the public domain, as explained at * http://creativecommons.org/licenses/publicdomain */ except for one file : http://gee.cs.oswego.edu/cgi- bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList. java for which I understand we can get a clean replacement from the backport. Now, there is an issue of our clean-room rules, and I think there's a very neat solution that would allow us to use this code w/o getting an ACQ from the authors of j.u.c (which Doug claims is himself, assisted by the JSR166 EG) The premise of our ACQ structure is that we want to ensure that people who have worked on a non-open/non-free implementation of a portion/module/component of Java not work on our implementation of that portion/module/component. Now, given that j.u.c in Java SE 5 is the first time this functionality has existed, it must be the case that the contributors are not contaminated by working on another implementation, since there are no other implementations. We can't be contaminated because there's nothing with which to contaminate us with. AIUI (and hypothetically) people could take a copy of the public domain code and create a proprietary derivative couldn't they? And the spec is out there for all to see, how do you know there are no other implementations? There could be implementations out there now, but there weren't before, and we'd just have to watch to see what gets added down the road... I assume that the authors (jsr166-group) have a good knowledge of all sorts of code that is in our ACQ CORE bucket. The need not only be 'contaminated' by concurrent. Right, but unless you believe that by knowing about code in our CORE bucket that isn't j.u.c yet somehow tainted j.u.c, shouldn't we just add a new 'bucket' for j.u.c to solve what would then simply be a paper problem? (I would like to see this, I'm still just thinking it through). This is a good and reasonable discussion to have. I'm just working the Pragmatic Devil's Advocate line here... geir Regards, Tim That is the gate I was talking about - we are still overseeing what we're distributing... Of course, this needs VM support, so there is work to do, but this seems like a sane and clean way to add this functionality to Harmony classlib, as well as build a bridge to another
Re: Problems with builth path!
Yep, in fact recent builds of Eclipse can cope with the kernel jars if you specify -Dpde.allowCycles=true as well as -Dpde.jreProfile=none on the launch-line. (We should plan to put the stubs and tests support jars into the HDK when we get there, but yes, in the meantime link/load it into the workspace/target) Regards, Tim Nathan Beyer wrote: After you've got everything built and you have the PDE's Target Platform pointing at the 'deploy\jdk\jre\lib\boot' folder you should just need to add the luni-kernel-stubs.jar to your build path. Most of the dependencies should be resolved as Plug-in Dependencies. You'll also need to add the 'build\tests' as a class folder so that the tests can compile. I usually do this by creating a new linked folder. -Nathan -Original Message- From: Bidea Cristian [mailto:[EMAIL PROTECTED] Sent: Friday, June 09, 2006 4:11 PM To: harmony-dev@incubator.apache.org Subject: Problems with builth path! Hello to everyone I've tried setting up my Eclipse environment for working on Harmony (at list trying) and I faced a problem. I've compiled the classpath and I've installed the VM from IBM. After that I've started Eclipse, after putting the required options in eclipse.ini, setting everything and checking it twice. When I checkout a module from repository I keep getting the same error at build: Severity and Description The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Object. Fix the build path then try building this project I'm not sure what should I include in the path or what am I doing wrong. In Eclipse in the Java Build Path menu I have only the option to include jars. I even tried to put everything from the Harmony/build directory into a jar and after that including it into java build path but it generated even more errors. I'm using Eclipse 3.2RC7. Thanks, Cristian - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
