[app] ant with ecj
Hi all. I'm trying to use ant with the ecj compiler. I override the compiler in build.xml like this: property name=build.compiler value= org.eclipse.jdt.core.JDTCompilerAdapter / This will execute the compiler, but I find I have to add each jar from jdk/jre/lib/boot to CLASSPATH or else ecj won't find the standard classes during compilation. This is probably user error, and not related to harmony. :) Does anyone know what I might be improperly configuring? Thanks, -Jordan
RE: [app] xmlbeans
I take it that means the issue is pretty obvious (very easy to recreate). Can you tell us what you did to recreate it and what class in Harmony is at issue? -Nathan -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 10:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [app] xmlbeans I reproduce the same error on xmlbeans-2.2.0. Jordan Justen wrote: Well, I don't have much details, but here's the stack trace. I figured it wouldn't be to helpful for the list. I don't see this exception with the sun jvm/classes. Anyway, I'll try debug it some... [java] java.lang.NullPointerException [java] at org.apache.xmlbeans.impl.common.NameUtil.splitWords( NameUtil.java:667) [java] at org.apache.xmlbeans.impl.common.NameUtil.lowerCamelCase( NameUtil.java:623) [java] at org.apache.xmlbeans.impl.common.NameUtil.getPackageFromNamespace( NameUtil.java:513) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName(NameUtil.ja va :328) [java] at org.apache.xmlbeans.impl.common.NameUtil.getClassNameFromQName(NameUtil.ja va :318) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.pickFullJavaClassName( StscJavaizer.java:679) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.assignGlobalJavaNames( StscJavaizer.java:91) [java] at org.apache.xmlbeans.impl.schema.StscJavaizer.javaizeAllTypes( StscJavaizer.java:55) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl( SchemaTypeSystemCompiler.java:313) [java] at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile( SchemaTypeSystemCompiler.java:181) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.loadTypeSystem( SchemaCompiler.java:952) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile( SchemaCompiler.java:1072) [java] at org.apache.xmlbeans.impl.tool.SchemaCompiler.main( SchemaCompiler.java:368) On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote: Is there a particular issue that you've run into? -Original Message- From: Jordan Justen [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 7:10 PM To: harmony-dev@incubator.apache.org Subject: [app] xmlbeans Has anyone successfully used harmony with xmlbeans ( http://xmlbeans.apache.org/)? Or, does anyone know of any major reasons why it would not be working at this time? I tried it without luck. I'll debug the error if no one knows of any major roadblocks that I'd encounter. Thanks, -Jordan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [app] ant with ecj
Hello Jordan, All the boot jars have been add in the javac tasks. Could you please paste the stack trace? Thanks a lot. Please refer to modules/luni/build.xml javac bootclasspath fileset dir=${hy.jdk}/jre/lib/boot include name=**/*.jar / /fileset /bootclasspath Best regards, Richard Jordan Justen wrote: Nathan, Is there a way to have the javac/ecj task include all of standard harmony jars without including them in the CLASSPATH environment variable? Thanks, -Jordan On 8/27/06, Nathan Beyer [EMAIL PROTECTED] wrote: Keep in mind that the execution of the Ant scripts and the compilation are two separate things, which means they are using two different classpaths. If the compilation task is complaining about a missing class, then this means the class is missing from the classpath of the compiler, not the classpath of the executing Ant. You'll need the Eclipse compiler JAR on Ant's execution classpath to execute the javac task. This can be confusing when using the Eclipse compiler, since it doesn't have any default classpath. Normally when you're using 'javac' from a JDK, the classpath of the underlying JRE (all of the java.*, etc classes) is automatically on the classpath. The Eclipse compiler is not part of a JDK, so there is nothing on the classpath by default. -Nathan -Original Message- From: Jordan Justen [mailto:[EMAIL PROTECTED] Sent: Sunday, August 27, 2006 8:49 PM To: harmony-dev@incubator.apache.org Subject: Re: [app] ant with ecj Richard, Yes, I also added ecj_3.2.jar to the CLASSPATH. Ant works fine, but the first time a javac task is encountered, the compiler complained that java.lang.Object was not found. I then added jdk/jre/lib/boot/kernel.jar to CLASSPATH. Now, I see an error that java.lang.String is not found, so I added luni.jar to CLASSPATH. etc... Since ant is basically working (mkdir tasks, delete tasks, java tasks all seem to work), I think the harmony jvm is loading these boot jars, but it seems like when the javac task uses ecj, those jars are not visible. I'm using windows xp, ant 1.6.5, and the latest harmony jdk snapshot. Thanks again, -Jordan On 8/27/06, Richard Liang [EMAIL PROTECTED] wrote: Jordan Justen wrote: Hi all. I'm trying to use ant with the ecj compiler. I override the compiler in build.xml like this: property name=build.compiler value= org.eclipse.jdt.core.JDTCompilerAdapter / This will execute the compiler, but I find I have to add each jar from jdk/jre/lib/boot to CLASSPATH or else ecj won't find the standard classes during compilation. This is probably user error, and not related to harmony. :) Does anyone know what I might be improperly configuring? Hello Jordan, Do you mean the build.compiler property in make/build_java.xml? I just give it a try by 1) overriding the compiler as what you have done 2) adding C:\harmony\workspace\trunk\depends\jars\ecj_3.2\ecj_3.2.jar into classpath. Everything works OK. :-) Could you give more detailed information about this issue? Thanks a lot. Best regards, Richard Thanks, -Jordan -- Richard Liang China Software 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software 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]
Re: [jira] Assigned: (HARMONY-1208) Bug fixing and cosmetics for Harmony 935
Hi Mikhail, On 8/25/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel 2006/8/25, Daniel Fridlender [EMAIL PROTECTED]: On 8/23/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel, I've tried the patch. 4 math tests failed. Could you please take a look? Thanks, Mikhail Hi Mikhail, You are right. Two of these four tests are due to typos in the exception messages: 1)org.apache.harmony.tests.java.math.BigDecimalConstructorsTest.testConstrStringExponentIntegerMin( BigDecimalConstructorsTest.java:497) expectedScale out of range. but was Scale out of range 2)org.apache.harmony.tests.java.math.BigDecimalScaleOperationsTest.testMovePointRightException( BigDecimalScaleOperationsTest.java:335) expectedUnderflow but was UnderFlow We corrected them (and a similar problem with Overflow) with a new patch typos.diff.zip´ in H1208. The other two failing tests require some discussion. 3)org.apache.harmony.tests.java.math.BigDecimalConstructorsTest.testConstrBI(BigDecimalConstructorsTest.java:75) I believe the test is wrong in this case since according to the API specification the NullPointerException will actually be thrown before the try block. The test incorrectly expects it to be thrown in the block. The RI also fails this test. I've just rerun it on RI and it passed. What RI version do you use? I got the argument about the spec. It in a class description, right? Right. The description of the class BigDecimal contains the statement All methods and constructors for this class throw NullPointerException when passed a null object reference for any input parameter. Thus, there is a bug in the 1.5.0 version of the RI when invoking the constructor BigDecimal(BigInteger val) with a null argument since it does not throw NPE. This bug is fixed in version 1.5.0_08 (and also in 1.6). I have just seen in H784 that Vladimir Ivanov discovered this for version 1.5.0_06. 4)org.apache.harmony.tests.java.math.BigDecimalArithmeticTest.testDivideByZero(BigDecimalArithmeticTest.java:492) expected BigInteger divide by zero but was Division by zero This is not just a typo. Both exception messages are used by the RI in different BigDecimal.divide methods when dividing by BigDecimal.ZERO. There is at least a third message: / by zero. Some methods seem to use different messages depending on the size of the dividend. So, I see two possibilities here: a) use everywhere the message Division by zero. b) try to find out when RI uses each of the different messages. I would suggest a) rather than b) since from the point of view of the programmer it is reasonable to obtain the same message when dividing by BigDecimal.ZERO regardless the size (or internal representation) of the dividend and the method invoked for the division. In general if a programmer use only one method in their implementation where RI throws BigInteger divide by zero, then they are not aware of other exception messages and they might hard code that BigInteger divide by zero one. It is a bit more complicated than that. From the tests we have run we can naturally guess that there are two groups of BigDecimal.divide methods in RI: i) those which check if the divisor is BigDecimal.ZERO in which case they throw the exception with the message Division by zero. ii) those which do not check (forget to check?) and attempt to divide anyhow: they will use the BigInteger divide by zero or / by zero depending on where the problem happens. That is, depending on whether the dividend is large (and the division takes place in BigInteger) or small (and the division takes place in a primitive type). So I'd prefer to keep it look like RI as it is now. BUT, if this change implies an undesirable design change then I'm OK with discrepancy in exception messages Keeping it look like RI for methods of group ii) would imply trying to determine the exact border between messages BigInteger divide by zero and / by zero. Thanks Daniel Thanks, Mikhail In addition, doing b) may imply inspecting the behavior of RI a bit too far. I am reluctant to do this since different messages may reveal when the unscaled value is implemented as a BigInteger and when as a primitive integral value. We submitted a new patch tests.diff.zip to H1208 correcting the test mentioned in 3) and replacing the test in 4) by another invocation to divide with the Division by zero message. Both RI and our implementation pass the tests. I think both patches should be applied. In the meantime we may discuss if the approach b) is preferred. Regards, Daniel 2006/8/22, Daniel Fridlender [EMAIL PROTECTED]: Hi Mikhail, On 8/17/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Daniel, Please resubmit the patch with license granted to ASF done. Seems like the patch was generated against original H-935 contribution and does not take into account later changes. Could
Re: [drlvm] how does drlvm insert the safe point into a method
Hi Fan, I think you are asking about safe instruction pointer addresses in JITed code where the JIT is able to enumerate all live references. If this is the case, it turns out there are lots of subtle interactions between all the pieces of the system. In otherwords, I can't do justice to the topic in an email. But I will point you in the right direction. The JIT can insert polling code at points where it knows it can find all live references on a thread's stack. When the GC wants a thread to suspend and report its live references, it can set a flag in the thread-local context. When the JITed code sees the flag set, it will suspend the thread and report the live references. As far as I know the DRLVM JIT you are looking at does not quite do this yet. An incomplete but useful for bringup approach is to let the targetted thread continue executing until it tries to allocate an object. Assuming there is no space available, the thread is vectored into the garbage collector itself. By design, object allocation sites are places where the JIT can enumerate all live references on the stack. There are other schemes, such as suspending and resuming the targetted thread until the JIT reports it can enumerate. I won't bore you with the details here. Let me know if this helps. On 8/27/06, Fan Bin [EMAIL PROTECTED] wrote: Hi, I have a question about jit compiler in drlvm. I want to suspend the thread manually on a particular point. I know that the thread can only be suspended at safe point. I guess the safe point is inserted by jit compiler when it compile the method, but I can't prove it from the source code. So my question is whether it's true that it is the jit compiler which insert the safe point. If it is true, how does it do this? Thank you for your help. -- 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: [classlib] Sun compiler change?
Richard Liang 写道: Richard Liang wrote: Nathan Beyer wrote: Is anyone else using the latest Sun JDK, v5.0 Update 8 on Windows? I'm seeing a compilation error in the LUNI that I don't see with 5.0 Update 7. Here's the error I'm getting. compile: [mkdir] Created dir: C:\dev\harmony\enhanced\classlib\trunk\build\classes [javac] Compiling 3173 source files to C:\dev\harmony\enhanced\classlib\trun k\build\classes [javac] C:\dev\harmony\enhanced\classlib\trunk\modules\luni\src\main\java\ja va\util\MiniEnumSet.java:78: inconvertible types [javac] found : java.util.Collectioncapture of ? extends E [javac] required: java.util.EnumSetE [javac] EnumSetE set = (EnumSetE) collection; [javac] ^ Yes, I got the same error using 1.5.0_08. Will have a look at it. :-) This should be an enhancement/bug-fixing of java compiler. There are bugs in java.util.MiniEnumSet. I will try to fix it later Seems that in new version of JDK, EnumSetE and capture of ? extends E (E was previously stated as E extends EnumE) are not considered compatible. After changing EnumSetE set = (EnumSetE)collection; into EnumSet set = (EnumSet)collection; , compilation using ant in command line succeeds. Would any one give a clue, why the are considered incompatible in this version of JDK? Eclipse uses its own JDK compiler, which may differ from this 1.5.0_08 version compiler. I guess this is the reason why compilation only fails in command line on your machine. Best regards Richard. Best regards, Richard When I compile in Eclipse 3.2 there's no error. -Nathan -- Spark Shen China Software 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]
[vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. 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: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
+1 Geir Magnusson Jr wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. 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]