Adds: [general] Dynamic class loading
This tool will not require modification of any code of existing VMs and should works on any JDK. java.system.class.loader system property should exists in any JDK (see http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html#getSystemClassLoader ). I have not found any similar tool in internet. JSP can't be used: because web server should be run, JSP has different syntax and semantics, JSP has different versions, need to use java compiler, etc. I think this tool may be very simple to implement, because many lines of code have been already written: it is URLCLassLoader. What do you think about separate tool in Apache? Nikolay Chugunov Intel Middleware Products Division -- Forwarded message -- From: Nikolay Chugunov [EMAIL PROTECTED] Subject: [general] Dynamic class loading To: harmony-dev@incubator.apache.org From the beginning of learning Java and till now I hate to compile java source code before run it. I propose to develop easy solution for this problem: compile java sources on fly. Command to do it can look like: java –cp …:mytool.jar -Djava.system.class.loader=classloader.MyClassLoaderHelloWorld When executing any application, if MyClassLoader does not find compiled class in class path, it will try to find file-source of this class with java extension in class path. If MyClassLoader finds this file, then MyClassLoader will compile source on fly and load class to MyClassLoader using *defineClass* method. The second improvement which I propose to develop is to load jar file from internet, if user specify URL to jar file in command line. MyClassLoader may cache compiled classes and loaded jars. MyClassLoader may use standard and Eclipse compiler to compile sources. Also MyClassLoader may compile on fly other sources (like Jasmin). The base of my tool will be existing URLClassLoader in Harmony. What do you think about my proposals? Nikolay Chugunov
Re: Adds: [general] Dynamic class loading
I wonder if it would be something cool for Apache Jakarta Commons? geir Nikolay Chugunov wrote: This tool will not require modification of any code of existing VMs and should works on any JDK. java.system.class.loader system property should exists in any JDK (see http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html#getSystemClassLoader ). I have not found any similar tool in internet. JSP can't be used: because web server should be run, JSP has different syntax and semantics, JSP has different versions, need to use java compiler, etc. I think this tool may be very simple to implement, because many lines of code have been already written: it is URLCLassLoader. What do you think about separate tool in Apache? Nikolay Chugunov Intel Middleware Products Division -- Forwarded message -- From: Nikolay Chugunov [EMAIL PROTECTED] Subject: [general] Dynamic class loading To: harmony-dev@incubator.apache.org From the beginning of learning Java and till now I hate to compile java source code before run it. I propose to develop easy solution for this problem: compile java sources on fly. Command to do it can look like: java –cp …:mytool.jar -Djava.system.class.loader=classloader.MyClassLoaderHelloWorld When executing any application, if MyClassLoader does not find compiled class in class path, it will try to find file-source of this class with java extension in class path. If MyClassLoader finds this file, then MyClassLoader will compile source on fly and load class to MyClassLoader using *defineClass* method. The second improvement which I propose to develop is to load jar file from internet, if user specify URL to jar file in command line. MyClassLoader may cache compiled classes and loaded jars. MyClassLoader may use standard and Eclipse compiler to compile sources. Also MyClassLoader may compile on fly other sources (like Jasmin). The base of my tool will be existing URLClassLoader in Harmony. What do you think about my proposals? Nikolay Chugunov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][lang] AbstractStringBuilder, abstract class?
On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:
An interesting side note: The Serialized Form documentation gives away
an
implementation detail of StringBuffer and StringBuilder, in that they both
extend from an AbstractStringBuilder. This might be an interesting
approach
to consolidate those code paths.
Spec lies sometimes? The spec of StringBuilder and StringBuffer claim the
superclass of them is java.lang.Object, but the serialized form tells the
truth - they extend from java.lang.AbstractStringBuilder, which is not
public.
I picked up this thread again because I found an existing application failed
against Harmony because of this problem. The scenario is:
1. application runs on jdk1.1
2. new instances of some classes. If a class has superclass, then new an
instance of superclass too if it's not abstract or an interface. The
pseudo-code looks like:
newAllInstances(Class clazz) {
if(clazz == null) return;
if (clazz is abstract or an interface) return;
new an instance of clazz;
newAllInstances(clazz.getSuperClass());
}
The test data includes some instances of StringBuffer. The application fails
against Harmony because AbstractStringBuilder is a concrete class but not
public. The application runs well against sun jdk 1.5 (Although all code are
based on jdk1.1) because the superclass is abstract.
So is it a reason to change the signature of class AbstractStringBuilder?
Make it as abstract really as the name suggests?
Thanks!
[1]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuilder
[2]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuffer
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 3:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Nathan,
First, let me say a big thank you for the code and tests you submitted.
I've had a chance to read through it and (beyond the comments below) it
looks good.
I've committed a modified version of your patch to SVN. However, ;-)
1. I've removed the javadoc comments as these appear to be direct
copies of the Sun documentation. We cannot copy Sun's property. For
now the comments have been replaced with TODO tags.
2. I've removed the .intern() from the string literals, since these
will be interned by the VM anyway.
3. Why have you got transient char[] and int fields, and then serialize
them (as int, char[])? Wouldn't it be easier to reorder the fields and
remove the readObject/writeObject methods?
Thanks again for your work,
Tim
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison resolved HARMONY-103:
-
Resolution: Fixed
Nathan,
Thanks for the patch, it has been applied (minus javadoc) at repo
revision
379882.
Please check that it has been applied as you expected.
java.lang.StringBuilder Implementation for LUNI
---
Key: HARMONY-103
URL: http://issues.apache.org/jira/browse/HARMONY-103
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Nathan Beyer
Assignee: Tim Ellison
Attachments: StringBuilder.java, StringBuilderTest.java
This bug is for submitting an implementation of the
java.lang.StringBuilder to the LUNI module of classlib. The implementation
and class definition is based on the specification at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
The implementation is not complete, there are a few method that are
either incomplete or not implemented. All of these are related to the
Unicode Code Point support, as defined by Java 5. As for the rest of the
implementation, there are probably a number of optimization points, but
the
focus was to complete the functionality and make it compatible with
various
Java 5 runtimes.
Additionally, I had a problem with compiling this class in Eclipse
3.1.2.
When I set the compiler to Java 1.4 compliance level, the methods which
implement the Appendable interface cause compilation errors. When I set
the
compiler to Java 5.0 compliance with Java 1.4 .class file compatability
and
Java 1.4 source compatibility, the class compiled fine. I'm not sure if
this
is quirk of the JDT compiler or what, but I'm going to do some
investigation
and testing to see if I can isolate it.
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Best regards,
Andrew Zhang
Re: [classlib][lang] AbstractStringBuilder, abstract class?
sounds reasonable, but don't go based on my word, of course.
Interesting question is why AbstractStringBuilder isn't abstract...
Andrew Zhang wrote:
On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:
An interesting side note: The Serialized Form documentation gives away
an
implementation detail of StringBuffer and StringBuilder, in that they
both
extend from an AbstractStringBuilder. This might be an interesting
approach
to consolidate those code paths.
Spec lies sometimes? The spec of StringBuilder and StringBuffer claim the
superclass of them is java.lang.Object, but the serialized form tells the
truth - they extend from java.lang.AbstractStringBuilder, which is not
public.
I picked up this thread again because I found an existing application
failed
against Harmony because of this problem. The scenario is:
1. application runs on jdk1.1
2. new instances of some classes. If a class has superclass, then new an
instance of superclass too if it's not abstract or an interface. The
pseudo-code looks like:
newAllInstances(Class clazz) {
if(clazz == null) return;
if (clazz is abstract or an interface) return;
new an instance of clazz;
newAllInstances(clazz.getSuperClass());
}
The test data includes some instances of StringBuffer. The application
fails
against Harmony because AbstractStringBuilder is a concrete class but not
public. The application runs well against sun jdk 1.5 (Although all code
are
based on jdk1.1) because the superclass is abstract.
So is it a reason to change the signature of class AbstractStringBuilder?
Make it as abstract really as the name suggests?
Thanks!
[1]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuilder
[2]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuffer
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 3:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Nathan,
First, let me say a big thank you for the code and tests you submitted.
I've had a chance to read through it and (beyond the comments below) it
looks good.
I've committed a modified version of your patch to SVN. However, ;-)
1. I've removed the javadoc comments as these appear to be direct
copies of the Sun documentation. We cannot copy Sun's property. For
now the comments have been replaced with TODO tags.
2. I've removed the .intern() from the string literals, since these
will be interned by the VM anyway.
3. Why have you got transient char[] and int fields, and then serialize
them (as int, char[])? Wouldn't it be easier to reorder the fields and
remove the readObject/writeObject methods?
Thanks again for your work,
Tim
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison resolved HARMONY-103:
-
Resolution: Fixed
Nathan,
Thanks for the patch, it has been applied (minus javadoc) at repo
revision
379882.
Please check that it has been applied as you expected.
java.lang.StringBuilder Implementation for LUNI
---
Key: HARMONY-103
URL: http://issues.apache.org/jira/browse/HARMONY-103
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Nathan Beyer
Assignee: Tim Ellison
Attachments: StringBuilder.java, StringBuilderTest.java
This bug is for submitting an implementation of the
java.lang.StringBuilder to the LUNI module of classlib. The
implementation
and class definition is based on the specification at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
The implementation is not complete, there are a few method that are
either incomplete or not implemented. All of these are related to the
Unicode Code Point support, as defined by Java 5. As for the rest of the
implementation, there are probably a number of optimization points, but
the
focus was to complete the functionality and make it compatible with
various
Java 5 runtimes.
Additionally, I had a problem with compiling this class in Eclipse
3.1.2.
When I set the compiler to Java 1.4 compliance level, the methods which
implement the Appendable interface cause compilation errors. When I set
the
compiler to Java 5.0 compliance with Java 1.4 .class file compatability
and
Java 1.4 source compatibility, the class compiled fine. I'm not sure if
this
is quirk of the JDT compiler or what, but I'm going to do some
investigation
and testing to see if I can isolate it.
--
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]
[party] who's coming to apachecon, raise their hands!
I am! -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [party] who's coming to apachecon, raise their hands!
I am! I have a session on wed, and we have a harmony BOF wed night. geir Stefano Mazzocchi wrote: I am! - 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][lang] AbstractStringBuilder, abstract class?
2006/10/7, Geir Magnusson Jr. [EMAIL PROTECTED]:
sounds reasonable, but don't go based on my word, of course.
Interesting question is why AbstractStringBuilder isn't abstract...
It does not really matters from implementation POV, and the name was
just chosen after the RI - sorta be deeply compatible. But indeed we
missed abstract modifier, which is also quite reasonable as a
precaution for undocumented exploitation.
Let's fix this.
Andrew Zhang wrote:
On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:
An interesting side note: The Serialized Form documentation gives away
an
implementation detail of StringBuffer and StringBuilder, in that they
both
extend from an AbstractStringBuilder. This might be an interesting
approach
to consolidate those code paths.
Spec lies sometimes? The spec of StringBuilder and StringBuffer claim the
superclass of them is java.lang.Object, but the serialized form tells the
truth - they extend from java.lang.AbstractStringBuilder, which is not
public.
I picked up this thread again because I found an existing application
failed
against Harmony because of this problem. The scenario is:
1. application runs on jdk1.1
2. new instances of some classes. If a class has superclass, then new an
instance of superclass too if it's not abstract or an interface. The
pseudo-code looks like:
newAllInstances(Class clazz) {
if(clazz == null) return;
if (clazz is abstract or an interface) return;
new an instance of clazz;
newAllInstances(clazz.getSuperClass());
}
The test data includes some instances of StringBuffer. The application
fails
against Harmony because AbstractStringBuilder is a concrete class but not
public. The application runs well against sun jdk 1.5 (Although all code
are
based on jdk1.1) because the superclass is abstract.
So is it a reason to change the signature of class AbstractStringBuilder?
Make it as abstract really as the name suggests?
Thanks!
[1]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuilder
[2]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuffer
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 3:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Nathan,
First, let me say a big thank you for the code and tests you submitted.
I've had a chance to read through it and (beyond the comments below) it
looks good.
I've committed a modified version of your patch to SVN. However, ;-)
1. I've removed the javadoc comments as these appear to be direct
copies of the Sun documentation. We cannot copy Sun's property. For
now the comments have been replaced with TODO tags.
2. I've removed the .intern() from the string literals, since these
will be interned by the VM anyway.
3. Why have you got transient char[] and int fields, and then serialize
them (as int, char[])? Wouldn't it be easier to reorder the fields and
remove the readObject/writeObject methods?
Thanks again for your work,
Tim
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison resolved HARMONY-103:
-
Resolution: Fixed
Nathan,
Thanks for the patch, it has been applied (minus javadoc) at repo
revision
379882.
Please check that it has been applied as you expected.
java.lang.StringBuilder Implementation for LUNI
---
Key: HARMONY-103
URL: http://issues.apache.org/jira/browse/HARMONY-103
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Nathan Beyer
Assignee: Tim Ellison
Attachments: StringBuilder.java, StringBuilderTest.java
This bug is for submitting an implementation of the
java.lang.StringBuilder to the LUNI module of classlib. The
implementation
and class definition is based on the specification at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
The implementation is not complete, there are a few method that are
either incomplete or not implemented. All of these are related to the
Unicode Code Point support, as defined by Java 5. As for the rest of the
implementation, there are probably a number of optimization points, but
the
focus was to complete the functionality and make it compatible with
various
Java 5 runtimes.
Additionally, I had a problem with compiling this class in Eclipse
3.1.2.
When I set the compiler to Java 1.4 compliance level, the methods which
implement the Appendable interface cause compilation errors. When I set
the
compiler to Java 5.0 compliance with Java 1.4 .class file compatability
and
Java 1.4 source compatibility, the class compiled fine. I'm not sure if
this
is quirk of the JDT compiler or what, but
Re: [classlib][lang] AbstractStringBuilder, abstract class?
Seems like it was just a oversight. I can check in a fix.
-Nathan
On 10/7/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/7, Geir Magnusson Jr. [EMAIL PROTECTED]:
sounds reasonable, but don't go based on my word, of course.
Interesting question is why AbstractStringBuilder isn't abstract...
It does not really matters from implementation POV, and the name was
just chosen after the RI - sorta be deeply compatible. But indeed we
missed abstract modifier, which is also quite reasonable as a
precaution for undocumented exploitation.
Let's fix this.
Andrew Zhang wrote:
On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:
An interesting side note: The Serialized Form documentation gives away
an
implementation detail of StringBuffer and StringBuilder, in that they
both
extend from an AbstractStringBuilder. This might be an interesting
approach
to consolidate those code paths.
Spec lies sometimes? The spec of StringBuilder and StringBuffer claim the
superclass of them is java.lang.Object, but the serialized form tells the
truth - they extend from java.lang.AbstractStringBuilder, which is not
public.
I picked up this thread again because I found an existing application
failed
against Harmony because of this problem. The scenario is:
1. application runs on jdk1.1
2. new instances of some classes. If a class has superclass, then new an
instance of superclass too if it's not abstract or an interface. The
pseudo-code looks like:
newAllInstances(Class clazz) {
if(clazz == null) return;
if (clazz is abstract or an interface) return;
new an instance of clazz;
newAllInstances(clazz.getSuperClass());
}
The test data includes some instances of StringBuffer. The application
fails
against Harmony because AbstractStringBuilder is a concrete class but not
public. The application runs well against sun jdk 1.5 (Although all code
are
based on jdk1.1) because the superclass is abstract.
So is it a reason to change the signature of class AbstractStringBuilder?
Make it as abstract really as the name suggests?
Thanks!
[1]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuilder
[2]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuffer
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 3:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Nathan,
First, let me say a big thank you for the code and tests you submitted.
I've had a chance to read through it and (beyond the comments below) it
looks good.
I've committed a modified version of your patch to SVN. However, ;-)
1. I've removed the javadoc comments as these appear to be direct
copies of the Sun documentation. We cannot copy Sun's property. For
now the comments have been replaced with TODO tags.
2. I've removed the .intern() from the string literals, since these
will be interned by the VM anyway.
3. Why have you got transient char[] and int fields, and then serialize
them (as int, char[])? Wouldn't it be easier to reorder the fields and
remove the readObject/writeObject methods?
Thanks again for your work,
Tim
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison resolved HARMONY-103:
-
Resolution: Fixed
Nathan,
Thanks for the patch, it has been applied (minus javadoc) at repo
revision
379882.
Please check that it has been applied as you expected.
java.lang.StringBuilder Implementation for LUNI
---
Key: HARMONY-103
URL: http://issues.apache.org/jira/browse/HARMONY-103
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Nathan Beyer
Assignee: Tim Ellison
Attachments: StringBuilder.java, StringBuilderTest.java
This bug is for submitting an implementation of the
java.lang.StringBuilder to the LUNI module of classlib. The
implementation
and class definition is based on the specification at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
The implementation is not complete, there are a few method that are
either incomplete or not implemented. All of these are related to the
Unicode Code Point support, as defined by Java 5. As for the rest of the
implementation, there are probably a number of optimization points, but
the
focus was to complete the functionality and make it compatible with
various
Java 5 runtimes.
Additionally, I had a problem with compiling this class in Eclipse
3.1.2.
When I set the compiler to Java 1.4 compliance level, the methods which
implement the
Re: svn commit: r453745 - in /incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet: bcproc.cpp cg.h cg_fld_arr.cpp cg_obj.cpp compiler.h enc.cpp enc.h enc_ia32.cpp magics.cpp
Did that test pass before?
[EMAIL PROTECTED] wrote:
Author: wjwashburn
Date: Fri Oct 6 12:52:20 2006
New Revision: 453745
URL: http://svn.apache.org/viewvc?view=revrev=453745
Log:
HARMONY-1677, vmmagic for Jitrino.JET compiler. Basically all the vmmagic
regression tests pass except atomic CAS
Tested on windowsXP and RedHat Linux w/ gcc 3.4.5
Added:
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/magics.cpp
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/bcproc.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg.h
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_fld_arr.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_obj.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/compiler.h
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/enc.cpp
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/enc.h
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/enc_ia32.cpp
Modified: incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/bcproc.cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/bcproc.cpp?view=diffrev=453745r1=453744r2=453745
==
--- incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/bcproc.cpp
(original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/bcproc.cpp Fri
Oct 6 12:52:20 2006
@@ -46,37 +46,43 @@
gen_dbg_check_stack(true);
}
-const InstrDesc idesc = instrs[jinst.opcode];
-switch (idesc.ik) {
-case ik_a:
-handle_ik_a(jinst);
-break;
-case ik_cf:
-handle_ik_cf(jinst);
-break;
-case ik_cnv:
-handle_ik_cnv(jinst);
-break;
-case ik_ls:
-handle_ik_ls(jinst);
-break;
-case ik_meth:
-handle_ik_meth(jinst);
-break;
-case ik_obj:
-handle_ik_obj(jinst);
-break;
-case ik_stack:
-handle_ik_stack(jinst);
-break;
-case ik_throw:
-gen_athrow();
-break;
-default:
-assert(jinst.opcode == OPCODE_NOP);
-break;
-};
-
+// First test if this is a magic. If not, then proceed with regular
+// code gen.
+if (!gen_magic()) {
+const InstrDesc idesc = instrs[jinst.opcode];
+switch (idesc.ik) {
+case ik_a:
+handle_ik_a(jinst);
+break;
+case ik_cf:
+handle_ik_cf(jinst);
+break;
+case ik_cnv:
+handle_ik_cnv(jinst);
+break;
+case ik_ls:
+handle_ik_ls(jinst);
+break;
+case ik_meth:
+handle_ik_meth(jinst);
+break;
+case ik_obj:
+handle_ik_obj(jinst);
+break;
+case ik_stack:
+handle_ik_stack(jinst);
+break;
+case ik_throw:
+gen_athrow();
+break;
+default:
+assert(jinst.opcode == OPCODE_NOP);
+break;
+} // ~switch(opcodegroup)
+} else { // if (!gen_magic()) {
+// no op. Just check stack (if applicable) and do mem manipulations
+}
+
if (is_set(DBG_CHECK_STACK)) {
gen_dbg_check_stack(false);
}
Modified: incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg.h
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg.h?view=diffrev=453745r1=453744r2=453745
==
--- incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg.h (original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg.h Fri Oct 6
12:52:20 2006
@@ -375,7 +375,7 @@
*
* Also invokes gen_check_bounds() and gen_check_null().
*/
-void gen_arr_store(jtype jt);
+void gen_arr_store(jtype jt, bool helperOk = true);
/**
* @brief Generates code to check bounds for array access.
* @param aref_depth - depth (in the operand stack) of the array's object
Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_fld_arr.cpp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_fld_arr.cpp?view=diffrev=453745r1=453744r2=453745
==
--- incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_fld_arr.cpp
(original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_fld_arr.cpp
Fri Oct 6 12:52:20 2006
@@ -124,11 +124,11 @@
}
}
-void CodeGen::gen_arr_store(jtype
[classlib] clap clap clap
I am installing a new machine now, and have been carefully writing down all that I had to do for tools and dependencies to update the website. When building classlib, I ran across the change where I didn't need to have the separate AWT/Swing deps done ahead of time, but if they weren't there, the build script told me what I needed. Effortless. Nice job, Mark. :) 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][lang] AbstractStringBuilder, abstract class?
I commited a change. The class is now abstract. Please verify that is
solves the issue.
Would someone mind posting a JIRA issue with an additional test for
StringBuffer and StringBuilder.
-Nathan
On 10/7/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Seems like it was just a oversight. I can check in a fix.
-Nathan
On 10/7/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/7, Geir Magnusson Jr. [EMAIL PROTECTED]:
sounds reasonable, but don't go based on my word, of course.
Interesting question is why AbstractStringBuilder isn't abstract...
It does not really matters from implementation POV, and the name was
just chosen after the RI - sorta be deeply compatible. But indeed we
missed abstract modifier, which is also quite reasonable as a
precaution for undocumented exploitation.
Let's fix this.
Andrew Zhang wrote:
On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:
An interesting side note: The Serialized Form documentation gives away
an
implementation detail of StringBuffer and StringBuilder, in that they
both
extend from an AbstractStringBuilder. This might be an interesting
approach
to consolidate those code paths.
Spec lies sometimes? The spec of StringBuilder and StringBuffer claim the
superclass of them is java.lang.Object, but the serialized form tells the
truth - they extend from java.lang.AbstractStringBuilder, which is not
public.
I picked up this thread again because I found an existing application
failed
against Harmony because of this problem. The scenario is:
1. application runs on jdk1.1
2. new instances of some classes. If a class has superclass, then new an
instance of superclass too if it's not abstract or an interface. The
pseudo-code looks like:
newAllInstances(Class clazz) {
if(clazz == null) return;
if (clazz is abstract or an interface) return;
new an instance of clazz;
newAllInstances(clazz.getSuperClass());
}
The test data includes some instances of StringBuffer. The application
fails
against Harmony because AbstractStringBuilder is a concrete class but not
public. The application runs well against sun jdk 1.5 (Although all code
are
based on jdk1.1) because the superclass is abstract.
So is it a reason to change the signature of class AbstractStringBuilder?
Make it as abstract really as the name suggests?
Thanks!
[1]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuilder
[2]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuffer
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 3:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Nathan,
First, let me say a big thank you for the code and tests you submitted.
I've had a chance to read through it and (beyond the comments below) it
looks good.
I've committed a modified version of your patch to SVN. However, ;-)
1. I've removed the javadoc comments as these appear to be direct
copies of the Sun documentation. We cannot copy Sun's property. For
now the comments have been replaced with TODO tags.
2. I've removed the .intern() from the string literals, since these
will be interned by the VM anyway.
3. Why have you got transient char[] and int fields, and then serialize
them (as int, char[])? Wouldn't it be easier to reorder the fields and
remove the readObject/writeObject methods?
Thanks again for your work,
Tim
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison resolved HARMONY-103:
-
Resolution: Fixed
Nathan,
Thanks for the patch, it has been applied (minus javadoc) at repo
revision
379882.
Please check that it has been applied as you expected.
java.lang.StringBuilder Implementation for LUNI
---
Key: HARMONY-103
URL: http://issues.apache.org/jira/browse/HARMONY-103
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Nathan Beyer
Assignee: Tim Ellison
Attachments: StringBuilder.java, StringBuilderTest.java
This bug is for submitting an implementation of the
java.lang.StringBuilder to the LUNI module of classlib. The
implementation
and class definition is based on the specification at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
The implementation is not complete, there are a few method that are
either incomplete or not implemented. All of these are related to the
Unicode Code Point support, as defined by Java
Re: [general] Dynamic class loading
Nathan Beyer wrote: Stefano is correct, this doesn't require anything special in the VM. In fact, the basics of this already exist -- JavaServer Pages. Is compiling code a big problem? Nathan, JSP can't be used: because web server should be run, JSP has different syntax and semantics, JSP has different versions, need to use java compiler. I want to develop this tool for sake of simplicity: the fewer steps to execute source code, the more simplicity. Besides, dynamic compilation will help beginners to faster learn Java: they may not learn javac tool. Nikolay Chugunov Intel Middleware Products Division
[classlib] build problem.... I'm forgetting something obvious...
still on that new machine. classlib builds fine, but ant test results in it appearing to be very, very confused when trying to compile, with the first module, accessibility. It can't find things like BasicSwingTestCase, although I can confirm that it was build in test_support... I figure I forgot something obvious... 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 problem.... I'm forgetting something obvious...
Are you running build with -Dwith.awt.swing=true? I had some weird problems yesterday and it just seemed that I wasn't consistently using that property for all ant runs. -Nathan On 10/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: still on that new machine. classlib builds fine, but ant test results in it appearing to be very, very confused when trying to compile, with the first module, accessibility. It can't find things like BasicSwingTestCase, although I can confirm that it was build in test_support... I figure I forgot something obvious... geir - 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: [general] Dynamic class loading
beanshell? :) Nikolay Chugunov wrote: Nathan Beyer wrote: Stefano is correct, this doesn't require anything special in the VM. In fact, the basics of this already exist -- JavaServer Pages. Is compiling code a big problem? Nathan, JSP can't be used: because web server should be run, JSP has different syntax and semantics, JSP has different versions, need to use java compiler. I want to develop this tool for sake of simplicity: the fewer steps to execute source code, the more simplicity. Besides, dynamic compilation will help beginners to faster learn Java: they may not learn javac tool. Nikolay Chugunov 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: [classlib] build problem.... I'm forgetting something obvious...
That could be it. If that case, we have a problem... Nathan Beyer wrote: Are you running build with -Dwith.awt.swing=true? I had some weird problems yesterday and it just seemed that I wasn't consistently using that property for all ant runs. -Nathan On 10/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: still on that new machine. classlib builds fine, but ant test results in it appearing to be very, very confused when trying to compile, with the first module, accessibility. It can't find things like BasicSwingTestCase, although I can confirm that it was build in test_support... I figure I forgot something obvious... geir - 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: [classlib] build problem.... I'm forgetting something obvious...
Nathan, yeah that's probably it. It's caught me out a couple of times. Is that swing test fix ready? If not perhaps we should just exclude it, and then I can dump the with.awt.swing property for good? Regards, Mark. On 7 October 2006 at 14:29, Nathan Beyer [EMAIL PROTECTED] wrote: Are you running build with -Dwith.awt.swing=true? I had some weird problems yesterday and it just seemed that I wasn't consistently using that property for all ant runs. -Nathan On 10/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: still on that new machine. classlib builds fine, but ant test results in it appearing to be very, very confused when trying to compile, with the first module, accessibility. It can't find things like BasicSwingTestCase, although I can confirm that it was build in test_support... I figure I forgot something obvious... geir - 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: [classlib] build problem.... I'm forgetting something obvious...
nope, that wasn't it. I did a ant clean, ant flag, and test flag still broke... Mark Hindess wrote: Nathan, yeah that's probably it. It's caught me out a couple of times. Is that swing test fix ready? If not perhaps we should just exclude it, and then I can dump the with.awt.swing property for good? Regards, Mark. On 7 October 2006 at 14:29, Nathan Beyer [EMAIL PROTECTED] wrote: Are you running build with -Dwith.awt.swing=true? I had some weird problems yesterday and it just seemed that I wasn't consistently using that property for all ant runs. -Nathan On 10/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: still on that new machine. classlib builds fine, but ant test results in it appearing to be very, very confused when trying to compile, with the first module, accessibility. It can't find things like BasicSwingTestCase, although I can confirm that it was build in test_support... I figure I forgot something obvious... geir - 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: [general] Dynamic class loading
I wasn't literally suggesting using JSPs, but rather the concept behind the technology -- dynamically loading a script with embedded Java, generating a complete Java source, compiling it and then loading the bytecodes. You can probably take the JSP engine from Tomcat and hack it into a more generalized launcher. -Nathan On 10/7/06, Nikolay Chugunov [EMAIL PROTECTED] wrote: Nathan Beyer wrote: Stefano is correct, this doesn't require anything special in the VM. In fact, the basics of this already exist -- JavaServer Pages. Is compiling code a big problem? Nathan, JSP can't be used: because web server should be run, JSP has different syntax and semantics, JSP has different versions, need to use java compiler. I want to develop this tool for sake of simplicity: the fewer steps to execute source code, the more simplicity. Besides, dynamic compilation will help beginners to faster learn Java: they may not learn javac tool. Nikolay Chugunov 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]
JNode 0.2.4 released
The JNode team is proud to announce the release of the version 0.2.4 of the JNode.org operating system. JNode.org is an open source java OS(Operating System) written fully in java (with a very small assembler nano-kernel). This release features the first possibility of basic development under jnode Screenshots are available here: http://www.jnode.org/node/132 New features improvements in this release are: Basic support for development under JNode javac command, included with the use of Eclipse JDT compiler Integrated standard java tools: jar, native2ascii, serialver etc. from GNU Classpath Text console improvements Swing based console New textconsole based editor JFat - a FAT32 file system implementation RamFS - a simple in-memory file system FTPFS - a read-only FTP based file system Many classpath patches ImageIO support for PNG, GIF and BMP images from GNU Classpath BDF font support Changable desktop Look Feel Isolate (JSR 121), not fully supported Simple webserver under JNode Various bugfixes in the resource loading, ISO9660, socket writing Download of JNode can be done at http://www.jnode.org/node/892 More information can be found at http://www.jnode.org or http://sourceforge.net/projects/jnode - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Dynamic class loading
Nathan Beyer wrote: I wasn't literally suggesting using JSPs, but rather the concept behind the technology -- dynamically loading a script with embedded Java, generating a complete Java source, compiling it and then loading the bytecodes. You can probably take the JSP engine from Tomcat and hack it into a more generalized launcher. Right. Take this: http://simile.mit.edu/repository/tools/loader/trunk/src/Loader.java and overload Class loadClass(String name, boolean resolve) merging it with something some code taken from http://tinyurl.com/r4rmf ship with the eclipse JDT compiler, stir up and you're done. -- Stefano. - 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: r453745 - in /incubator/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet: bcproc.cpp cg.h cg_fld_arr.cpp cg_obj.cpp compiler.h enc.cpp enc.h enc_ia32.cpp magics.cpp
I tested CAS ops in this implementation and it worked. Could you show me the test that fails? On 10/8/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Did that test pass before? [EMAIL PROTECTED] wrote: Author: wjwashburn Date: Fri Oct 6 12:52:20 2006 New Revision: 453745 URL: http://svn.apache.org/viewvc?view=revrev=453745 Log: HARMONY-1677, vmmagic for Jitrino.JET compiler. Basically all the vmmagic regression tests pass except atomic CAS -- Mikhail Fursov
Re: [party] who's coming to apachecon, raise their hands!
me too. I'm in Austin now, and leaving Fri afternoon. Tim Stefano Mazzocchi wrote: I am! -- 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: Eclipse bug - move MANIFEST.MF to a different location
Alex Blewitt wrote: Hi all, There's a discussion going on the Eclipse bugs list about being able to move the META-INF/MANIFEST.MF to a different location (e.g. src/main/resources/META-INF/MANIFEST.MF). For some reason, the Eclispe PDE/Equinox team can't seem to understand why anyone would want to put resources anywhere other than the top-level of the project. LOL How about making there be a default and then have it a configuration option? If you'd like to add your opinions, please add your comments to (and vote for!) https://bugs.eclipse.org/bugs/show_bug.cgi?id=153023 as well as perhaps https://bugs.eclipse.org/bugs/show_bug.cgi?id=154079 Thanks, Alex. PS There was also some spirited discussion on the equinox-dev mailing list some time ago, but I think it's migrated from there into the bug discussion http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01272.html Basically seems to be Eclipse-users saying Yes! We want this! and the Equinox team going Why? It works fine ... Imagine... - 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: Eclipse bug - move MANIFEST.MF to a different location
...and don't forget https://bugs.eclipse.org/bugs/show_bug.cgi?id=122310 that I opened Dec last year. Regards, Tim Alex Blewitt wrote: Hi all, There's a discussion going on the Eclipse bugs list about being able to move the META-INF/MANIFEST.MF to a different location (e.g. src/main/resources/META-INF/MANIFEST.MF). For some reason, the Eclispe PDE/Equinox team can't seem to understand why anyone would want to put resources anywhere other than the top-level of the project. If you'd like to add your opinions, please add your comments to (and vote for!) https://bugs.eclipse.org/bugs/show_bug.cgi?id=153023 as well as perhaps https://bugs.eclipse.org/bugs/show_bug.cgi?id=154079 Thanks, Alex. PS There was also some spirited discussion on the equinox-dev mailing list some time ago, but I think it's migrated from there into the bug discussion http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01272.html Basically seems to be Eclipse-users saying Yes! We want this! and the Equinox team going Why? It works fine ... - 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: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 Geir Magnusson Jr. wrote: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - 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][lang] AbstractStringBuilder, abstract class?
On 10/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
sounds reasonable, but don't go based on my word, of course.
Interesting question is why AbstractStringBuilder isn't abstract...
curious too...
Andrew Zhang wrote:
On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:
An interesting side note: The Serialized Form documentation gives
away
an
implementation detail of StringBuffer and StringBuilder, in that they
both
extend from an AbstractStringBuilder. This might be an interesting
approach
to consolidate those code paths.
Spec lies sometimes? The spec of StringBuilder and StringBuffer claim
the
superclass of them is java.lang.Object, but the serialized form tells
the
truth - they extend from java.lang.AbstractStringBuilder, which is not
public.
I picked up this thread again because I found an existing application
failed
against Harmony because of this problem. The scenario is:
1. application runs on jdk1.1
2. new instances of some classes. If a class has superclass, then new an
instance of superclass too if it's not abstract or an interface. The
pseudo-code looks like:
newAllInstances(Class clazz) {
if(clazz == null) return;
if (clazz is abstract or an interface) return;
new an instance of clazz;
newAllInstances(clazz.getSuperClass());
}
The test data includes some instances of StringBuffer. The application
fails
against Harmony because AbstractStringBuilder is a concrete class but
not
public. The application runs well against sun jdk 1.5 (Although all code
are
based on jdk1.1) because the superclass is abstract.
So is it a reason to change the signature of class
AbstractStringBuilder?
Make it as abstract really as the name suggests?
Thanks!
[1]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuilder
[2]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuffer
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 3:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Nathan,
First, let me say a big thank you for the code and tests you submitted.
I've had a chance to read through it and (beyond the comments below) it
looks good.
I've committed a modified version of your patch to SVN. However, ;-)
1. I've removed the javadoc comments as these appear to be direct
copies of the Sun documentation. We cannot copy Sun's property. For
now the comments have been replaced with TODO tags.
2. I've removed the .intern() from the string literals, since these
will be interned by the VM anyway.
3. Why have you got transient char[] and int fields, and then
serialize
them (as int, char[])? Wouldn't it be easier to reorder the fields and
remove the readObject/writeObject methods?
Thanks again for your work,
Tim
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison resolved HARMONY-103:
-
Resolution: Fixed
Nathan,
Thanks for the patch, it has been applied (minus javadoc) at repo
revision
379882.
Please check that it has been applied as you expected.
java.lang.StringBuilder Implementation for LUNI
---
Key: HARMONY-103
URL: http://issues.apache.org/jira/browse/HARMONY-103
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Nathan Beyer
Assignee: Tim Ellison
Attachments: StringBuilder.java, StringBuilderTest.java
This bug is for submitting an implementation of the
java.lang.StringBuilder to the LUNI module of classlib. The
implementation
and class definition is based on the specification at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
The implementation is not complete, there are a few method that are
either incomplete or not implemented. All of these are related to the
Unicode Code Point support, as defined by Java 5. As for the rest of
the
implementation, there are probably a number of optimization points, but
the
focus was to complete the functionality and make it compatible with
various
Java 5 runtimes.
Additionally, I had a problem with compiling this class in Eclipse
3.1.2.
When I set the compiler to Java 1.4 compliance level, the methods which
implement the Appendable interface cause compilation errors. When I set
the
compiler to Java 5.0 compliance with Java 1.4 .class file compatability
and
Java 1.4 source compatibility, the class compiled fine. I'm not sure if
this
is quirk of the JDT compiler or what, but I'm going to do some
investigation
and testing to see if I can isolate it.
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use
Re: [classlib][lang] AbstractStringBuilder, abstract class?
On 10/8/06, Nathan Beyer [EMAIL PROTECTED] wrote:
I commited a change. The class is now abstract. Please verify that is
solves the issue.
Thank you Nathan, it works fine now!
Would someone mind posting a JIRA issue with an additional test for
StringBuffer and StringBuilder.
-Nathan
On 10/7/06, Nathan Beyer [EMAIL PROTECTED] wrote:
Seems like it was just a oversight. I can check in a fix.
-Nathan
On 10/7/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
2006/10/7, Geir Magnusson Jr. [EMAIL PROTECTED]:
sounds reasonable, but don't go based on my word, of course.
Interesting question is why AbstractStringBuilder isn't abstract...
It does not really matters from implementation POV, and the name was
just chosen after the RI - sorta be deeply compatible. But indeed we
missed abstract modifier, which is also quite reasonable as a
precaution for undocumented exploitation.
Let's fix this.
Andrew Zhang wrote:
On 2/23/06, Nathan Beyer [EMAIL PROTECTED] wrote:
An interesting side note: The Serialized Form documentation
gives away
an
implementation detail of StringBuffer and StringBuilder, in that
they
both
extend from an AbstractStringBuilder. This might be an
interesting
approach
to consolidate those code paths.
Spec lies sometimes? The spec of StringBuilder and StringBuffer
claim the
superclass of them is java.lang.Object, but the serialized form
tells the
truth - they extend from java.lang.AbstractStringBuilder, which is
not
public.
I picked up this thread again because I found an existing
application
failed
against Harmony because of this problem. The scenario is:
1. application runs on jdk1.1
2. new instances of some classes. If a class has superclass, then
new an
instance of superclass too if it's not abstract or an interface.
The
pseudo-code looks like:
newAllInstances(Class clazz) {
if(clazz == null) return;
if (clazz is abstract or an interface) return;
new an instance of clazz;
newAllInstances(clazz.getSuperClass());
}
The test data includes some instances of StringBuffer. The
application
fails
against Harmony because AbstractStringBuilder is a concrete class
but not
public. The application runs well against sun jdk 1.5 (Although
all code
are
based on jdk1.1) because the superclass is abstract.
So is it a reason to change the signature of class
AbstractStringBuilder?
Make it as abstract really as the name suggests?
Thanks!
[1]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuilder
[2]
http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
gBuffer
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 3:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Resolved: (HARMONY-103)
java.lang.StringBuilder
Implementation for LUNI
Nathan,
First, let me say a big thank you for the code and tests you
submitted.
I've had a chance to read through it and (beyond the comments
below) it
looks good.
I've committed a modified version of your patch to SVN. However,
;-)
1. I've removed the javadoc comments as these appear to be
direct
copies of the Sun documentation. We cannot copy Sun's
property. For
now the comments have been replaced with TODO tags.
2. I've removed the .intern() from the string literals, since
these
will be interned by the VM anyway.
3. Why have you got transient char[] and int fields, and then
serialize
them (as int, char[])? Wouldn't it be easier to reorder the
fields and
remove the readObject/writeObject methods?
Thanks again for your work,
Tim
Tim Ellison (JIRA) wrote:
[
http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison resolved HARMONY-103:
-
Resolution: Fixed
Nathan,
Thanks for the patch, it has been applied (minus javadoc) at
repo
revision
379882.
Please check that it has been applied as you expected.
java.lang.StringBuilder Implementation for LUNI
---
Key: HARMONY-103
URL: http://issues.apache.org/jira/browse/HARMONY-103
Project: Harmony
Type: New Feature
Components: Classlib
Reporter: Nathan Beyer
Assignee: Tim Ellison
Attachments: StringBuilder.java, StringBuilderTest.java
This bug is for submitting an implementation of the
java.lang.StringBuilder to the LUNI module of classlib. The
implementation
and class definition is based on the specification at
[result] Re: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 from Oleg, Mikhail L, Stefano, Mikhail F, Mark, Geir, Alexey P, Dan, Tim No 0 or -1 votes Geir Magnusson Jr. wrote: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - 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][lang] AbstractStringBuilder, abstract class?
By the way, is it ok to report a commercial or GPL/LGPL java software on what can it do wiki page? [1] [1] http://wiki.apache.org/harmony/ClassLibrary -- Best regards, Andrew Zhang
Re: Re: Eclipse bug - move MANIFEST.MF to a different location
Cool. I've asked them to mark it as a dupe of 153023, so you should get Cc'd onto that one automatically ... but if you can use the 'vote for this bug' then it would be one more person on the list. It's at 5 at the moment, so the more people who vote for it the more PDE will realise that it's a requested feature ... Re: the default: I'm guessing that if it were to go ahead, they would make it backwardly compatible to be in the project root. My hope is that they search for it in the bin/ directory (or whatever other output directories there are) so that you could have a src/main/resources/META-INF/MANIFEST.MF, and then it would just be resolved similar to any other resource at build time. Plus, it would make exporting easy; you'd just zip up the bin/ directory ... Alex. - 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][lang] AbstractStringBuilder, abstract class?
yes Andrew Zhang wrote: By the way, is it ok to report a commercial or GPL/LGPL java software on what can it do wiki page? [1] [1] http://wiki.apache.org/harmony/ClassLibrary - 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][nio] How to fix read-only problem? (Re: [classlib][io][nio] Sync issue of java.io.FileOutputStream and java.nio.channels.FileChannel)
On 10/3/06, Andrew Zhang [EMAIL PROTECTED] wrote:
There are two ways to fix this problem:
1. Add a read-only flag in FileDescriptor. The default value is false. Set
the flag to true in FileInputStream and RandomeAccessFile(r).
2. Determine the fd in native code whether the fd is read-only.
Solution 1 judges the fd in java code, but has to remove native
from FileDescriptor#sync() signature. While solution 2 seems nature, and
solves the problem thoroughly, but requires more codes. If we adopt solution
2, we should add a new portable native mehtod like isReadOnly(int fd). Where
should we put the method? in port? or OSFileSystemWin32/Linux? Any
suggestions and comments?
Andrew,
I prefer to solution 2. IMHO, we may put the method in portlib if necessary.
Best regards,
Richard
Thanks!
On 9/19/06, Andrew Zhang [EMAIL PROTECTED] wrote:
I just found another bug of sync. Harmony throws SyncFailedException when
fd is read-only while RI returns silently. Spec doesn't explictly describe
the behaviour in such case[1]. But, it seems intended behaviour of RI,
because it requires additional check before invoke os sync. Following test
reproduces the bug:
public void testSyncReadOnly() throws Exception {
String TESTFILE = tempFile;
try {
FileOutputStream fos = new FileOutputStream(TESTFILE);
fos.write(something.getBytes());
fos.close();
RandomAccessFile raf = new RandomAccessFile(TESTFILE, rw);
raf.getFD().sync();
raf.close();
FileInputStream fis = new FileInputStream(TESTFILE);
fis.getFD().sync();
fis.close();
} finally {
new File(TESTFILE).delete();
}
}
I'll file a JIRA to record this bug soon!
[1] SyncFailedException - Thrown when the buffers cannot be flushed, or
because the system cannot guarantee that all the buffers have been
synchronized with physical media.
On 9/19/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/18/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 9/18/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello,
One Apache Derby test[1] fails on Harmony. It seems that RI always
sync the FileOutputStream and FileChannel after each write, which
is
different from Harmony. But there is no explicit description in Java
Spec. Shall we follow RI? Thanks a lot.
The following test cases could demonstrate this issue.
public void testFile() {
File derbyLog = new File(d:\\, derby1.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
fos.write(0x41);
assertEquals(1, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
public void testFileChannel() {
File derbyLog = new File(d:\\, derby2.log);
try {
FileOutputStream fos = new FileOutputStream(derbyLog);
FileChannel fc = fos.getChannel();
fc.write (ByteBuffer.wrap(new byte[]{0x41, 0x42}));
assertEquals(2, derbyLog.length());
} catch (Exception e) {
e.printStackTrace();
}
}
Interesting. I think we'd better follow RI although it's
implementation
dependent. Otherwise, it breaks existing application.
To make test more interesting, I wrote a similar test:
public void testFile() throws Exception {
File derbyLog = File.createTempFile(test, log);
derbyLog.deleteOnExit();
RandomAccessFile fos = new RandomAccessFile(derbyLog, rws);
for (int i = 0; i 1000; i++) {
fos.write(0x41);
assertEquals(1 + i, derbyLog.length());
}
}
Run it and you'll be surprised. :-)
Wow! It tooks RI 0.381 seconds, while 21.761 seconds for Harmony. We
shall improve our performance!
Let's have a more further study about this issue.
[1]
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/logStream.java?view=co
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
--
Best regards,
Andrew
