Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
2006/6/8, Paulex Yang <[EMAIL PROTECTED]>: Vladimir, Vladimir Ivanov wrote: > Thanks Paulex! > > I did the same, but could not send results due to spam filter J > Observations: > > 1. Coverage results look pretty much similar. > 2. Exclude list looks pretty much similar too, but, looks like it > depends on the way of data collection (I didn't run ant task and the > list is > a little bit different). Great. > > In any case, I think, when we run harmony on another VM exclude list will > have to be updated. > > > > May be we can start publishing the coverage information on wiki pages and > provide some updates time to time (I can do it)? > +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) Does it make sense to create corresponding build target? Thanks, Mikhail > > > One note: > > I noticed that different unit tests have very different package names > > Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html > > > > C:\coverage\tests\test>ls > > GZIPOutClose2.txtapi config javax > tests > > GZIPOutFinish.txtapi.injected dazzle orgxml > > GZIPOutWrite.txt binarygifprefs > > Inet6Address.golden.ser bundles impl serialization > > JDK2-3gabba.zip com impl.injected test.txt > > > > I think, it would be good if tests had unified package names. > > Why? – so far, just common sense, just to have an order in test suite > > Organization (if consider all unit tests as solid test suite). > > Thanks, > Vladimir > > For example, my exclude list for java.io is: > -java.io.BufferedInputStream, > -java.io.BufferedOutputStream, > -java.io.File, > -java.io.FileChannelFactory, > -java.io.FileDescriptor, > -java.io.FileInputStream, > -java.io.FileOutputStream, > -java.io.FilterInputStream , > -java.io.FilterOutputStream, > -java.io.InputStream, > -java.io.OutputStream, > -java.io.ObjectStreamField, > -java.io.PrintStream > > > On 6/6/06, Paulex Yang <[EMAIL PROTECTED]> wrote: >> >> I've attach the scripts and excluded class lists to JIRA, please refer >> to https://issues.apache.org/jira/browse/HARMONY-564. Enjoy it:). >> >> Mark Hindess wrote: >> > On 2 June 2006 at 10:37, Paulex Yang <[EMAIL PROTECTED]> wrote: >> > >> >> Mark, >> >> >> >> I'm glad that there is someone else has interest on emma, I've >> tried it >> >> before. AFAIK, emma works by instrumentation, but sometimes for >> classes >> >> in bootclasspath, the instrumentation cannot work, there are two >> cases: >> >> >> 1. Some instrumented classes cannot be loaded by VM. >> >> 2. Some classes cannot be instrumented >> >> >> >> I have tried to look more inside to find some way to work around >> but I >> >> haven't got enough time yet. >> >> >> >> Specifically for nio-channel module, I had a list for these two cases >> (I >> >> believe the data is a little outdated and should be reevaluated) >> >> case 1. >> >> BaseByteBuffer.class >> >> Buffer.class >> >> BufferFactory.class >> >> ByteBuffer.class >> >> CharArrayBuffer.class >> >> CharBuffer.class >> >> HeapByteBuffer.class >> >> ReadWriteCharArrayBuffer.class >> >> ReadWriteHeapByteBuffer.class >> >> FileChannel.class >> >> AbstractInterruptibleChannel.class >> >> FileChannelImpl.class >> >> WriteOnlyFileChannel.class >> >> LockManager.class >> >> LockManager$1.class >> >> ReadOnlyFileChannel.class >> >> >> >> case 2: >> >> ByteChannel.class >> >> Channel.class >> >> GatheringByteChannel.class >> >> InterruptibleChannel.class >> >> WritableByteChannel.class >> >> >> >> And I have got some ant script and more excluded list for emma, if >> >> anyone has interests, I can upload it to JIRA. >> >> >> > >> > Yes! >> > >> > -Mark. >> > >> > >> >> Mark Hindess wrote: >> >> >> >>> Anyone tried using emma (emma.sf.net) to look at test coverage >> for our >> >>> tests? That might help ensure we don't trim them down too much? >> >>> >> >>> I suspect we will soon reach a point where there are significantly >> fewer >> >>> obvious opportunities for small contributions - e.g. >> 1.5generification, >> >>> etc from looking at JAPI reports. Having test coverage reports >> might >> >>> help by highlighting areas for improvement. >> >>> >> >>> I had a quick try with: >> >>> >> >>> ant -f make/build.xml >> >>> ant -f modules/nio/make/build.xml test >> >>> java -cp emma.jar emma instr -m overwrite -cp >> deploy/jdk/jre/lib/boot/nio >> >>> >> >> .jar >> >> >> >>> and then: >> >>> >> >>> java -Xbootclasspath/p: emma.jar \ >> >>>-c
[classlib] moving to 1.5 for real - discuss
Thanks to many stellar contributions all round we are pretty much exhausting the work we can do with the temporary solution we adopted of source=1.5 target=jsr14|1.4 compiler flags. How do you feel about moving to 1.5 for real? It would be simple to change the Java compiler build options to generate 1.5 class files. AIUI there is at least some 1.5 awareness in DRLVM and JCHEVM (and SableVM?) which would allow the current functionality to work, and IBM can provide a 1.5 version of the IBM VME to run on. Thoughts? 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: [classlib] Enum ready to go
Thanks Mikhail. I updated the test in r412663.
Regards,
Tim
Mikhail Loenko wrote:
> now two out of three yesterday's tests pass, one still fails:
> tests.api.java.net.AuthenticatorTest
>
> Thanks,
> Mikhail
>
> 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> So the ECJ folk are going to modify their compiler to dispatch to
>> Enum#valueOf(Class, String) too [1] -- which means we get to decide the
>> exception thrown by a null name.
>>
>> The old Sun-based compilers (like the BEA one referenced below) and
>> current ECJ will throw an IAE for empty enums and NPE for non-empty
>> enums, and I don't see that we can influence that code.
>>
>> If we want the same tests to pass on both old and new compilers we'll
>> have to allow either exception.
>>
>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=145746
>>
>> Regards,
>> Tim
>>
>> Mikhail Loenko wrote:
>> > javac and java are from the same distrib (javac does not print
>> > detailed version info,
>> > that is why I''m mentioning java version),
>> > so it is javac 1.5.0_b64
>> >
>> > so I compile with JDK 1.5.0_b64, run on Harmony and it fails
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > 2006/6/7, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
>> >> Mikhail Loenko wrote:
>> >> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> >> The Sun 1.5.0_06 compiler was driven directly by our build
>> scripts (so
>> >> >> using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5
>> target 1.4
>> >> >> set.
>> >> >>
>> >> >> I could throw an IAE from Enum#valueOf(Class, null) when the
>> Enum is
>> >> >> empty, but seems a bit of a drag to work around the compilers.
>> >> >>
>> >> >> (which version of BEA javac?)
>> >> >
>> >> > javac -version prints just "1.5.0"
>> >> > java -version prints "build 1.5.0-b64"
>> >> >
>> >>
>> >> I would bet the tests shall pass if using javac of java-version "build
>> >> 1.5.0_01" or later :)
>> >> And as the tests also fail on RI of "build 1.5.0-b64" (I've just find
>> >> one:) ), I guess it is a bug of RI, which was fixed in the later
>> version.
>> >>
>> >> What's more, shall we also suggest that everyone use a latest
>> version of
>> >> javac to avoid such problem?
>> >>
>> >>
>> >> >
>> >> >>
>> >> >> Regards,
>> >> >> Tim
>> >> >>
>> >> >> Mikhail Loenko wrote:
>> >> >> > Are you compiling with "jsr14" as our build does?
>> >> >> >
>> >> >> > I'm using BEA javac with "jsr14" it compiles to something like
>> this:
>> >> >> > for(i=0; i < values.length; i++ )
>> >> >> > if( values[i].name().equals(argument) )
>> >> >> > return values[i].name().equals(argument)
>> >> >> > throw IAE
>> >> >> >
>> >> >> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> >> >> Maybe compiler specific.
>> >> >> >>
>> >> >> >> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> >> >> >> delegates to the Enum type:
>> >> >> >>
>> >> >> >> public static Type valueOf(String name)
>> >> >> >> {
>> >> >> >> return (Type)Enum.valueOf(
>> >> >> >> Proxy.class$java$net$Proxy$Type != null ?
>> >> >> >> Proxy.class$java$net$Proxy$Type :
>> >> >> >> (
>> >> >> >> Proxy.class$java$net$Proxy$Type =
>> >> >> >> Proxy._mthclass$("java.net.Proxy$Type")
>> >> >> >> ),
>> >> >> >> name);
>> >> >> >> }
>> >> >> >>
>> >> >> >>
>> >> >> >> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>> >> >> >>
>> >> >> >> public static Type valueOf(String s)
>> >> >> >> {
>> >> >> >> Type atype[];
>> >> >> >> Type type1;
>> >> >> >> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> >> >> >> if(s.equals((type1 = atype[i]).name()))
>> >> >> >> return type1;
>> >> >> >> throw new IllegalArgumentException(s);
>> >> >> >> }
>> >> >> >>
>> >> >> >>
>> >> >> >> In the Sun compiler a null name argument gets passed to
>> >> >> >> Enum#valueOf(Class, String) where I check and throw NPE.
>> >> >> >>
>> >> >> >> In the Eclipse compiler the line if(s.equals(...)... will cause
>> >> a NPE
>> >> >> >> iff there are entries in the VALUES array (otherwise it
>> doesn't go
>> >> >> into
>> >> >> >> the for-loop) and throws an IAE without going into my code.
>> >> >> >>
>> >> >> >> Maybe I can withdraw the null name test while we settle this?
>> >> >> >
>> >> >> > We now have 3 tests failing
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Mikhail
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >> Tim
>> >> >> >>
>> >> >> >>
>> >> >> >> Andrew Zhang wrote:
>> >> >> >> > Hi, Stepan,
>> >> >> >> >
>> >> >> >> > The test you metioned is passed in my environment:
>> >> >> >> > RI version: 1.5.0_02.
>> >> >> >> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >> >> >> >
>> >> >> >> > Is the problem caused by earlier version javac?
>> >> >> >> >
>> >> >> >> > I remember that RI of earlier verion throws IAE instead of NPE
>> >> >> when the
>> >> >> >> > arguement is null.
>> >> >> >> >
>> >> >> >> > Would you please check "java" version?
>> >> >> >> >
>> >> >> >> > Thanks.
>> >> >>
Re: [jchevm+classlibadapter] Running classlib tests
On 7 June 2006 at 13:32, "Weldon Washburn" <[EMAIL PROTECTED]> wrote: > Mark, > > Indeed impressive! And a big thank you for doing this. I didn't really do much. You, Ivan and Archie had already done the real work. I just hacked a few small methods and wrote a small "java" wrapper to get the tests to run. > I also want to thank Ivan Volosyuk for his mods to areas like > VMStackWalker, ClassLoader, StackTraceElement, etc. It is an > important contribution. Agreed! The test failure reports would be pretty meaningless without this! > I look forward to your next email on classlibadapter. Want to try adding support for -Xbootclasspath/a to the wrapper to get a few more tests running. Then I'll jira the bits I've been using and post some test results. After that I might take a look at producing some ant/make scripts for building the classlibadapter. Regards, Mark. > On 6/7/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Darn impressive. > > > > Mark Hindess 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. > > > > > > Will provide more details of what I had to do to run the tests and some > > > of the causes of failures in the next couple of days. > > > > > > 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] > > > > > > > -- > 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: [jira] Created: (HARMONY-574) [classlib][util]Java 5 Enhancement:new class java.util.PriorityQueue
If we choose to pick up the concurrency utilities we will get j.u.PriorityQueue from there. I wouldn't spend any time on it right now if I were you. Regards, Tim Paulex Yang (JIRA) wrote: > [classlib][util]Java 5 Enhancement:new class java.util.PriorityQueue > > > Key: HARMONY-574 > URL: http://issues.apache.org/jira/browse/HARMONY-574 > Project: Harmony > Type: Bug > > Components: Classlib > Reporter: Paulex Yang > Priority: Minor > > > There is a new class java.util.PriorityQueue in Java 5, but it is not > implemented in Harmony(project luni). I'll attach patch soon. > -- 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: [tools] I want to implement keytool - have a question
Thanks for your welcome and consultations.:) I'll be happy to do something helpful. I'm going to create a JIRA issue and post the stubs today. I have tried to run stubs with the launcher. "Hello world" is printed fine. :) Thanks, Anton. 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>: Anton Rusanov wrote: > Hello. > I looked through Harmony code and I think I can implement the Keytool for > the project using existing classes. I've already played with the thing and > it doesn't seem to be very hard to do. I'm going to create a couple of > files > with stubs and gradually replace stubs with implementation using patches. Great. > And I have a question. What should I do to make the keytool run with the > launcher being developed here? Define the class org.apache.harmony.tools.keytool.Main which will be packaged into tools.jar. It should have a public static void main(String args[]) which will be passed the command-line arguments that were given to the keytool launcher. (Of course, you can develop & test your code by running that main() directly from a regular launcher in the IDE too) Sounds like the incentive I needed to hook in the tools build . 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: [classlib] proposal - resolution to java.util.concurrent issue
Geir Magnusson Jr wrote: > > Nathan Beyer wrote: >> I'm all for it, especially if Doug is okay with it. > > I can certainly say that Doug would prefer it. > >> I made an attempt at >> using the code a week back and it should be fairly easy to get the majority >> of it in. The missing piece would be a VMI API for the atomic and lock >> functionality. > > Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for > J9 to continue to work. Sure, it would require we switch to a 1.5 VM, but that is not a bad thing (and warrants another thread). Regards, Tim >> Would we be using the latest version from HEAD, or is there a tag we should >> begin with? The latest code seems to have some Java 6 classes. Would we >> leave them out for now, or just leave them in? > > There probably is a tag for the latest Java 5 version, and I'd leave > them out to limit confusion (and so we can use the same version that > Sun/IBM/BEA is using) but I don't feel strongly at all about this. > > geir > > >> -Nathan >> >>> -Original Message- >>> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, June 07, 2006 10:29 AM >>> To: harmony-dev@incubator.apache.org >>> Subject: [classlib] proposal - resolution to java.util.concurrent issue >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> Comments? Things that I missed? >>> >>> 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] > > -- 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] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Vladimir, Vladimir Ivanov wrote: Thanks Paulex! I did the same, but could not send results due to spam filter J Observations: 1. Coverage results look pretty much similar. 2. Exclude list looks pretty much similar too, but, looks like it depends on the way of data collection (I didn't run ant task and the list is a little bit different). Great. In any case, I think, when we run harmony on another VM exclude list will have to be updated. May be we can start publishing the coverage information on wiki pages and provide some updates time to time (I can do it)? +1, and of course, you can only if no one in the mailing list objects and you'll have my welcome, and I think it will be even greater if these reports can be generated regularly like what JAPI is doing:) One note: I noticed that different unit tests have very different package names Now the directory with all built tests copied to one place looks like: I think we have got a agreement on the test naming convention[1], but for sure, there have been many (legacy) test cases before this agreement, and I think the volunteer is highly welcome to provide patch for them. [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html C:\coverage\tests\test>ls GZIPOutClose2.txtapi config javax tests GZIPOutFinish.txtapi.injected dazzle orgxml GZIPOutWrite.txt binarygifprefs Inet6Address.golden.ser bundles impl serialization JDK2-3gabba.zip com impl.injected test.txt I think, it would be good if tests had unified package names. Why? – so far, just common sense, just to have an order in test suite Organization (if consider all unit tests as solid test suite). Thanks, Vladimir For example, my exclude list for java.io is: -java.io.BufferedInputStream, -java.io.BufferedOutputStream, -java.io.File, -java.io.FileChannelFactory, -java.io.FileDescriptor, -java.io.FileInputStream, -java.io.FileOutputStream, -java.io.FilterInputStream , -java.io.FilterOutputStream, -java.io.InputStream, -java.io.OutputStream, -java.io.ObjectStreamField, -java.io.PrintStream On 6/6/06, Paulex Yang <[EMAIL PROTECTED]> wrote: I've attach the scripts and excluded class lists to JIRA, please refer to https://issues.apache.org/jira/browse/HARMONY-564. Enjoy it:). Mark Hindess wrote: > On 2 June 2006 at 10:37, Paulex Yang <[EMAIL PROTECTED]> wrote: > >> Mark, >> >> I'm glad that there is someone else has interest on emma, I've tried it >> before. AFAIK, emma works by instrumentation, but sometimes for classes >> in bootclasspath, the instrumentation cannot work, there are two cases: >> 1. Some instrumented classes cannot be loaded by VM. >> 2. Some classes cannot be instrumented >> >> I have tried to look more inside to find some way to work around but I >> haven't got enough time yet. >> >> Specifically for nio-channel module, I had a list for these two cases (I >> believe the data is a little outdated and should be reevaluated) >> case 1. >> BaseByteBuffer.class >> Buffer.class >> BufferFactory.class >> ByteBuffer.class >> CharArrayBuffer.class >> CharBuffer.class >> HeapByteBuffer.class >> ReadWriteCharArrayBuffer.class >> ReadWriteHeapByteBuffer.class >> FileChannel.class >> AbstractInterruptibleChannel.class >> FileChannelImpl.class >> WriteOnlyFileChannel.class >> LockManager.class >> LockManager$1.class >> ReadOnlyFileChannel.class >> >> case 2: >> ByteChannel.class >> Channel.class >> GatheringByteChannel.class >> InterruptibleChannel.class >> WritableByteChannel.class >> >> And I have got some ant script and more excluded list for emma, if >> anyone has interests, I can upload it to JIRA. >> > > Yes! > > -Mark. > > >> Mark Hindess wrote: >> >>> Anyone tried using emma (emma.sf.net) to look at test coverage for our >>> tests? That might help ensure we don't trim them down too much? >>> >>> I suspect we will soon reach a point where there are significantly fewer >>> obvious opportunities for small contributions - e.g. 1.5generification, >>> etc from looking at JAPI reports. Having test coverage reports might >>> help by highlighting areas for improvement. >>> >>> I had a quick try with: >>> >>> ant -f make/build.xml >>> ant -f modules/nio/make/build.xml test >>> java -cp emma.jar emma instr -m overwrite -cp deploy/jdk/jre/lib/boot/nio >>> >> .jar >> >>> and then: >>> >>> java -Xbootclasspath/p: emma.jar \ >>>-cp build/tests:modules/nio/bin/test:junit.jar:. \ >>>junit.textui.TestRunner \ >>>org.apache.harmony.tests.java.nio.channels.SocketChannelTest >>> >>> (Running all the tests is a little tricky because test depends on build, >>> which depends on clean which wipes out the instr'd jar. ;-( ) >>> >>> Sadly it dies horribly with the stack trace below. I'll take another >>> look when I have a little more time, but I thought I'd mention it i
Re: [classlib] Enum ready to go
now two out of three yesterday's tests pass, one still fails:
tests.api.java.net.AuthenticatorTest
Thanks,
Mikhail
2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
So the ECJ folk are going to modify their compiler to dispatch to
Enum#valueOf(Class, String) too [1] -- which means we get to decide the
exception thrown by a null name.
The old Sun-based compilers (like the BEA one referenced below) and
current ECJ will throw an IAE for empty enums and NPE for non-empty
enums, and I don't see that we can influence that code.
If we want the same tests to pass on both old and new compilers we'll
have to allow either exception.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=145746
Regards,
Tim
Mikhail Loenko wrote:
> javac and java are from the same distrib (javac does not print
> detailed version info,
> that is why I''m mentioning java version),
> so it is javac 1.5.0_b64
>
> so I compile with JDK 1.5.0_b64, run on Harmony and it fails
>
> Thanks,
> Mikhail
>
> 2006/6/7, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
>> Mikhail Loenko wrote:
>> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
>> >> using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target 1.4
>> >> set.
>> >>
>> >> I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
>> >> empty, but seems a bit of a drag to work around the compilers.
>> >>
>> >> (which version of BEA javac?)
>> >
>> > javac -version prints just "1.5.0"
>> > java -version prints "build 1.5.0-b64"
>> >
>>
>> I would bet the tests shall pass if using javac of java-version "build
>> 1.5.0_01" or later :)
>> And as the tests also fail on RI of "build 1.5.0-b64" (I've just find
>> one:) ), I guess it is a bug of RI, which was fixed in the later version.
>>
>> What's more, shall we also suggest that everyone use a latest version of
>> javac to avoid such problem?
>>
>>
>> >
>> >>
>> >> Regards,
>> >> Tim
>> >>
>> >> Mikhail Loenko wrote:
>> >> > Are you compiling with "jsr14" as our build does?
>> >> >
>> >> > I'm using BEA javac with "jsr14" it compiles to something like this:
>> >> > for(i=0; i < values.length; i++ )
>> >> > if( values[i].name().equals(argument) )
>> >> > return values[i].name().equals(argument)
>> >> > throw IAE
>> >> >
>> >> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> >> Maybe compiler specific.
>> >> >>
>> >> >> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> >> >> delegates to the Enum type:
>> >> >>
>> >> >> public static Type valueOf(String name)
>> >> >> {
>> >> >> return (Type)Enum.valueOf(
>> >> >> Proxy.class$java$net$Proxy$Type != null ?
>> >> >> Proxy.class$java$net$Proxy$Type :
>> >> >> (
>> >> >> Proxy.class$java$net$Proxy$Type =
>> >> >> Proxy._mthclass$("java.net.Proxy$Type")
>> >> >> ),
>> >> >> name);
>> >> >> }
>> >> >>
>> >> >>
>> >> >> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>> >> >>
>> >> >> public static Type valueOf(String s)
>> >> >> {
>> >> >> Type atype[];
>> >> >> Type type1;
>> >> >> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> >> >> if(s.equals((type1 = atype[i]).name()))
>> >> >> return type1;
>> >> >> throw new IllegalArgumentException(s);
>> >> >> }
>> >> >>
>> >> >>
>> >> >> In the Sun compiler a null name argument gets passed to
>> >> >> Enum#valueOf(Class, String) where I check and throw NPE.
>> >> >>
>> >> >> In the Eclipse compiler the line if(s.equals(...)... will cause
>> a NPE
>> >> >> iff there are entries in the VALUES array (otherwise it doesn't go
>> >> into
>> >> >> the for-loop) and throws an IAE without going into my code.
>> >> >>
>> >> >> Maybe I can withdraw the null name test while we settle this?
>> >> >
>> >> > We now have 3 tests failing
>> >> >
>> >> > Thanks,
>> >> > Mikhail
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> Regards,
>> >> >> Tim
>> >> >>
>> >> >>
>> >> >> Andrew Zhang wrote:
>> >> >> > Hi, Stepan,
>> >> >> >
>> >> >> > The test you metioned is passed in my environment:
>> >> >> > RI version: 1.5.0_02.
>> >> >> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >> >> >
>> >> >> > Is the problem caused by earlier version javac?
>> >> >> >
>> >> >> > I remember that RI of earlier verion throws IAE instead of NPE
>> >> when the
>> >> >> > arguement is null.
>> >> >> >
>> >> >> > Would you please check "java" version?
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>> >> >> >>
>> >> >> >> I found the reason - tests expect NPE when valueOf(null) is
>> invoked
>> >> >> but
>> >> >> >> IAE
>> >> >> >> is thrown instead. For example,
>> >> >> >>
>> >> >> >> java.lang.IllegalArgumentException
>> >> >> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> >> >> >> EnumTest.java
>> >> >> >> :22)
>> >> >> >> at
>> >> >> >>
>> >> >>
>> >>
>> org.apache.harmony.test
Re: [VOTE] Acceptance of Harmony-528 : AWT, Java2D and Swing
+1 On 6/6/06, Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-528, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase 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. Again, I think that getting this into SVN and letting people supply patches against SVN will be productive. Also, there's a lot of excitement around getting this in and a binary snapshot created... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura 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] Enum ready to go
Mikhail Loenko wrote:
javac and java are from the same distrib (javac does not print
detailed version info,
that is why I''m mentioning java version),
so it is javac 1.5.0_b64
so I compile with JDK 1.5.0_b64, run on Harmony and it fails
Yes, and please note RI's strange version style, 1.5.0_b64 is earlier
than 1.5.0_01, and the latest is 1.5.0_06. (As we see, 1.5.0_b64 surely
means 1.5.0_00_b64, and it really puzzles me at the first glance :) )
Thanks,
Mikhail
2006/6/7, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
> 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
>> using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target 1.4
>> set.
>>
>> I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
>> empty, but seems a bit of a drag to work around the compilers.
>>
>> (which version of BEA javac?)
>
> javac -version prints just "1.5.0"
> java -version prints "build 1.5.0-b64"
>
I would bet the tests shall pass if using javac of java-version "build
1.5.0_01" or later :)
And as the tests also fail on RI of "build 1.5.0-b64" (I've just find
one:) ), I guess it is a bug of RI, which was fixed in the later version.
What's more, shall we also suggest that everyone use a latest version of
javac to avoid such problem?
>
>>
>> Regards,
>> Tim
>>
>> Mikhail Loenko wrote:
>> > Are you compiling with "jsr14" as our build does?
>> >
>> > I'm using BEA javac with "jsr14" it compiles to something like this:
>> > for(i=0; i < values.length; i++ )
>> > if( values[i].name().equals(argument) )
>> > return values[i].name().equals(argument)
>> > throw IAE
>> >
>> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> Maybe compiler specific.
>> >>
>> >> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> >> delegates to the Enum type:
>> >>
>> >> public static Type valueOf(String name)
>> >> {
>> >> return (Type)Enum.valueOf(
>> >> Proxy.class$java$net$Proxy$Type != null ?
>> >> Proxy.class$java$net$Proxy$Type :
>> >> (
>> >> Proxy.class$java$net$Proxy$Type =
>> >> Proxy._mthclass$("java.net.Proxy$Type")
>> >> ),
>> >> name);
>> >> }
>> >>
>> >>
>> >> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>> >>
>> >> public static Type valueOf(String s)
>> >> {
>> >> Type atype[];
>> >> Type type1;
>> >> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> >> if(s.equals((type1 = atype[i]).name()))
>> >> return type1;
>> >> throw new IllegalArgumentException(s);
>> >> }
>> >>
>> >>
>> >> In the Sun compiler a null name argument gets passed to
>> >> Enum#valueOf(Class, String) where I check and throw NPE.
>> >>
>> >> In the Eclipse compiler the line if(s.equals(...)... will cause
a NPE
>> >> iff there are entries in the VALUES array (otherwise it doesn't go
>> into
>> >> the for-loop) and throws an IAE without going into my code.
>> >>
>> >> Maybe I can withdraw the null name test while we settle this?
>> >
>> > We now have 3 tests failing
>> >
>> > Thanks,
>> > Mikhail
>> >
>> >
>> >
>> >>
>> >> Regards,
>> >> Tim
>> >>
>> >>
>> >> Andrew Zhang wrote:
>> >> > Hi, Stepan,
>> >> >
>> >> > The test you metioned is passed in my environment:
>> >> > RI version: 1.5.0_02.
>> >> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >> >
>> >> > Is the problem caused by earlier version javac?
>> >> >
>> >> > I remember that RI of earlier verion throws IAE instead of NPE
>> when the
>> >> > arguement is null.
>> >> >
>> >> > Would you please check "java" version?
>> >> >
>> >> > Thanks.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> I found the reason - tests expect NPE when valueOf(null) is
invoked
>> >> but
>> >> >> IAE
>> >> >> is thrown instead. For example,
>> >> >>
>> >> >> java.lang.IllegalArgumentException
>> >> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> >> >> EnumTest.java
>> >> >> :22)
>> >> >> at
>> >> >>
>> >>
>>
org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> >> >> (EnumTest.java :113)
>> >> >> at
>> >>
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>> >> >>
>> >> >> Thanks,
>> >> >> Stepan.
>> >> >>
>> >> >> On 6/7/06, Andrew Zhang wrote:
>> >> >> >
>> >> >> > Hello Stepan and Mikhail,
>> >> >> >
>> >> >> > All tests passed on my machine.
>> >> >> >
>> >> >> > Which test case was failed in your environment, on RI or
Harmony?
>> >> >> >
>> >> >> > Thanks!
>> >> >> >
>> >> >> >
>> >> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>> >> >> > >
>> >> >> > > Hi Tim,
>> >> >> > >
>> >> >> > > On 6/7/06, Tim Ellison wrote:
>> >> >> > > >
>> >> >> > > > Heads up that I completed the implementation of j.l.Enum
>> >> today; so
>> >> >> you
>> >> >> > > > can go mad and use enum types in classlib code for real
now.
>> >> >> > >
>> >> >> > >
RE: [classlib] proposal - resolution to java.util.concurrent issue
> -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 6:37 PM > To: harmony-dev@incubator.apache.org > Subject: Re: [classlib] proposal - resolution to java.util.concurrent > issue > > > > Nathan Beyer wrote: > > I'm all for it, especially if Doug is okay with it. > > I can certainly say that Doug would prefer it. > > > I made an attempt at > > using the code a week back and it should be fairly easy to get the > majority > > of it in. The missing piece would be a VMI API for the atomic and lock > > functionality. > > Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for > J9 to continue to work. > One way to address some of this would be to begin with just the j.u.c classes only; from what I could tell most if not all of them didn't have any dependencies on the atomic and lock sub packages. Also, I think we could stub out the VMI API such that other classes would at least compile. I'm not extremely familiar with the atomic APIs, but I think would could go as far to build a temporary atomicity implementation by using plain-old synchronized locks ... maybe. :) > > > > Would we be using the latest version from HEAD, or is there a tag we > should > > begin with? The latest code seems to have some Java 6 classes. Would we > > leave them out for now, or just leave them in? > > There probably is a tag for the latest Java 5 version, and I'd leave > them out to limit confusion (and so we can use the same version that > Sun/IBM/BEA is using) but I don't feel strongly at all about this. > > geir > > > > > > -Nathan > > > >> -Original Message- > >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, June 07, 2006 10:29 AM > >> To: harmony-dev@incubator.apache.org > >> Subject: [classlib] proposal - resolution to java.util.concurrent issue > >> > >> 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. > >> > >> 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. > >> > >> 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. > >> > >> Comments? Things that I missed? > >> > >> 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 unsub
Re: [classlib] proposal - resolution to java.util.concurrent issue
Nathan Beyer wrote: > I'm all for it, especially if Doug is okay with it. I can certainly say that Doug would prefer it. > I made an attempt at > using the code a week back and it should be fairly easy to get the majority > of it in. The missing piece would be a VMI API for the atomic and lock > functionality. Maybe Tim/George/Mark/Oliver can give us a hint ;) It would be nice for J9 to continue to work. > > Would we be using the latest version from HEAD, or is there a tag we should > begin with? The latest code seems to have some Java 6 classes. Would we > leave them out for now, or just leave them in? There probably is a tag for the latest Java 5 version, and I'd leave them out to limit confusion (and so we can use the same version that Sun/IBM/BEA is using) but I don't feel strongly at all about this. geir > > -Nathan > >> -Original Message- >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, June 07, 2006 10:29 AM >> To: harmony-dev@incubator.apache.org >> Subject: [classlib] proposal - resolution to java.util.concurrent issue >> >> 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. >> >> 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. >> >> 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. >> >> Comments? Things that I missed? >> >> 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] proposal - resolution to java.util.concurrent issue
I'm all for it, especially if Doug is okay with it. I made an attempt at using the code a week back and it should be fairly easy to get the majority of it in. The missing piece would be a VMI API for the atomic and lock functionality. Would we be using the latest version from HEAD, or is there a tag we should begin with? The latest code seems to have some Java 6 classes. Would we leave them out for now, or just leave them in? -Nathan > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 10:29 AM > To: harmony-dev@incubator.apache.org > Subject: [classlib] proposal - resolution to java.util.concurrent issue > > 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. > > 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. > > 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. > > Comments? Things that I missed? > > 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]
[general] More SVN restructuring thoughts... (was Re: Ant build | IOException)
This brings up a good point. (I'm so used to CVS, I keep forgetting that branches and tags really don't exist in SVN...) We have been talking a little about how to 'federate' things so that we have a harmony project, rather than separate islands of activity, so that a user can type 'build' somewhere, and get a full working system w/ tools, vm and classlib. The problem that we'll face is that we have harmony/classlib/trunk classlib/branches classlib/tags classlib/archive harmony/drlvm/trunk drlvm/branches ... So you get a big pile of stuff whenever you do a svn co on root, as Garrett points out. I was chatting about this w/ Garrett, who is a real SVN guru, and he suggested we do the following - * setup harmony/trunk as the federation point w/ empty directories for /tools, /vm, /classlib, whatever * setup a fetch script so that it does an svn switch for each of them into the right part of the svn tree (letting people choose among VM choices, versions of classlib, etc). You could also just use a symlink to point up and over to /harmony/classlib/trunk * build from that set So we'd end up with /harmony /classlib /trunk /... /drlvm /trunk /... /trunk /build build.xml ... /target < where the build goes > /classlib /vm /tools This seems like it gives us incredible freedom, ease for someone that wants to just do a top-level build (svn co harmony/trunk; setup vm=drlvm classlib=head; build) and see what they get, and doesn't hammer SVN so hard... If no one thinks of a problem, I'll try this. I doesn't change the fact that projects should be able to push generated artifacts into a common directory, but does make things easy to setup and work with efficiently. Thanks Garrett! geir Garrett Rooney wrote: > On 6/7/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote: > >> svn checkout https://svn.apache.org/repos/asf/incubator/harmony >> >> ant -f harmony/enhanced/classlib/trunk/make/depends.xml download > > Please don't check out the root of the harmony tree. It's incredibly > wasteful, that's far more content than you need, and it'll only get > worse as more tags and branches are created. > > If you want to check out the trunk of the classlib, check out the > trunk of the classlib: > > svn checkout > https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk > classlib > > -garrett > > - > 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]
[testing] new subcomponent of Harmony?
As we start to flesh out the project more and more, one of the things we've talked about is testing (and I don't mean unit tests..). I think that our testing infrastructure and results tracking is going to be a very significant undertaking in the project, and the time feels right to seriously make it a part of the project. I've thought about this a bit, and while I'm sure we'll probably get something setup here at the ASF, I honestly don't think a single resource like the ASF (or anyone) will be able to match what we can do together as a distributed community, in terms of numbers or variety. Therefore, given that have been significant achievements in this already (like what IBM has running...), and I'm sure that there are many others interested with contributions of code as well as time, I'd like to propose... * Add /testing (or some other appropriate name) off of root, as a peer to /classlib, /jchevm, /drlvm etc * Bring together what various people are using into a unified and easy-to-use setup in SVN that anyone can just download, configure and run (Hey, Mark!) * Setup a place on the website to track who is doing what platform. This way, no one entity has any "responsibility" for doing this for the community - we all do it - and we all share in contributing to the infrastructure. I'd certainly setup a machine at home to do this, and I'd work to get something setup inside my employer, Intel. I bet a lot of other people would as well. Thoughts? 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: Ant build | IOException
On 6/7/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote: svn checkout https://svn.apache.org/repos/asf/incubator/harmony ant -f harmony/enhanced/classlib/trunk/make/depends.xml download Please don't check out the root of the harmony tree. It's incredibly wasteful, that's far more content than you need, and it'll only get worse as more tags and branches are created. If you want to check out the trunk of the classlib, check out the trunk of the classlib: svn checkout https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk classlib -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: Ant build | IOException
Anoop kumar V skrev den 30-05-2006 04:36: Hi, I am a n00b wanting to contribute to Harmony. All I have done so far (code-wise) is checkout the harmony code (revision 410710) from svn and run ant from ~/Harmony/make folder. I have just done the exercise for the first time with a fresh Ubuntu 6.06 installation, and it is possible just with gij (i.e. without downloading a JDK) as the ecj is one of the depent downloads (and I hope that it is usable, as I recall there was a compiler issue at one time). I cannot recall at the moment if I installed gcj explicitly or it gets in as an ant dependency. I copy the installation to a fresh deploy directory just to ensure that it is only updated when I want it to. --- sudo apt-get install ant gcc make mkdir harmony cd harmony // now get the Harmony-vme-linux.IA32-v3.tar.gz from IBM and store it in the harmony directory svn checkout https://svn.apache.org/repos/asf/incubator/harmony ant -f harmony/enhanced/classlib/trunk/make/depends.xml download CLASSPATH=harmony/enhanced/classlib/trunk/depends/jars/ecj_3.2RC5/ecj_3.2RC5.jar ant -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter -f harmony/enhanced/classlib/trunk/make/build.xml cp -R harmony/enhanced/classlib/trunk/deploy . tar xvzf Harmony-vme-linux.IA32-v3.tar.gz -C deploy/jdk export PATH=$(pwd)/deploy/jdk/jre/bin:$PATH Now "java -version" should report java version 1.5 (subset) (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable. Please let me know if there is any inaccuracies in the above. -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
Re: [jchevm+classlibadapter] Running classlib tests
Wow! I've just wanted to run eclipse :) And it requires a bunch of the functionality. Thank you, Mark, it is great to know that I am not only one who interested in the adapter. It was quite interesting to get something work. Now, it becoming increasingly difficult to dig deep into eclipse internal searching for new failures. It seems that classlib tests can do this task easier. I am going to do some more hacking at weekend. For now I have one small fix for ThreadLocal implementation. I will create corresponding jira today. Btw, it will be good if all such jiras will be linked to each other as relatives. They will be easy to find. -- Ivan 2006/6/7, Geir Magnusson Jr <[EMAIL PROTECTED]>: Darn impressive. Mark Hindess 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. > > Will provide more details of what I had to do to run the tests and some > of the causes of failures in the next couple of days. > > Regards, > Mark. -- 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]
[DRLVM] jitting MMTk vmmagic classes -- first stab at the requirements
All,
Below is a first stab at defining what the JIT needs to be aware of
when compiling the vmmagic classes. I am hoping the MMTk crowd will
correct the mistakes in the below example.
There are multiple ways of doing address arithmetic with the vmmagic
classes. The below is intended to illustrate specific pointer
handling concepts so that folks working on the compiler can figure out
what the JIT is supposed to do. It is not necessarily the best
approach or representative of what a GC would ever do.
In a little while, I will attempt to map this example to machine code
that Jitrino.JET could generate. Admittedly the code quality will be
bad or maybe even broken. However, the motivation is to show the
compiler folks how a JIT could generate vmmagic.unboxed code.
// a bunch of non-vmmagic code (normal java code)...
public class Green {
int f1;
Green obj1;
}
Green g1 = new Green();
//beginning of code that involves vmmagic
ObjectReference oRef = ObjectReference.fromObject((Object)g1); //oRef
is an unboxed ref ptr, the JIT is always required to enumerate oRef
Address aa = oRef.toAddress(); //aa is an unboxed raw pointer, JIT
should never enumerate aa and aa can only exist within the scope of
the "Uninterruptible" interface
int ptrBits = aa.toInt(); // the MMTk developer must be very careful
to keep all raw heap ptrs within the scope of an "Uninterruptible".
Question: are there any tools to help the developer handle this
properly?
ptrBits = ptrBits + 12; // ugly code, but for sake of illustration
assume the obj1 field is at location ref ptr + 12
Address interiorPtr = new Address(ptrBits); // again, the JIT should
never enumerate interiorPtr
ObjectReference oRef2 = interiorPtr.loadObjectReference(); // the JIT
must enumerate oRef2
Green g2 = oRef2.toObject();
//end of code that involves vmmagic
g2.f1 = 45;
// a bunch of non-vmmagic code (normal java code)…
--
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: [jchevm+classlibadapter] Running classlib tests
Mark, Indeed impressive! And a big thank you for doing this. I also want to thank Ivan Volosyuk for his mods to areas like VMStackWalker, ClassLoader, StackTraceElement, etc. It is an important contribution. I look forward to your next email on classlibadapter. On 6/7/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Darn impressive. Mark Hindess 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. > > Will provide more details of what I had to do to run the tests and some > of the causes of failures in the next couple of days. > > 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] -- 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: [jchevm+classlibadapter] Running classlib tests
Darn impressive. Mark Hindess 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. > > Will provide more details of what I had to do to run the tests and some > of the causes of failures in the next couple of days. > > 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]
[jchevm+classlibadapter] Running classlib tests
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. Will provide more details of what I had to do to run the tests and some of the causes of failures in the next couple of days. 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: >> 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. > > 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... 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 . 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]
Re: [classlib] proposal - resolution to java.util.concurrent issue
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)? 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)? > 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? > 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 . 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]
[classlib] proposal - resolution to java.util.concurrent issue
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. 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. 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. Comments? Things that I missed? 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: [tools] I want to implement keytool - have a question
Geir Magnusson Jr wrote: > so explain in more detail :) Someone might sign up... The deploy directory does not currently contain all the build-time requirements for the native code launcher (it needs hyprt.lib and hycomp.h etc. etc.) or the java-based tooling tests (it will need the test support classes). Oliver has already signed up to getting those in place for each module to compile against, and that will do fine for tools too (even if they are not in /classlib). Regards, Tim > Tim Ellison wrote: >> yeah, and it can compile against the hdk! >> >> Seriously though, if we pull the launcher and java tools out of >> /classlib it will need to compile against some .h's, libs and JARs that >> we currently do not put into deploy. We should aim for that, but that's >> more than I was signing up to do right now. >> >> Regards, >> Tim >> >> Geir Magnusson Jr wrote: >>> Elford, Chris L wrote: Geir writes: >> Maybe it's time to pull tools out? I'm not quite sure what you are suggesting. Pulling them out of the build? Placing them somewhere else in the repository? >>> Sorry. I mean to put together a tools 'subsection' in the project, so >>> it's 'front and center'. >>> >>> IOW, we now have as our svn repo : >>> >>> /classlib >>> /drlvm >>> /jchevm >>> >>> so I was thinking we bring the tools 'stuff' from /classlib and move to >>> >>> /tools >>> >>> geir >>> Thanks, Chris Elford Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 5:31 AM To: harmony-dev@incubator.apache.org Subject: Re: [tools] I want to implement keytool - have a question Maybe it's time to pull tools out? Tim Ellison wrote: > Anton Rusanov wrote: >> Hello. >> I looked through Harmony code and I think I can implement the Keytool for >> the project using existing classes. I've already played with the thing and >> it doesn't seem to be very hard to do. I'm going to create a couple of >> files >> with stubs and gradually replace stubs with implementation using patches. > Great. > >> And I have a question. What should I do to make the keytool run with the >> launcher being developed here? > Define the class > > org.apache.harmony.tools.keytool.Main > > which will be packaged into tools.jar. It should have a > > public static void main(String args[]) > > which will be passed the command-line arguments that were given to the > keytool launcher. > > (Of course, you can develop & test your code by running that main() > directly from a regular launcher in the IDE too) > > Sounds like the incentive I needed to hook in the tools build . > > 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] >>> - >>> 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: Supporting working on a single module?
On 7 June 2006 at 10:52, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > On 7 June 2006 at 9:42, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> Oliver Deakin wrote: > >>> Just thought Id give a bit of a heads up on HARMONY-561. > >>> The patch attached to that JIRA moves the header files under the > >>> native-src//include directories into > >>> /modules//src/main/native. It also updates the build > >>> scripts and > >>> makefiles to move the headers into a shared location (/include, as > >>> described at [1]) and compile against their new location. > >> Right, and I really don't like it, have been saying I don't like > >> overwriting the HDK, gave a reason for why I don't like it, and never > >> heard a reason why it must be this way. > > > > It's no different to how we've been deploying java code for the last > > several months. > > Sure it is, if you think of the HDK as a binary snapshot you can build > against. > > > That is, if you build at the top level, you are > > effectively creating the java parts of the jre (which is part of the > > large hdk). If you then go and build in say modules/luni, you are > > building against the jars in the "hdk/jdk/jre/lib/boot" directory and > > the new luni.jar will be overwrite the existing one. > > That's misleading, because there is no 'hdk' now. > > There's nothing wrong with having a /deploy or /target directory that we > build into in parallel w/ the hdk, and no one's told me why that's a bad > idea, since *that* is how we've been working for several months now. Ok. This is all Oliver's changes are doing - building native code into /deploy? So your objection is that we are calling this directory the hdk? When the hdk should be an artifact that we just keep zipped up and unpack (possibly as part of the build) to deploy before building anything that overwrites it? (This has the advantage that we don't have to change the launcher.) > Remember, the motivation for this change is to modularize the natives, > not the hdk. lets not let the tail wag the dog here. > > > So if Oliver is breaking anything by these changes, then it is > > nothing that wasn't broken before for the java code building > > process. So I don't see the harm in proceeding because without this > > or something like it, it is impossible to move forward with (long > > overdue) the native-src restructuring. > > I don't think I said he was breaking anything. I said that I felt > that any alternatives that I suggested that got us to the same place, > yet in what I felt lead to clarity and diversity in use case were > ignored. > > Isn't anyone else bothered by the build process dropping artifacts > into and overriding what is an SDK? I think I understand why someone might be bothered but I'm not really concerned. If I want a pristine copy back I just unzip it again. I don't see the immediate benefit of keeping a pristine copy unzip'd. The only advantage I see that comes from not changing the unzip'd copy would be that you could have just one unzip'd pristine copy. But without changing the launcher (and complicating things for every user not just developers) I don't see how you could use a single copy, unless you copy it which would negate this advantage. > > No one has felt a pressing need to solve the problem with respect to > > the java code parts of the hdk (jre) being overwritten so I don't > > see why we now need to solve that problem first. > > You are mixing two things up here. No one cares if we overwrite > stuff in the build destination - that's a necessity - and that's not > the issue. The issue is confusing the hdk, something that we'll > distribute as snapshots or versioned releases, w/ the build target. Ok. Let's stop calling what Oliver is doing an hdk then. > >> If you want me to put my money where my mouth is and just patch > >> it, I'm more than able to do that, but I'd rather reach consensus > >> together on how to go forward. > > > > I'd prefer the consensus approach too. > > > > Having said that I am interested in how you would patch it. I've > > not clearly understood how it should be solved/patched. Ignoring > > the native code for a moment, how do you propose to solve the > > problem with respect to the hdk/jdk/jre/lib/boot jars? Where should > > the jars go when we build at the top level? > > /target/jdk/jre/lib/boot for example > > > > ...and to be honest, I think that it should be in a peer to /classlib, > not inside of clsaslib. > > ... and which the word 'target' up for debate, although I prefer it to > 'deploy', because I think of deploy as a tree created when you push the > button to do a release or snapshot i.e. > > /deploy/harmony-0.5-snapshot/ > > I do think we should consider how we are using these names. I notice that the Apache Commons projects that I was looking at recently use build (or sometimes target) for the build artifacts and dist for the sense in which you think of deploy. > > >
Re: [tools] I want to implement keytool - have a question
so explain in more detail :) Someone might sign up... Tim Ellison wrote: > yeah, and it can compile against the hdk! > > Seriously though, if we pull the launcher and java tools out of > /classlib it will need to compile against some .h's, libs and JARs that > we currently do not put into deploy. We should aim for that, but that's > more than I was signing up to do right now. > > Regards, > Tim > > Geir Magnusson Jr wrote: >> Elford, Chris L wrote: >>> Geir writes: > Maybe it's time to pull tools out? >>> I'm not quite sure what you are suggesting. Pulling them out of the >>> build? Placing them somewhere else in the repository? >> Sorry. I mean to put together a tools 'subsection' in the project, so >> it's 'front and center'. >> >> IOW, we now have as our svn repo : >> >> /classlib >> /drlvm >> /jchevm >> >> so I was thinking we bring the tools 'stuff' from /classlib and move to >> >> /tools >> >> geir >> >>> Thanks, >>> >>> Chris Elford >>> Intel Middleware Products Division >>> >>> -Original Message- >>> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, June 07, 2006 5:31 AM >>> To: harmony-dev@incubator.apache.org >>> Subject: Re: [tools] I want to implement keytool - have a question >>> >>> Maybe it's time to pull tools out? >>> >>> Tim Ellison wrote: Anton Rusanov wrote: > Hello. > I looked through Harmony code and I think I can implement the >>> Keytool for > the project using existing classes. I've already played with the >>> thing and > it doesn't seem to be very hard to do. I'm going to create a couple >>> of > files > with stubs and gradually replace stubs with implementation using >>> patches. Great. > And I have a question. What should I do to make the keytool run with >>> the > launcher being developed here? Define the class org.apache.harmony.tools.keytool.Main which will be packaged into tools.jar. It should have a public static void main(String args[]) which will be passed the command-line arguments that were given to the keytool launcher. (Of course, you can develop & test your code by running that main() directly from a regular launcher in the IDE too) Sounds like the incentive I needed to hook in the tools build . 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] >>> >>> >> - >> 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: Supporting working on a single module?
Geir Magnusson Jr wrote: Oliver Deakin wrote: Just thought Id give a bit of a heads up on HARMONY-561. The patch attached to that JIRA moves the header files under the native-src//include directories into /modules//src/main/native. It also updates the build scripts and makefiles to move the headers into a shared location (/include, as described at [1]) and compile against their new location. Right, and I really don't like it, have been saying I don't like overwriting the HDK, gave a reason for why I don't like it, and never heard a reason why it must be this way. ok, I understand that - perhaps I should have used deploy/include instead of /include in the above description, but I was trying to link the patch with the HDK layout described on the website so it was clear how it would enable us to create and use an HDK. The patches Im submitting at the moment are *not* intended to overwrite a base HDK (which I believe is what you did not like), but rather to place their output in the working deploy directory. What Im currently doing is just attempting to modularise the native code with building against an HDK in mind. This does *not* preclude your suggestion of having an immutable base HDK - in fact, I hope that the work Im doing will enable us to do exactly that. However, before that can happen there is plenty of work to be done reorganising the natives and making the build scripts capable of building against an HDK. In summary, here's what IMHO still needs to be done with the natives to get the HDK use that we have discussed: 1) Reorganise natives into modules (this has been hanging over us for too long!) 2) Alter the build scripts to be capable of building in a modular way (Java and native code) against the contents of the deploy (or target) directory. 3) Finally, alter the build scripts to be capable of building against a base HDK that is immutable (i.e. your suggestion) but still putting its produced binaries into the deploy directory (so not overwriting the base HDK content). Does that sound good? If you want me to put my money where my mouth is and just patch it, I'm more than able to do that, but I'd rather reach consensus together on how to go forward. Agreed - concensus is preferable and Im glad you brought up the fact that you were unhappy with what was happening and gave me an opportunity to explain. Id like the HDK to be satisfactory and useful to all participants in the project. Regards, Oliver The next piece of work I intend to look at is getting the windows/linux makefiles to build their .lib/.a files directly into the /lib directory (also described in [1]), See above and getting each native component to link against the libs at that location. Once this is done the deploy directory should look like a complete HDK after a global build. ie it will contain everything needed to build each individual native component or java module against it. That is a good outcome if it isn't the hdk directory. If it's the HDK directory, consider me against it. We should then be able to make the final moves of the classlib native code into the modules (and start creating some classlib HDK snapshots). Great. geir Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html - 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] -- 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: [tools] I want to implement keytool - have a question
yeah, and it can compile against the hdk! Seriously though, if we pull the launcher and java tools out of /classlib it will need to compile against some .h's, libs and JARs that we currently do not put into deploy. We should aim for that, but that's more than I was signing up to do right now. Regards, Tim Geir Magnusson Jr wrote: > > Elford, Chris L wrote: >> Geir writes: Maybe it's time to pull tools out? >> I'm not quite sure what you are suggesting. Pulling them out of the >> build? Placing them somewhere else in the repository? > > Sorry. I mean to put together a tools 'subsection' in the project, so > it's 'front and center'. > > IOW, we now have as our svn repo : > > /classlib > /drlvm > /jchevm > > so I was thinking we bring the tools 'stuff' from /classlib and move to > > /tools > > geir > >> Thanks, >> >> Chris Elford >> Intel Middleware Products Division >> >> -Original Message- >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, June 07, 2006 5:31 AM >> To: harmony-dev@incubator.apache.org >> Subject: Re: [tools] I want to implement keytool - have a question >> >> Maybe it's time to pull tools out? >> >> Tim Ellison wrote: >>> Anton Rusanov wrote: Hello. I looked through Harmony code and I think I can implement the >> Keytool for the project using existing classes. I've already played with the >> thing and it doesn't seem to be very hard to do. I'm going to create a couple >> of files with stubs and gradually replace stubs with implementation using >> patches. >>> Great. >>> And I have a question. What should I do to make the keytool run with >> the launcher being developed here? >>> Define the class >>> >>> org.apache.harmony.tools.keytool.Main >>> >>> which will be packaged into tools.jar. It should have a >>> >>> public static void main(String args[]) >>> >>> which will be passed the command-line arguments that were given to the >>> keytool launcher. >>> >>> (Of course, you can develop & test your code by running that main() >>> directly from a regular launcher in the IDE too) >>> >>> Sounds like the incentive I needed to hook in the tools build . >>> >>> 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] >> >> > > - > 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] Enum ready to go
So the ECJ folk are going to modify their compiler to dispatch to
Enum#valueOf(Class, String) too [1] -- which means we get to decide the
exception thrown by a null name.
The old Sun-based compilers (like the BEA one referenced below) and
current ECJ will throw an IAE for empty enums and NPE for non-empty
enums, and I don't see that we can influence that code.
If we want the same tests to pass on both old and new compilers we'll
have to allow either exception.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=145746
Regards,
Tim
Mikhail Loenko wrote:
> javac and java are from the same distrib (javac does not print
> detailed version info,
> that is why I''m mentioning java version),
> so it is javac 1.5.0_b64
>
> so I compile with JDK 1.5.0_b64, run on Harmony and it fails
>
> Thanks,
> Mikhail
>
> 2006/6/7, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
>> Mikhail Loenko wrote:
>> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
>> >> using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target 1.4
>> >> set.
>> >>
>> >> I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
>> >> empty, but seems a bit of a drag to work around the compilers.
>> >>
>> >> (which version of BEA javac?)
>> >
>> > javac -version prints just "1.5.0"
>> > java -version prints "build 1.5.0-b64"
>> >
>>
>> I would bet the tests shall pass if using javac of java-version "build
>> 1.5.0_01" or later :)
>> And as the tests also fail on RI of "build 1.5.0-b64" (I've just find
>> one:) ), I guess it is a bug of RI, which was fixed in the later version.
>>
>> What's more, shall we also suggest that everyone use a latest version of
>> javac to avoid such problem?
>>
>>
>> >
>> >>
>> >> Regards,
>> >> Tim
>> >>
>> >> Mikhail Loenko wrote:
>> >> > Are you compiling with "jsr14" as our build does?
>> >> >
>> >> > I'm using BEA javac with "jsr14" it compiles to something like this:
>> >> > for(i=0; i < values.length; i++ )
>> >> > if( values[i].name().equals(argument) )
>> >> > return values[i].name().equals(argument)
>> >> > throw IAE
>> >> >
>> >> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> >> Maybe compiler specific.
>> >> >>
>> >> >> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> >> >> delegates to the Enum type:
>> >> >>
>> >> >> public static Type valueOf(String name)
>> >> >> {
>> >> >> return (Type)Enum.valueOf(
>> >> >> Proxy.class$java$net$Proxy$Type != null ?
>> >> >> Proxy.class$java$net$Proxy$Type :
>> >> >> (
>> >> >> Proxy.class$java$net$Proxy$Type =
>> >> >> Proxy._mthclass$("java.net.Proxy$Type")
>> >> >> ),
>> >> >> name);
>> >> >> }
>> >> >>
>> >> >>
>> >> >> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>> >> >>
>> >> >> public static Type valueOf(String s)
>> >> >> {
>> >> >> Type atype[];
>> >> >> Type type1;
>> >> >> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> >> >> if(s.equals((type1 = atype[i]).name()))
>> >> >> return type1;
>> >> >> throw new IllegalArgumentException(s);
>> >> >> }
>> >> >>
>> >> >>
>> >> >> In the Sun compiler a null name argument gets passed to
>> >> >> Enum#valueOf(Class, String) where I check and throw NPE.
>> >> >>
>> >> >> In the Eclipse compiler the line if(s.equals(...)... will cause
>> a NPE
>> >> >> iff there are entries in the VALUES array (otherwise it doesn't go
>> >> into
>> >> >> the for-loop) and throws an IAE without going into my code.
>> >> >>
>> >> >> Maybe I can withdraw the null name test while we settle this?
>> >> >
>> >> > We now have 3 tests failing
>> >> >
>> >> > Thanks,
>> >> > Mikhail
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> Regards,
>> >> >> Tim
>> >> >>
>> >> >>
>> >> >> Andrew Zhang wrote:
>> >> >> > Hi, Stepan,
>> >> >> >
>> >> >> > The test you metioned is passed in my environment:
>> >> >> > RI version: 1.5.0_02.
>> >> >> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >> >> >
>> >> >> > Is the problem caused by earlier version javac?
>> >> >> >
>> >> >> > I remember that RI of earlier verion throws IAE instead of NPE
>> >> when the
>> >> >> > arguement is null.
>> >> >> >
>> >> >> > Would you please check "java" version?
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>> >> >> >>
>> >> >> >> I found the reason - tests expect NPE when valueOf(null) is
>> invoked
>> >> >> but
>> >> >> >> IAE
>> >> >> >> is thrown instead. For example,
>> >> >> >>
>> >> >> >> java.lang.IllegalArgumentException
>> >> >> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> >> >> >> EnumTest.java
>> >> >> >> :22)
>> >> >> >> at
>> >> >> >>
>> >> >>
>> >>
>> org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> >> >> >> (EnumTest.java :113)
>> >> >> >> at
>> >> >>
>> java.lang.reflect.AccessibleObject.invokeV(Acces
Re: Supporting working on a single module?
I guess I can sum it up this way - I see writing modified headers, .so//dll, and .jar into the hdk strikes me as writing headers and libraries into /usr/include or /lib... 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: [tools] I want to implement keytool - have a question
Elford, Chris L wrote: > Geir writes: >>> Maybe it's time to pull tools out? > > I'm not quite sure what you are suggesting. Pulling them out of the > build? Placing them somewhere else in the repository? Sorry. I mean to put together a tools 'subsection' in the project, so it's 'front and center'. IOW, we now have as our svn repo : /classlib /drlvm /jchevm so I was thinking we bring the tools 'stuff' from /classlib and move to /tools geir > > Thanks, > > Chris Elford > Intel Middleware Products Division > > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 07, 2006 5:31 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [tools] I want to implement keytool - have a question > > Maybe it's time to pull tools out? > > Tim Ellison wrote: >> Anton Rusanov wrote: >>> Hello. >>> I looked through Harmony code and I think I can implement the > Keytool for >>> the project using existing classes. I've already played with the > thing and >>> it doesn't seem to be very hard to do. I'm going to create a couple > of >>> files >>> with stubs and gradually replace stubs with implementation using > patches. >> Great. >> >>> And I have a question. What should I do to make the keytool run with > the >>> launcher being developed here? >> Define the class >> >> org.apache.harmony.tools.keytool.Main >> >> which will be packaged into tools.jar. It should have a >> >> public static void main(String args[]) >> >> which will be passed the command-line arguments that were given to the >> keytool launcher. >> >> (Of course, you can develop & test your code by running that main() >> directly from a regular launcher in the IDE too) >> >> Sounds like the incentive I needed to hook in the tools build . >> >> 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] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
Mark Hindess wrote: > On 7 June 2006 at 9:42, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> Oliver Deakin wrote: >>> Just thought Id give a bit of a heads up on HARMONY-561. >>> The patch attached to that JIRA moves the header files under the >>> native-src//include directories into >>> /modules//src/main/native. It also updates the build >>> scripts and >>> makefiles to move the headers into a shared location (/include, as >>> described at [1]) and compile against their new location. >> Right, and I really don't like it, have been saying I don't like >> overwriting the HDK, gave a reason for why I don't like it, and never >> heard a reason why it must be this way. > > It's no different to how we've been deploying java code for the last > several months. Sure it is, if you think of the HDK as a binary snapshot you can build against. > That is, if you build at the top level, you are > effectively creating the java parts of the jre (which is part of the > large hdk). If you then go and build in say modules/luni, you are > building against the jars in the "hdk/jdk/jre/lib/boot" directory and > the new luni.jar will be overwrite the existing one. That's misleading, because there is no 'hdk' now. There's nothing wrong with having a /deploy or /target directory that we build into in parallel w/ the hdk, and no one's told me why that's a bad idea, since *that* is how we've been working for several months now. Remember, the motivation for this change is to modularize the natives, not the hdk. lets not let the tail wag the dog here. > > So if Oliver is breaking anything by these changes, then it is nothing > that wasn't broken before for the java code building process. So I > don't see the harm in proceeding because without this or something like > it, it is impossible to move forward with (long overdue) the native-src > restructuring. I don't think I said he was breaking anything. I said that I felt that any alternatives that I suggested that got us to the same place, yet in what I felt lead to clarity and diversity in use case were ignored. Isn't anyone else bothered by the build process dropping artifacts into and overriding what is an SDK? > > No one has felt a pressing need to solve the problem with respect to the > java code parts of the hdk (jre) being overwritten so I don't see why we > now need to solve that problem first. You are mixing two things up here. No one cares if we overwrite stuff in the build destination - that's a necessity - and that's not the issue. The issue is confusing the hdk, something that we'll distribute as snapshots or versioned releases, w/ the build target. > >> If you want me to put my money where my mouth is and just patch it, >> I'm more than able to do that, but I'd rather reach consensus together >> on how to go forward. > > I'd prefer the consensus approach too. > > Having said that I am interested in how you would patch it. I've not > clearly understood how it should be solved/patched. Ignoring the native > code for a moment, how do you propose to solve the problem with respect > to the hdk/jdk/jre/lib/boot jars? Where should the jars go when we > build at the top level? /target/jdk/jre/lib/boot for example ...and to be honest, I think that it should be in a peer to /classlib, not inside of clsaslib. ... and which the word 'target' up for debate, although I prefer it to 'deploy', because I think of deploy as a tree created when you push the button to do a release or snapshot i.e. /deploy/harmony-0.5-snapshot/ > Currently they go in the hdk - just as they > always have - except we didn't call it that. I think that's a really deceptive argument, as the hdk is more than just a simple directory rename. It's a distributed versioned resource. > Where do you think we > should put the jars created when we build in a module? Where they went before >Should the > launcher be modified to support looking for the jars in all locations > (with the hdk/jdk/jre/lib/boot location as last resort)? Well, I believe we still have to sort out where we think that the hdk lives, given classlib is just one part of Harmony. (I know we've been very focused on the classlib until now, but our goal is JavaSE, not a classlib) But putting that aside, yes, that's sortof what I was imagining although I didn't quite grok the best way... I don't know if it's possible, creating classpaths and library paths that are a combination of the /target stuff in front of the /hdk stuff, so that you can 'override'... So let me try to summarize my objections - my main objection is that while I agree the hdk is a powerful and useful idea, we're mixing up the hdk and the build destination, for reasons that haven't been explained. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTEC
RE: [tools] I want to implement keytool - have a question
Geir writes: >> Maybe it's time to pull tools out? I'm not quite sure what you are suggesting. Pulling them out of the build? Placing them somewhere else in the repository? Thanks, Chris Elford Intel Middleware Products Division -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 5:31 AM To: harmony-dev@incubator.apache.org Subject: Re: [tools] I want to implement keytool - have a question Maybe it's time to pull tools out? Tim Ellison wrote: > Anton Rusanov wrote: >> Hello. >> I looked through Harmony code and I think I can implement the Keytool for >> the project using existing classes. I've already played with the thing and >> it doesn't seem to be very hard to do. I'm going to create a couple of >> files >> with stubs and gradually replace stubs with implementation using patches. > > Great. > >> And I have a question. What should I do to make the keytool run with the >> launcher being developed here? > > Define the class > > org.apache.harmony.tools.keytool.Main > > which will be packaged into tools.jar. It should have a > > public static void main(String args[]) > > which will be passed the command-line arguments that were given to the > keytool launcher. > > (Of course, you can develop & test your code by running that main() > directly from a regular launcher in the IDE too) > > Sounds like the incentive I needed to hook in the tools build . > > 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: Supporting working on a single module?
On 7 June 2006 at 9:42, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Oliver Deakin wrote: > > Just thought Id give a bit of a heads up on HARMONY-561. > > The patch attached to that JIRA moves the header files under the > > native-src//include directories into > > /modules//src/main/native. It also updates the build > > scripts and > > makefiles to move the headers into a shared location (/include, as > > described at [1]) and compile against their new location. > > Right, and I really don't like it, have been saying I don't like > overwriting the HDK, gave a reason for why I don't like it, and never > heard a reason why it must be this way. It's no different to how we've been deploying java code for the last several months. That is, if you build at the top level, you are effectively creating the java parts of the jre (which is part of the large hdk). If you then go and build in say modules/luni, you are building against the jars in the "hdk/jdk/jre/lib/boot" directory and the new luni.jar will be overwrite the existing one. So if Oliver is breaking anything by these changes, then it is nothing that wasn't broken before for the java code building process. So I don't see the harm in proceeding because without this or something like it, it is impossible to move forward with (long overdue) the native-src restructuring. No one has felt a pressing need to solve the problem with respect to the java code parts of the hdk (jre) being overwritten so I don't see why we now need to solve that problem first. > If you want me to put my money where my mouth is and just patch it, > I'm more than able to do that, but I'd rather reach consensus together > on how to go forward. I'd prefer the consensus approach too. Having said that I am interested in how you would patch it. I've not clearly understood how it should be solved/patched. Ignoring the native code for a moment, how do you propose to solve the problem with respect to the hdk/jdk/jre/lib/boot jars? Where should the jars go when we build at the top level? Currently they go in the hdk - just as they always have - except we didn't call it that. Where do you think we should put the jars created when we build in a module? Should the launcher be modified to support looking for the jars in all locations (with the hdk/jdk/jre/lib/boot location as last resort)? 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: Supporting working on a single module?
Oliver Deakin wrote: > Just thought Id give a bit of a heads up on HARMONY-561. > The patch attached to that JIRA moves the header files under the > native-src//include directories into > /modules//src/main/native. It also updates the build > scripts and > makefiles to move the headers into a shared location (/include, as > described at [1]) and compile against their new location. Right, and I really don't like it, have been saying I don't like overwriting the HDK, gave a reason for why I don't like it, and never heard a reason why it must be this way. If you want me to put my money where my mouth is and just patch it, I'm more than able to do that, but I'd rather reach consensus together on how to go forward. > > The next piece of work I intend to look at is getting the windows/linux > makefiles to > build their .lib/.a files directly into the /lib directory (also > described in [1]), See above > and getting each native component to link against the libs at that > location. Once > this is done the deploy directory should look like a complete HDK after > a global > build. ie it will contain everything needed to build each individual > native component > or java module against it. That is a good outcome if it isn't the hdk directory. If it's the HDK directory, consider me against it. > > We should then be able to make the final moves of the classlib native code > into the modules (and start creating some classlib HDK snapshots). Great. geir > > Regards, > Oliver > > > [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html > > - > 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] build -unhook the classlib build and point to the existing in-tree one
Can I get some help from someone w/ the build? First thing, I want to stop using the auto-download classlib and harmony JIRA fetches, and just point the build at the existing classlib that's in the svn tree. IOW, I have w/ /harmony/enhanced/ as my root : drlvm/trunk/ classlib/trunk/ and I want to change the drlvm to use the stuff in classlib/trunk to build. Maybe if I see the fast way to do that, I'll then be able to start having a /deploy directory peer to drlvm and classlib and can go from there. 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] the build.... why?
Salikh Zakirov wrote: > Geir Magnusson Jr wrote: >> What I don't understand is the "motivation" or the "theory" behind how >> and why it was done. I'm hoping that if I grok that, all will fall into >> place for me and with that different perspective, I might find it easier >> to work with. > > The two main requirements behind the design of this build system were > 1. Unify the build system for the class library and VM But we can *easily* do that simply by having a top level script first invoke the DRLVM build, and then the classlibrary (or whatever order is approrpros...) > 2. Do not use Cygwin for the build on Windows That's fine, although at some point, someone will hopefully make that work too. > > (and a number of other reasonable requirements > 3. incremental build > 4. tracking C++ dependencies > 5. keeping platform-specific configuration in a compact and readable form) Ok > >> As I understand it, it's really a "meta build" system, as it's purpose >> seems to be to create the actual ant scripts that execute to do the >> work. Why? > > (less sure about this one) > As far as I understand, the trick with preprocessing XML files allows to keep > platform-specific configuration compactly in one readable file. > And by the way, the XML transformation (what you call "meta build" system) is > only limited to filtering XML fragments based on the detected platform. Hm. I thought it was more than that given the eventual creations of the massive file, build.tmp.xml > >> Also, it doesn't use 'make' for building the C/C++ code. Why? > > Using GNU make leads to requirement to have GNU tools on Windows (contradicts > requirement (2) above) > NMAKE cannot be used since it is not available on the Linux. We seem to do ok w/ classlib though...? > Moreover, from Ant-contrib is not bad in tracking dependencies > and running various kinds of compilers. > > We used GNU Make for some time while preparing DRLVM contribution, > but moved on to Ant-based system later because of requirements (1), (2). Ok, thanks. > > -- > Salikh Zakirov, 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: [tools] I want to implement keytool - have a question
Maybe it's time to pull tools out? Tim Ellison wrote: > Anton Rusanov wrote: >> Hello. >> I looked through Harmony code and I think I can implement the Keytool for >> the project using existing classes. I've already played with the thing and >> it doesn't seem to be very hard to do. I'm going to create a couple of >> files >> with stubs and gradually replace stubs with implementation using patches. > > Great. > >> And I have a question. What should I do to make the keytool run with the >> launcher being developed here? > > Define the class > > org.apache.harmony.tools.keytool.Main > > which will be packaged into tools.jar. It should have a > > public static void main(String args[]) > > which will be passed the command-line arguments that were given to the > keytool launcher. > > (Of course, you can develop & test your code by running that main() > directly from a regular launcher in the IDE too) > > Sounds like the incentive I needed to hook in the tools build . > > 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]
Re: [tools] I want to implement keytool - have a question
Anton Rusanov wrote: > Hello. > I looked through Harmony code and I think I can implement the Keytool for > the project using existing classes. I've already played with the thing and > it doesn't seem to be very hard to do. I'm going to create a couple of > files > with stubs and gradually replace stubs with implementation using patches. Great. > And I have a question. What should I do to make the keytool run with the > launcher being developed here? Define the class org.apache.harmony.tools.keytool.Main which will be packaged into tools.jar. It should have a public static void main(String args[]) which will be passed the command-line arguments that were given to the keytool launcher. (Of course, you can develop & test your code by running that main() directly from a regular launcher in the IDE too) Sounds like the incentive I needed to hook in the tools build . 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] the build.... why?
Geir Magnusson Jr wrote: > What I don't understand is the "motivation" or the "theory" behind how > and why it was done. I'm hoping that if I grok that, all will fall into > place for me and with that different perspective, I might find it easier > to work with. The two main requirements behind the design of this build system were 1. Unify the build system for the class library and VM 2. Do not use Cygwin for the build on Windows (and a number of other reasonable requirements 3. incremental build 4. tracking C++ dependencies 5. keeping platform-specific configuration in a compact and readable form) > As I understand it, it's really a "meta build" system, as it's purpose > seems to be to create the actual ant scripts that execute to do the > work. Why? (less sure about this one) As far as I understand, the trick with preprocessing XML files allows to keep platform-specific configuration compactly in one readable file. And by the way, the XML transformation (what you call "meta build" system) is only limited to filtering XML fragments based on the detected platform. > Also, it doesn't use 'make' for building the C/C++ code. Why? Using GNU make leads to requirement to have GNU tools on Windows (contradicts requirement (2) above) NMAKE cannot be used since it is not available on the Linux. Moreover, from Ant-contrib is not bad in tracking dependencies and running various kinds of compilers. We used GNU Make for some time while preparing DRLVM contribution, but moved on to Ant-based system later because of requirements (1), (2). -- Salikh Zakirov, 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: [tools] I want to implement keytool - have a question
Anton Rusanov wrote: > Hello. > I looked through Harmony code and I think I can implement the Keytool for > the project using existing classes. I've already played with the thing and > it doesn't seem to be very hard to do. I'm going to create a couple of > files > with stubs and gradually replace stubs with implementation using patches. Excellent! > > And I have a question. What should I do to make the keytool run with the > launcher being developed here? See this thread : http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] Tim modified the launcher to support just this kind of endeavour. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools] I want to implement keytool - have a question
Hello. I looked through Harmony code and I think I can implement the Keytool for the project using existing classes. I've already played with the thing and it doesn't seem to be very hard to do. I'm going to create a couple of files with stubs and gradually replace stubs with implementation using patches. And I have a question. What should I do to make the keytool run with the launcher being developed here? Anton Rusanov Intel Middleware Products Division
Re: [classlib] Enum ready to go
javac and java are from the same distrib (javac does not print
detailed version info,
that is why I''m mentioning java version),
so it is javac 1.5.0_b64
so I compile with JDK 1.5.0_b64, run on Harmony and it fails
Thanks,
Mikhail
2006/6/7, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
> 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
>> using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target 1.4
>> set.
>>
>> I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
>> empty, but seems a bit of a drag to work around the compilers.
>>
>> (which version of BEA javac?)
>
> javac -version prints just "1.5.0"
> java -version prints "build 1.5.0-b64"
>
I would bet the tests shall pass if using javac of java-version "build
1.5.0_01" or later :)
And as the tests also fail on RI of "build 1.5.0-b64" (I've just find
one:) ), I guess it is a bug of RI, which was fixed in the later version.
What's more, shall we also suggest that everyone use a latest version of
javac to avoid such problem?
>
>>
>> Regards,
>> Tim
>>
>> Mikhail Loenko wrote:
>> > Are you compiling with "jsr14" as our build does?
>> >
>> > I'm using BEA javac with "jsr14" it compiles to something like this:
>> > for(i=0; i < values.length; i++ )
>> > if( values[i].name().equals(argument) )
>> > return values[i].name().equals(argument)
>> > throw IAE
>> >
>> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> >> Maybe compiler specific.
>> >>
>> >> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> >> delegates to the Enum type:
>> >>
>> >> public static Type valueOf(String name)
>> >> {
>> >> return (Type)Enum.valueOf(
>> >> Proxy.class$java$net$Proxy$Type != null ?
>> >> Proxy.class$java$net$Proxy$Type :
>> >> (
>> >> Proxy.class$java$net$Proxy$Type =
>> >> Proxy._mthclass$("java.net.Proxy$Type")
>> >> ),
>> >> name);
>> >> }
>> >>
>> >>
>> >> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>> >>
>> >> public static Type valueOf(String s)
>> >> {
>> >> Type atype[];
>> >> Type type1;
>> >> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> >> if(s.equals((type1 = atype[i]).name()))
>> >> return type1;
>> >> throw new IllegalArgumentException(s);
>> >> }
>> >>
>> >>
>> >> In the Sun compiler a null name argument gets passed to
>> >> Enum#valueOf(Class, String) where I check and throw NPE.
>> >>
>> >> In the Eclipse compiler the line if(s.equals(...)... will cause a NPE
>> >> iff there are entries in the VALUES array (otherwise it doesn't go
>> into
>> >> the for-loop) and throws an IAE without going into my code.
>> >>
>> >> Maybe I can withdraw the null name test while we settle this?
>> >
>> > We now have 3 tests failing
>> >
>> > Thanks,
>> > Mikhail
>> >
>> >
>> >
>> >>
>> >> Regards,
>> >> Tim
>> >>
>> >>
>> >> Andrew Zhang wrote:
>> >> > Hi, Stepan,
>> >> >
>> >> > The test you metioned is passed in my environment:
>> >> > RI version: 1.5.0_02.
>> >> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >> >
>> >> > Is the problem caused by earlier version javac?
>> >> >
>> >> > I remember that RI of earlier verion throws IAE instead of NPE
>> when the
>> >> > arguement is null.
>> >> >
>> >> > Would you please check "java" version?
>> >> >
>> >> > Thanks.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> I found the reason - tests expect NPE when valueOf(null) is invoked
>> >> but
>> >> >> IAE
>> >> >> is thrown instead. For example,
>> >> >>
>> >> >> java.lang.IllegalArgumentException
>> >> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> >> >> EnumTest.java
>> >> >> :22)
>> >> >> at
>> >> >>
>> >>
>> org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> >> >> (EnumTest.java :113)
>> >> >> at
>> >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>> >> >>
>> >> >> Thanks,
>> >> >> Stepan.
>> >> >>
>> >> >> On 6/7/06, Andrew Zhang wrote:
>> >> >> >
>> >> >> > Hello Stepan and Mikhail,
>> >> >> >
>> >> >> > All tests passed on my machine.
>> >> >> >
>> >> >> > Which test case was failed in your environment, on RI or Harmony?
>> >> >> >
>> >> >> > Thanks!
>> >> >> >
>> >> >> >
>> >> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>> >> >> > >
>> >> >> > > Hi Tim,
>> >> >> > >
>> >> >> > > On 6/7/06, Tim Ellison wrote:
>> >> >> > > >
>> >> >> > > > Heads up that I completed the implementation of j.l.Enum
>> >> today; so
>> >> >> you
>> >> >> > > > can go mad and use enum types in classlib code for real now.
>> >> >> > >
>> >> >> > >
>> >> >> > > Cool!
>> >> >> > >
>> >> >> > > I wrote a bunch of tests but if you could hammer on it and
>> try to
>> >> >> break
>> >> >> > > > it that would be good :-)
>> >> >> > >
>> >> >> > >
>> >> >> > > And did you run it? :-) It fails for me :-(
>
Re: [announce] New Apache Harmony Committer : Nathan Beyer
2006/6/7, Tim Ellison <[EMAIL PROTECTED]>: Geir Magnusson Jr wrote: > > Tim Ellison wrote: >> Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 2:19 AM To: harmony-dev@incubator.apache.org Subject: Re: [announce] New Apache Harmony Committer : Nathan Beyer p.s. IIRC you are a Harmony Authorized Contributor, so your status is an 'A' rather than a 'R', right? >>> Okay. I wasn't quite sure what that meant. What's the test to know the >>> difference? I didn't have any restrictions from the questionnaire, which is >>> why I set it to just regular. >> I'm just guessing, it was Geir's distinction. I thought that if you >> were regular then you are restricted by the ACQ, so don't get access to >> the 'enhanced' area of SVN. I may well be wrong. > > That's right. There's a first for everything :-) Mikhail: you may want to update your status too. OK, now the puzzle seems to be solved :) Thanks, Mikhail 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] - 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] Enum ready to go
Jimmy, Jing Lv wrote:
> Mikhail Loenko wrote:
>> 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>>> The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
>>> using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target
>>> 1.4 set.
>>>
>>> I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
>>> empty, but seems a bit of a drag to work around the compilers.
>>>
>>> (which version of BEA javac?)
>>
>> javac -version prints just "1.5.0"
>> java -version prints "build 1.5.0-b64"
>>
>
> I would bet the tests shall pass if using javac of java-version "build
> 1.5.0_01" or later :)
> And as the tests also fail on RI of "build 1.5.0-b64" (I've just find
> one:) ), I guess it is a bug of RI, which was fixed in the later version.
>
> What's more, shall we also suggest that everyone use a latest version of
> javac to avoid such problem?
Let me ask the compiler folk what they think first [1], I think we can
work with both (modulo the empty enum case in ECJ) if we have to since
at least in one case it is delegated straight back to us.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=145732
Regards,
Tim
>>> Mikhail Loenko wrote:
>>> > Are you compiling with "jsr14" as our build does?
>>> >
>>> > I'm using BEA javac with "jsr14" it compiles to something like this:
>>> > for(i=0; i < values.length; i++ )
>>> > if( values[i].name().equals(argument) )
>>> > return values[i].name().equals(argument)
>>> > throw IAE
>>> >
>>> > 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>>> >> Maybe compiler specific.
>>> >>
>>> >> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>>> >> delegates to the Enum type:
>>> >>
>>> >> public static Type valueOf(String name)
>>> >> {
>>> >> return (Type)Enum.valueOf(
>>> >> Proxy.class$java$net$Proxy$Type != null ?
>>> >> Proxy.class$java$net$Proxy$Type :
>>> >> (
>>> >> Proxy.class$java$net$Proxy$Type =
>>> >> Proxy._mthclass$("java.net.Proxy$Type")
>>> >> ),
>>> >> name);
>>> >> }
>>> >>
>>> >>
>>> >> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>>> >>
>>> >> public static Type valueOf(String s)
>>> >> {
>>> >> Type atype[];
>>> >> Type type1;
>>> >> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>>> >> if(s.equals((type1 = atype[i]).name()))
>>> >> return type1;
>>> >> throw new IllegalArgumentException(s);
>>> >> }
>>> >>
>>> >>
>>> >> In the Sun compiler a null name argument gets passed to
>>> >> Enum#valueOf(Class, String) where I check and throw NPE.
>>> >>
>>> >> In the Eclipse compiler the line if(s.equals(...)... will cause a NPE
>>> >> iff there are entries in the VALUES array (otherwise it doesn't go
>>> into
>>> >> the for-loop) and throws an IAE without going into my code.
>>> >>
>>> >> Maybe I can withdraw the null name test while we settle this?
>>> >
>>> > We now have 3 tests failing
>>> >
>>> > Thanks,
>>> > Mikhail
>>> >
>>> >
>>> >
>>> >>
>>> >> Regards,
>>> >> Tim
>>> >>
>>> >>
>>> >> Andrew Zhang wrote:
>>> >> > Hi, Stepan,
>>> >> >
>>> >> > The test you metioned is passed in my environment:
>>> >> > RI version: 1.5.0_02.
>>> >> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>>> >> >
>>> >> > Is the problem caused by earlier version javac?
>>> >> >
>>> >> > I remember that RI of earlier verion throws IAE instead of NPE
>>> when the
>>> >> > arguement is null.
>>> >> >
>>> >> > Would you please check "java" version?
>>> >> >
>>> >> > Thanks.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>>> >> >>
>>> >> >> I found the reason - tests expect NPE when valueOf(null) is
>>> invoked
>>> >> but
>>> >> >> IAE
>>> >> >> is thrown instead. For example,
>>> >> >>
>>> >> >> java.lang.IllegalArgumentException
>>> >> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>>> >> >> EnumTest.java
>>> >> >> :22)
>>> >> >> at
>>> >> >>
>>> >>
>>> org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>>>
>>> >> >> (EnumTest.java :113)
>>> >> >> at
>>> >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Stepan.
>>> >> >>
>>> >> >> On 6/7/06, Andrew Zhang wrote:
>>> >> >> >
>>> >> >> > Hello Stepan and Mikhail,
>>> >> >> >
>>> >> >> > All tests passed on my machine.
>>> >> >> >
>>> >> >> > Which test case was failed in your environment, on RI or
>>> Harmony?
>>> >> >> >
>>> >> >> > Thanks!
>>> >> >> >
>>> >> >> >
>>> >> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>>> >> >> > >
>>> >> >> > > Hi Tim,
>>> >> >> > >
>>> >> >> > > On 6/7/06, Tim Ellison wrote:
>>> >> >> > > >
>>> >> >> > > > Heads up that I completed the implementation of j.l.Enum
>>> >> today; so
>>> >> >> you
>>> >> >> > > > can go mad and use enum types in classlib code for real now.
>>> >> >> > >
>>> >> >> > >
>>> >> >> > > Cool!
>>> >> >> > >
>>> >> >> > > I wrote a bunch of tests but if you could hammer
Re: [classlib] Enum ready to go
Mikhail Loenko wrote:
2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target 1.4
set.
I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
empty, but seems a bit of a drag to work around the compilers.
(which version of BEA javac?)
javac -version prints just "1.5.0"
java -version prints "build 1.5.0-b64"
I would bet the tests shall pass if using javac of java-version "build
1.5.0_01" or later :)
And as the tests also fail on RI of "build 1.5.0-b64" (I've just find
one:) ), I guess it is a bug of RI, which was fixed in the later version.
What's more, shall we also suggest that everyone use a latest version of
javac to avoid such problem?
Regards,
Tim
Mikhail Loenko wrote:
> Are you compiling with "jsr14" as our build does?
>
> I'm using BEA javac with "jsr14" it compiles to something like this:
> for(i=0; i < values.length; i++ )
> if( values[i].name().equals(argument) )
> return values[i].name().equals(argument)
> throw IAE
>
> 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> Maybe compiler specific.
>>
>> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> delegates to the Enum type:
>>
>> public static Type valueOf(String name)
>> {
>> return (Type)Enum.valueOf(
>> Proxy.class$java$net$Proxy$Type != null ?
>> Proxy.class$java$net$Proxy$Type :
>> (
>> Proxy.class$java$net$Proxy$Type =
>> Proxy._mthclass$("java.net.Proxy$Type")
>> ),
>> name);
>> }
>>
>>
>> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>>
>> public static Type valueOf(String s)
>> {
>> Type atype[];
>> Type type1;
>> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> if(s.equals((type1 = atype[i]).name()))
>> return type1;
>> throw new IllegalArgumentException(s);
>> }
>>
>>
>> In the Sun compiler a null name argument gets passed to
>> Enum#valueOf(Class, String) where I check and throw NPE.
>>
>> In the Eclipse compiler the line if(s.equals(...)... will cause a NPE
>> iff there are entries in the VALUES array (otherwise it doesn't go
into
>> the for-loop) and throws an IAE without going into my code.
>>
>> Maybe I can withdraw the null name test while we settle this?
>
> We now have 3 tests failing
>
> Thanks,
> Mikhail
>
>
>
>>
>> Regards,
>> Tim
>>
>>
>> Andrew Zhang wrote:
>> > Hi, Stepan,
>> >
>> > The test you metioned is passed in my environment:
>> > RI version: 1.5.0_02.
>> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >
>> > Is the problem caused by earlier version javac?
>> >
>> > I remember that RI of earlier verion throws IAE instead of NPE
when the
>> > arguement is null.
>> >
>> > Would you please check "java" version?
>> >
>> > Thanks.
>> >
>> >
>> >
>> >
>> >
>> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I found the reason - tests expect NPE when valueOf(null) is invoked
>> but
>> >> IAE
>> >> is thrown instead. For example,
>> >>
>> >> java.lang.IllegalArgumentException
>> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> >> EnumTest.java
>> >> :22)
>> >> at
>> >>
>>
org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> >> (EnumTest.java :113)
>> >> at
>> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>> >>
>> >> Thanks,
>> >> Stepan.
>> >>
>> >> On 6/7/06, Andrew Zhang wrote:
>> >> >
>> >> > Hello Stepan and Mikhail,
>> >> >
>> >> > All tests passed on my machine.
>> >> >
>> >> > Which test case was failed in your environment, on RI or Harmony?
>> >> >
>> >> > Thanks!
>> >> >
>> >> >
>> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>> >> > >
>> >> > > Hi Tim,
>> >> > >
>> >> > > On 6/7/06, Tim Ellison wrote:
>> >> > > >
>> >> > > > Heads up that I completed the implementation of j.l.Enum
>> today; so
>> >> you
>> >> > > > can go mad and use enum types in classlib code for real now.
>> >> > >
>> >> > >
>> >> > > Cool!
>> >> > >
>> >> > > I wrote a bunch of tests but if you could hammer on it and
try to
>> >> break
>> >> > > > it that would be good :-)
>> >> > >
>> >> > >
>> >> > > And did you run it? :-) It fails for me :-(
>> >> > >
>> >> > > Thanks,
>> >> > > Stepan.
>> >> > >
>> >> > > If you take a look at the implementation [1] of valueOf(Class,
>> >> String)
>> >> > > > it uses reflection to get the enum constant values. I'm not
>> sure
>> >> how
>> >> > > > 'popular' the valueOf() method is, but since the values don't
>> >> change
>> >> > > > they are a good candidate for being cached if it proves to be
>> >> called
>> >> > > > frequently. I'm happy to do that if people think it is
>> worthwhile.
>> >> > > >
>> >> > > > Regards,
>> >> > > > Tim
>> >> > > >
>> >> > > >
>> >> > > > [1]
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/
Re: [drlvm] the build.... why?
Of course I can get it to work, and it works well. Like I said in my first note, it's very impressive. What I don't understand is the "motivation" or the "theory" behind how and why it was done. I'm hoping that if I grok that, all will fall into place for me and with that different perspective, I might find it easier to work with. As I understand it, it's really a "meta build" system, as it's purpose seems to be to create the actual ant scripts that execute to do the work. Why? Also, it doesn't use 'make' for building the C/C++ code. Why? geir Vladimir Gorr wrote: > Hi Geir, > > It's not exactly clear to me how you started the build process for DRLVM > but I hope it has been made in accordance with the README file, namely: > > - set ANT_HOME & JAVA_HOME env variable > - cd build; build.bat update > - build.bat > > Second step is intended for downloading all necessary third-party sources > used by DRLVM > (APR, LOG4CXX, ICU and etc). After this the *pre-copied* directory will be > created where all sources are kept. > No needs to perform this step if downloading is successfully finalized. The > latest step will start the build process > for all downloaded resources including the Harmony classes. All binaries > will be in the *build\win_ia32_icl_debug\deploy\jre* directory. > > Thanks, > Vladimir. > > > On 6/7/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> I have to admit, I don't grok the build for drlvm. >> >> I was trying to figure out how to unhook the building of everything, >> like APR and our own classlib, and I just got lost in layer after layer. >> It certainly is an impressive achievement - the author clearly >> understood how to get the best out of ant, and there are some very >> clever things in there, but for maintainability by a broad group of >> people, I think it's going to be challenging. >> >> I may be just too much of a simpleton, although the generated 21,000 >> line ant script gave me confidence that I wasn't too off base. :) >> >> So... can someone provide some background? >> >> Personally, I'd love to see something like we're using in classlib, w/ >> ant as the scripting environment, using make where appropriate... >> >> 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: [announce] New Apache Harmony Committer : Nathan Beyer
Geir Magnusson Jr wrote: > > Tim Ellison wrote: >> Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 2:19 AM To: harmony-dev@incubator.apache.org Subject: Re: [announce] New Apache Harmony Committer : Nathan Beyer p.s. IIRC you are a Harmony Authorized Contributor, so your status is an 'A' rather than a 'R', right? >>> Okay. I wasn't quite sure what that meant. What's the test to know the >>> difference? I didn't have any restrictions from the questionnaire, which is >>> why I set it to just regular. >> I'm just guessing, it was Geir's distinction. I thought that if you >> were regular then you are restricted by the ACQ, so don't get access to >> the 'enhanced' area of SVN. I may well be wrong. > > That's right. There's a first for everything :-) Mikhail: you may want to update your status 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]
Re: [classlib] Enum ready to go
2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target 1.4 set.
I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
empty, but seems a bit of a drag to work around the compilers.
(which version of BEA javac?)
javac -version prints just "1.5.0"
java -version prints "build 1.5.0-b64"
Regards,
Tim
Mikhail Loenko wrote:
> Are you compiling with "jsr14" as our build does?
>
> I'm using BEA javac with "jsr14" it compiles to something like this:
> for(i=0; i < values.length; i++ )
> if( values[i].name().equals(argument) )
> return values[i].name().equals(argument)
> throw IAE
>
> 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> Maybe compiler specific.
>>
>> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> delegates to the Enum type:
>>
>> public static Type valueOf(String name)
>> {
>> return (Type)Enum.valueOf(
>> Proxy.class$java$net$Proxy$Type != null ?
>> Proxy.class$java$net$Proxy$Type :
>> (
>> Proxy.class$java$net$Proxy$Type =
>> Proxy._mthclass$("java.net.Proxy$Type")
>> ),
>> name);
>> }
>>
>>
>> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>>
>> public static Type valueOf(String s)
>> {
>> Type atype[];
>> Type type1;
>> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> if(s.equals((type1 = atype[i]).name()))
>> return type1;
>> throw new IllegalArgumentException(s);
>> }
>>
>>
>> In the Sun compiler a null name argument gets passed to
>> Enum#valueOf(Class, String) where I check and throw NPE.
>>
>> In the Eclipse compiler the line if(s.equals(...)... will cause a NPE
>> iff there are entries in the VALUES array (otherwise it doesn't go into
>> the for-loop) and throws an IAE without going into my code.
>>
>> Maybe I can withdraw the null name test while we settle this?
>
> We now have 3 tests failing
>
> Thanks,
> Mikhail
>
>
>
>>
>> Regards,
>> Tim
>>
>>
>> Andrew Zhang wrote:
>> > Hi, Stepan,
>> >
>> > The test you metioned is passed in my environment:
>> > RI version: 1.5.0_02.
>> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >
>> > Is the problem caused by earlier version javac?
>> >
>> > I remember that RI of earlier verion throws IAE instead of NPE when the
>> > arguement is null.
>> >
>> > Would you please check "java" version?
>> >
>> > Thanks.
>> >
>> >
>> >
>> >
>> >
>> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I found the reason - tests expect NPE when valueOf(null) is invoked
>> but
>> >> IAE
>> >> is thrown instead. For example,
>> >>
>> >> java.lang.IllegalArgumentException
>> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> >> EnumTest.java
>> >> :22)
>> >> at
>> >>
>> org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> >> (EnumTest.java :113)
>> >> at
>> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>> >>
>> >> Thanks,
>> >> Stepan.
>> >>
>> >> On 6/7/06, Andrew Zhang wrote:
>> >> >
>> >> > Hello Stepan and Mikhail,
>> >> >
>> >> > All tests passed on my machine.
>> >> >
>> >> > Which test case was failed in your environment, on RI or Harmony?
>> >> >
>> >> > Thanks!
>> >> >
>> >> >
>> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>> >> > >
>> >> > > Hi Tim,
>> >> > >
>> >> > > On 6/7/06, Tim Ellison wrote:
>> >> > > >
>> >> > > > Heads up that I completed the implementation of j.l.Enum
>> today; so
>> >> you
>> >> > > > can go mad and use enum types in classlib code for real now.
>> >> > >
>> >> > >
>> >> > > Cool!
>> >> > >
>> >> > > I wrote a bunch of tests but if you could hammer on it and try to
>> >> break
>> >> > > > it that would be good :-)
>> >> > >
>> >> > >
>> >> > > And did you run it? :-) It fails for me :-(
>> >> > >
>> >> > > Thanks,
>> >> > > Stepan.
>> >> > >
>> >> > > If you take a look at the implementation [1] of valueOf(Class,
>> >> String)
>> >> > > > it uses reflection to get the enum constant values. I'm not
>> sure
>> >> how
>> >> > > > 'popular' the valueOf() method is, but since the values don't
>> >> change
>> >> > > > they are a good candidate for being cached if it proves to be
>> >> called
>> >> > > > frequently. I'm happy to do that if people think it is
>> worthwhile.
>> >> > > >
>> >> > > > Regards,
>> >> > > > Tim
>> >> > > >
>> >> > > >
>> >> > > > [1]
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup
>>
>> >>
>> >> > > >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> 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] Acceptance of Harmony-528 : AWT, Java2D and Swing
of course... Tim Ellison wrote: > Geir Magnusson Jr wrote: >> How much time? > > Can I have a day to answer that question accurately ;-) ? > > Regards, > Tim > >> Tim Ellison wrote: >>> I'd like to request more time to look through the contribution. >>> Apologies for the delay but it is a large amount of code. The vote came >>> round a bit quicker than the others -- which is good but unexpected. >>> >>> Regards, >>> Tim >>> >>> Geir Magnusson Jr wrote: I have received the ACQs and the BCC for Harmony-528, so I can assert that the critical provenance paperwork is in order and in SVN. Please vote to accept or reject this codebase 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. Again, I think that getting this into SVN and letting people supply patches against SVN will be productive. Also, there's a lot of excitement around getting this in and a binary snapshot created... 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: [announce] New Apache Harmony Committer : Nathan Beyer
Tim Ellison wrote: > Nathan Beyer wrote: >>> -Original Message- >>> From: Tim Ellison [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, June 06, 2006 2:19 AM >>> To: harmony-dev@incubator.apache.org >>> Subject: Re: [announce] New Apache Harmony Committer : Nathan Beyer >>> >>> p.s. IIRC you are a Harmony Authorized Contributor, so your status is >>> an 'A' rather than a 'R', right? >> Okay. I wasn't quite sure what that meant. What's the test to know the >> difference? I didn't have any restrictions from the questionnaire, which is >> why I set it to just regular. > > I'm just guessing, it was Geir's distinction. I thought that if you > were regular then you are restricted by the ACQ, so don't get access to > the 'enhanced' area of SVN. I may well be wrong. That's right. 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] Enum ready to go
The Sun 1.5.0_06 compiler was driven directly by our build scripts (so
using jsr14) and the Eclipse 3.2RC4 compiler has source 1.5 target 1.4 set.
I could throw an IAE from Enum#valueOf(Class, null) when the Enum is
empty, but seems a bit of a drag to work around the compilers.
(which version of BEA javac?)
Regards,
Tim
Mikhail Loenko wrote:
> Are you compiling with "jsr14" as our build does?
>
> I'm using BEA javac with "jsr14" it compiles to something like this:
> for(i=0; i < values.length; i++ )
> if( values[i].name().equals(argument) )
> return values[i].name().equals(argument)
> throw IAE
>
> 2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
>> Maybe compiler specific.
>>
>> Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
>> delegates to the Enum type:
>>
>> public static Type valueOf(String name)
>> {
>> return (Type)Enum.valueOf(
>> Proxy.class$java$net$Proxy$Type != null ?
>> Proxy.class$java$net$Proxy$Type :
>> (
>> Proxy.class$java$net$Proxy$Type =
>> Proxy._mthclass$("java.net.Proxy$Type")
>> ),
>> name);
>> }
>>
>>
>> and the Eclipse compiler 3.2RC4 looks up the constant itself:
>>
>> public static Type valueOf(String s)
>> {
>> Type atype[];
>> Type type1;
>> for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
>> if(s.equals((type1 = atype[i]).name()))
>> return type1;
>> throw new IllegalArgumentException(s);
>> }
>>
>>
>> In the Sun compiler a null name argument gets passed to
>> Enum#valueOf(Class, String) where I check and throw NPE.
>>
>> In the Eclipse compiler the line if(s.equals(...)... will cause a NPE
>> iff there are entries in the VALUES array (otherwise it doesn't go into
>> the for-loop) and throws an IAE without going into my code.
>>
>> Maybe I can withdraw the null name test while we settle this?
>
> We now have 3 tests failing
>
> Thanks,
> Mikhail
>
>
>
>>
>> Regards,
>> Tim
>>
>>
>> Andrew Zhang wrote:
>> > Hi, Stepan,
>> >
>> > The test you metioned is passed in my environment:
>> > RI version: 1.5.0_02.
>> > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>> >
>> > Is the problem caused by earlier version javac?
>> >
>> > I remember that RI of earlier verion throws IAE instead of NPE when the
>> > arguement is null.
>> >
>> > Would you please check "java" version?
>> >
>> > Thanks.
>> >
>> >
>> >
>> >
>> >
>> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I found the reason - tests expect NPE when valueOf(null) is invoked
>> but
>> >> IAE
>> >> is thrown instead. For example,
>> >>
>> >> java.lang.IllegalArgumentException
>> >> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> >> EnumTest.java
>> >> :22)
>> >> at
>> >>
>> org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> >> (EnumTest.java :113)
>> >> at
>> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>> >>
>> >> Thanks,
>> >> Stepan.
>> >>
>> >> On 6/7/06, Andrew Zhang wrote:
>> >> >
>> >> > Hello Stepan and Mikhail,
>> >> >
>> >> > All tests passed on my machine.
>> >> >
>> >> > Which test case was failed in your environment, on RI or Harmony?
>> >> >
>> >> > Thanks!
>> >> >
>> >> >
>> >> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>> >> > >
>> >> > > Hi Tim,
>> >> > >
>> >> > > On 6/7/06, Tim Ellison wrote:
>> >> > > >
>> >> > > > Heads up that I completed the implementation of j.l.Enum
>> today; so
>> >> you
>> >> > > > can go mad and use enum types in classlib code for real now.
>> >> > >
>> >> > >
>> >> > > Cool!
>> >> > >
>> >> > > I wrote a bunch of tests but if you could hammer on it and try to
>> >> break
>> >> > > > it that would be good :-)
>> >> > >
>> >> > >
>> >> > > And did you run it? :-) It fails for me :-(
>> >> > >
>> >> > > Thanks,
>> >> > > Stepan.
>> >> > >
>> >> > > If you take a look at the implementation [1] of valueOf(Class,
>> >> String)
>> >> > > > it uses reflection to get the enum constant values. I'm not
>> sure
>> >> how
>> >> > > > 'popular' the valueOf() method is, but since the values don't
>> >> change
>> >> > > > they are a good candidate for being cached if it proves to be
>> >> called
>> >> > > > frequently. I'm happy to do that if people think it is
>> worthwhile.
>> >> > > >
>> >> > > > Regards,
>> >> > > > Tim
>> >> > > >
>> >> > > >
>> >> > > > [1]
>> >> > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup
>>
>> >>
>> >> > > >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> 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.
>>
>> ---
Re: [VOTE] Acceptance of Harmony-528 : AWT, Java2D and Swing
Geir Magnusson Jr wrote: > How much time? Can I have a day to answer that question accurately ;-) ? Regards, Tim > Tim Ellison wrote: >> I'd like to request more time to look through the contribution. >> Apologies for the delay but it is a large amount of code. The vote came >> round a bit quicker than the others -- which is good but unexpected. >> >> Regards, >> Tim >> >> Geir Magnusson Jr wrote: >>> I have received the ACQs and the BCC for Harmony-528, so I can assert >>> that the critical provenance paperwork is in order and in SVN. >>> >>> Please vote to accept or reject this codebase 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. >>> >>> Again, I think that getting this into SVN and letting people supply >>> patches against SVN will be productive. Also, there's a lot of >>> excitement around getting this in and a binary snapshot created... >>> >>> 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] > > -- 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] Enum ready to go
Are you compiling with "jsr14" as our build does?
I'm using BEA javac with "jsr14" it compiles to something like this:
for(i=0; i < values.length; i++ )
if( values[i].name().equals(argument) )
return values[i].name().equals(argument)
throw IAE
2006/6/7, Tim Ellison <[EMAIL PROTECTED]>:
Maybe compiler specific.
Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
delegates to the Enum type:
public static Type valueOf(String name)
{
return (Type)Enum.valueOf(
Proxy.class$java$net$Proxy$Type != null ?
Proxy.class$java$net$Proxy$Type :
(
Proxy.class$java$net$Proxy$Type =
Proxy._mthclass$("java.net.Proxy$Type")
),
name);
}
and the Eclipse compiler 3.2RC4 looks up the constant itself:
public static Type valueOf(String s)
{
Type atype[];
Type type1;
for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
if(s.equals((type1 = atype[i]).name()))
return type1;
throw new IllegalArgumentException(s);
}
In the Sun compiler a null name argument gets passed to
Enum#valueOf(Class, String) where I check and throw NPE.
In the Eclipse compiler the line if(s.equals(...)... will cause a NPE
iff there are entries in the VALUES array (otherwise it doesn't go into
the for-loop) and throws an IAE without going into my code.
Maybe I can withdraw the null name test while we settle this?
We now have 3 tests failing
Thanks,
Mikhail
Regards,
Tim
Andrew Zhang wrote:
> Hi, Stepan,
>
> The test you metioned is passed in my environment:
> RI version: 1.5.0_02.
> Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>
> Is the problem caused by earlier version javac?
>
> I remember that RI of earlier verion throws IAE instead of NPE when the
> arguement is null.
>
> Would you please check "java" version?
>
> Thanks.
>
>
>
>
>
> On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>>
>> I found the reason - tests expect NPE when valueOf(null) is invoked but
>> IAE
>> is thrown instead. For example,
>>
>> java.lang.IllegalArgumentException
>> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> EnumTest.java
>> :22)
>> at
>> org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> (EnumTest.java :113)
>> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>>
>> Thanks,
>> Stepan.
>>
>> On 6/7/06, Andrew Zhang wrote:
>> >
>> > Hello Stepan and Mikhail,
>> >
>> > All tests passed on my machine.
>> >
>> > Which test case was failed in your environment, on RI or Harmony?
>> >
>> > Thanks!
>> >
>> >
>> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>> > >
>> > > Hi Tim,
>> > >
>> > > On 6/7/06, Tim Ellison wrote:
>> > > >
>> > > > Heads up that I completed the implementation of j.l.Enum today; so
>> you
>> > > > can go mad and use enum types in classlib code for real now.
>> > >
>> > >
>> > > Cool!
>> > >
>> > > I wrote a bunch of tests but if you could hammer on it and try to
>> break
>> > > > it that would be good :-)
>> > >
>> > >
>> > > And did you run it? :-) It fails for me :-(
>> > >
>> > > Thanks,
>> > > Stepan.
>> > >
>> > > If you take a look at the implementation [1] of valueOf(Class,
>> String)
>> > > > it uses reflection to get the enum constant values. I'm not sure
>> how
>> > > > 'popular' the valueOf() method is, but since the values don't
>> change
>> > > > they are a good candidate for being cached if it proves to be
>> called
>> > > > frequently. I'm happy to do that if people think it is worthwhile.
>> > > >
>> > > > Regards,
>> > > > Tim
>> > > >
>> > > >
>> > > > [1]
>> > > >
>> > > >
>> > >
>> >
>>
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup
>>
>> > > >
>> >
>> >
>> >
>>
>>
>> --
>> 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]
-
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] Enum ready to go
Stepan Mishura wrote: I found the reason - tests expect NPE when valueOf(null) is invoked but IAE is thrown instead. For example, java.lang.IllegalArgumentException at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(EnumTest.java :22) at org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String (EnumTest.java:113) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Thanks, Stepan. Hi: It works well on my workspace, with windows XP sp2, RI (1.5.0_06, the latest version). By the way, it also passes all test on RI 1.5.0_01, and on Linux(kernel 2.4.2, RI 1.5.0_02). Look into code, I doubt perhaps it is compiler who cause the problem. I would try an early version of RI 1.5.0, but currently I can not find one. On 6/7/06, Andrew Zhang wrote: Hello Stepan and Mikhail, All tests passed on my machine. Which test case was failed in your environment, on RI or Harmony? Thanks! On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > Hi Tim, > > On 6/7/06, Tim Ellison wrote: > > > > Heads up that I completed the implementation of j.l.Enum today; so you > > can go mad and use enum types in classlib code for real now. > > > Cool! > > I wrote a bunch of tests but if you could hammer on it and try to break > > it that would be good :-) > > > And did you run it? :-) It fails for me :-( > > Thanks, > Stepan. > > If you take a look at the implementation [1] of valueOf(Class, String) > > it uses reflection to get the enum constant values. I'm not sure how > > 'popular' the valueOf() method is, but since the values don't change > > they are a good candidate for being cached if it proves to be called > > frequently. I'm happy to do that if people think it is worthwhile. > > > > Regards, > > Tim > > > > > > [1] > > > > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup > > -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv 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: [announce] New Apache Harmony Committer : Nathan Beyer
Nathan Beyer wrote: >> -Original Message- >> From: Tim Ellison [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, June 06, 2006 2:19 AM >> To: harmony-dev@incubator.apache.org >> Subject: Re: [announce] New Apache Harmony Committer : Nathan Beyer >> >> p.s. IIRC you are a Harmony Authorized Contributor, so your status is >> an 'A' rather than a 'R', right? > > Okay. I wasn't quite sure what that meant. What's the test to know the > difference? I didn't have any restrictions from the questionnaire, which is > why I set it to just regular. I'm just guessing, it was Geir's distinction. I thought that if you were regular then you are restricted by the ACQ, so don't get access to the 'enhanced' area of SVN. I may well be wrong. 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: [apps] welkin (was Re: [VOTE] Acceptance of Harmony-528: ...)
2006/6/6, Stefano Mazzocchi <[EMAIL PROTECTED]>: BTW, is Harmony's Java2D hardware accelerated or software drawn? As it was written in contribution email Java2D uses GDI+ library on Windows and Xlib on Linux. So it's almost everywhere hardware accelerated on Windows and almost everywhere software drawn on Linux. For now... :) However there are some cases when we use software drawing on Windows. Because not all the Java entities can be converted into GDI+ entities. For example we can not fill shapes with acyclic gradient by GDI+ routines. You can read more about our Java2D implemntation internals in the attached documentation (modules/awt/doc/Java2D.html). -- Alexey A. Petrenko 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] [testing] math2 tests
Stepan Mishura wrote:
> So you suggest to generate thousands of 'dynamic' tests. Right?
Nope, not if there is no new code paths being exercised by them. I was
just pointing out that even where the thousands of tests do test
different code paths you may choose to generate them dynamically rather
than statically.
Regards,
Tim
> On 6/7/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>
>> I doubt it.
>>
>> Even if it were, the logic used to generate the tests can often be built
>> into the runtime tests themselves to exercise the APIs thoroughly
>> without creating thousands of 'static' tests.
>>
>> Regards,
>> Tim
>>
>>
>> Mikhail Loenko wrote:
>> > I've found an issue similar to rmi tests[1]
>> >
>> > There is a method BigDecimal.subtract(BigDecimal,MathContext), its
>> > implementation in math2 consists of 30 lines
>> >
>> > Implementation does not perform any heavy math: I've counted 5
>> > possible execution paths, different branches are calling
>> > BigInteger.multiply,
>> > BigInteger.subtract, new BigDecimal, and couple more methods.
>> >
>> > The test against that method has 2198 generated test cases looking like
>> the
>> > following:
>> >
>> > public void testSubtractMathContext() {
>> >bigDec= new BigDecimal("...");
>> >BigDecimal bigDec2= new BigDecimal("...");
>> >assertEquals(msgNotSame, new BigDecimal("..."),
>> >bigDec.subtract(bigDec2,new MathContext(...)));
>> > }
>> >
>> > Do we need that many tests for this method?
>> >
>> > Thanks,
>> > Mikhail
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[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]
>>
>>
>
>
> --
> 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: [jira] Updated: (HARMONY-548) upgrade to xerces 2.8.0 and xalan 2.7.0
Dmitry M. Kononov wrote: > Hi Tim, > > On 6/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Dmitry M. Kononov wrote: >> > I noticed that the xalan.jar 2.7.0 from the ibiblio site does not >> > contain the BCEL at all. However, a lot of xalan's classes (maybe even >> > all) depend on it. >> > >> > Are you going to add the BCEL to the list of dependencies separately? >> >> Can you explain why we need BCEL? (All the Harmony tests pass fine with >> the new Xalan version as it is) > > I am not sure that we really need it at the moment. We do not need it > unless we want to use the XSLTC compiler which is a part of xalan.jar and > depends on BCEL. > > The reason why I asked is a wish to be sure that I could use the BCEL > version > later than 5.0, that is included into xalan.jar usually. For example, > I would like to > use BCEL 5.1 or later in some tool. But, can I be sure that the next > upgrade of the xalan > will not include the old version of the BCEL again as it was in the > xalan.jar version 2.6? You would have to ask the Xalan team for their plans; however, I would imagine that their inclusion of BCEL is for their own internal implementation and not as a supported API for the xalan.jar. Probably best if you put your dependency on BCEL directly. 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: [classlib] Enum ready to go
Maybe compiler specific.
Looking at Proxy.Type it appears that the Sun compiler 1.5.0_06
delegates to the Enum type:
public static Type valueOf(String name)
{
return (Type)Enum.valueOf(
Proxy.class$java$net$Proxy$Type != null ?
Proxy.class$java$net$Proxy$Type :
(
Proxy.class$java$net$Proxy$Type =
Proxy._mthclass$("java.net.Proxy$Type")
),
name);
}
and the Eclipse compiler 3.2RC4 looks up the constant itself:
public static Type valueOf(String s)
{
Type atype[];
Type type1;
for(int i = (atype = ENUM$VALUES).length; --i >= 0;)
if(s.equals((type1 = atype[i]).name()))
return type1;
throw new IllegalArgumentException(s);
}
In the Sun compiler a null name argument gets passed to
Enum#valueOf(Class, String) where I check and throw NPE.
In the Eclipse compiler the line if(s.equals(...)... will cause a NPE
iff there are entries in the VALUES array (otherwise it doesn't go into
the for-loop) and throws an IAE without going into my code.
Maybe I can withdraw the null name test while we settle this?
Regards,
Tim
Andrew Zhang wrote:
> Hi, Stepan,
>
> The test you metioned is passed in my environment:
> RI version: 1.5.0_02.
> Linux: Read hat Enterprise Linux AS(2.4.21-15.EL)
>
> Is the problem caused by earlier version javac?
>
> I remember that RI of earlier verion throws IAE instead of NPE when the
> arguement is null.
>
> Would you please check "java" version?
>
> Thanks.
>
>
>
>
>
> On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>>
>> I found the reason - tests expect NPE when valueOf(null) is invoked but
>> IAE
>> is thrown instead. For example,
>>
>> java.lang.IllegalArgumentException
>> at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(
>> EnumTest.java
>> :22)
>> at
>> org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String
>> (EnumTest.java :113)
>> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>>
>> Thanks,
>> Stepan.
>>
>> On 6/7/06, Andrew Zhang wrote:
>> >
>> > Hello Stepan and Mikhail,
>> >
>> > All tests passed on my machine.
>> >
>> > Which test case was failed in your environment, on RI or Harmony?
>> >
>> > Thanks!
>> >
>> >
>> > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote:
>> > >
>> > > Hi Tim,
>> > >
>> > > On 6/7/06, Tim Ellison wrote:
>> > > >
>> > > > Heads up that I completed the implementation of j.l.Enum today; so
>> you
>> > > > can go mad and use enum types in classlib code for real now.
>> > >
>> > >
>> > > Cool!
>> > >
>> > > I wrote a bunch of tests but if you could hammer on it and try to
>> break
>> > > > it that would be good :-)
>> > >
>> > >
>> > > And did you run it? :-) It fails for me :-(
>> > >
>> > > Thanks,
>> > > Stepan.
>> > >
>> > > If you take a look at the implementation [1] of valueOf(Class,
>> String)
>> > > > it uses reflection to get the enum constant values. I'm not sure
>> how
>> > > > 'popular' the valueOf() method is, but since the values don't
>> change
>> > > > they are a good candidate for being cached if it proves to be
>> called
>> > > > frequently. I'm happy to do that if people think it is worthwhile.
>> > > >
>> > > > Regards,
>> > > > Tim
>> > > >
>> > > >
>> > > > [1]
>> > > >
>> > > >
>> > >
>> >
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup
>>
>> > > >
>> >
>> >
>> >
>>
>>
>> --
>> 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] Enum ready to go
Hi, Mikhail, Of course I DID... On 6/7/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Hi Andrew Did you update your workspace? Thanks, Mikhail 2006/6/7, Andrew Zhang <[EMAIL PROTECTED]>: > Hi, Stepan, > > The test you metioned is passed in my environment: > RI version: 1.5.0_02. > Linux: Read hat Enterprise Linux AS(2.4.21-15.EL) > > Is the problem caused by earlier version javac? > > I remember that RI of earlier verion throws IAE instead of NPE when the > arguement is null. > > Would you please check "java" version? > > Thanks. > > > > > > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > > I found the reason - tests expect NPE when valueOf(null) is invoked but > > IAE > > is thrown instead. For example, > > > > java.lang.IllegalArgumentException > > at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf( > > EnumTest.java > > :22) > > at > > org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String > > (EnumTest.java :113) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java :205) > > > > Thanks, > > Stepan. > > > > On 6/7/06, Andrew Zhang wrote: > > > > > > Hello Stepan and Mikhail, > > > > > > All tests passed on my machine. > > > > > > Which test case was failed in your environment, on RI or Harmony? > > > > > > Thanks! > > > > > > > > > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote: > > > > > > > > Hi Tim, > > > > > > > > On 6/7/06, Tim Ellison wrote: > > > > > > > > > > Heads up that I completed the implementation of j.l.Enum today; so > > you > > > > > can go mad and use enum types in classlib code for real now. > > > > > > > > > > > > Cool! > > > > > > > > I wrote a bunch of tests but if you could hammer on it and try to > > break > > > > > it that would be good :-) > > > > > > > > > > > > And did you run it? :-) It fails for me :-( > > > > > > > > Thanks, > > > > Stepan. > > > > > > > > If you take a look at the implementation [1] of valueOf(Class, String) > > > > > it uses reflection to get the enum constant values. I'm not sure > > how > > > > > 'popular' the valueOf() method is, but since the values don't change > > > > > they are a good candidate for being cached if it proves to be called > > > > > frequently. I'm happy to do that if people think it is worthwhile. > > > > > > > > > > Regards, > > > > > Tim > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup > > > > > > > > > > > > > > > > > > > > -- > > 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 > > - 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
Re: [classlib] Enum ready to go
Hi Andrew Did you update your workspace? Thanks, Mikhail 2006/6/7, Andrew Zhang <[EMAIL PROTECTED]>: Hi, Stepan, The test you metioned is passed in my environment: RI version: 1.5.0_02. Linux: Read hat Enterprise Linux AS(2.4.21-15.EL) Is the problem caused by earlier version javac? I remember that RI of earlier verion throws IAE instead of NPE when the arguement is null. Would you please check "java" version? Thanks. On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > I found the reason - tests expect NPE when valueOf(null) is invoked but > IAE > is thrown instead. For example, > > java.lang.IllegalArgumentException > at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf( > EnumTest.java > :22) > at > org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String > (EnumTest.java :113) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) > > Thanks, > Stepan. > > On 6/7/06, Andrew Zhang wrote: > > > > Hello Stepan and Mikhail, > > > > All tests passed on my machine. > > > > Which test case was failed in your environment, on RI or Harmony? > > > > Thanks! > > > > > > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote: > > > > > > Hi Tim, > > > > > > On 6/7/06, Tim Ellison wrote: > > > > > > > > Heads up that I completed the implementation of j.l.Enum today; so > you > > > > can go mad and use enum types in classlib code for real now. > > > > > > > > > Cool! > > > > > > I wrote a bunch of tests but if you could hammer on it and try to > break > > > > it that would be good :-) > > > > > > > > > And did you run it? :-) It fails for me :-( > > > > > > Thanks, > > > Stepan. > > > > > > If you take a look at the implementation [1] of valueOf(Class, String) > > > > it uses reflection to get the enum constant values. I'm not sure > how > > > > 'popular' the valueOf() method is, but since the values don't change > > > > they are a good candidate for being cached if it proves to be called > > > > frequently. I'm happy to do that if people think it is worthwhile. > > > > > > > > Regards, > > > > Tim > > > > > > > > > > > > [1] > > > > > > > > > > > > > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup > > > > > > > > > > > > > -- > 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 - 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] Updated: (HARMONY-548) upgrade to xerces 2.8.0 and xalan 2.7.0
Hi Tim, On 6/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Dmitry M. Kononov wrote: > I noticed that the xalan.jar 2.7.0 from the ibiblio site does not > contain the BCEL at all. However, a lot of xalan's classes (maybe even > all) depend on it. > > Are you going to add the BCEL to the list of dependencies separately? Can you explain why we need BCEL? (All the Harmony tests pass fine with the new Xalan version as it is) I am not sure that we really need it at the moment. We do not need it unless we want to use the XSLTC compiler which is a part of xalan.jar and depends on BCEL. The reason why I asked is a wish to be sure that I could use the BCEL version later than 5.0, that is included into xalan.jar usually. For example, I would like to use BCEL 5.1 or later in some tool. But, can I be sure that the next upgrade of the xalan will not include the old version of the BCEL again as it was in the xalan.jar version 2.6? Thanks. -- Dmitry M. Kononov Intel Managed Runtime 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] Enum ready to go
Hi, Stepan, The test you metioned is passed in my environment: RI version: 1.5.0_02. Linux: Read hat Enterprise Linux AS(2.4.21-15.EL) Is the problem caused by earlier version javac? I remember that RI of earlier verion throws IAE instead of NPE when the arguement is null. Would you please check "java" version? Thanks. On 6/7/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: I found the reason - tests expect NPE when valueOf(null) is invoked but IAE is thrown instead. For example, java.lang.IllegalArgumentException at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf( EnumTest.java :22) at org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String (EnumTest.java :113) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Thanks, Stepan. On 6/7/06, Andrew Zhang wrote: > > Hello Stepan and Mikhail, > > All tests passed on my machine. > > Which test case was failed in your environment, on RI or Harmony? > > Thanks! > > > On 6/7/06, Stepan Mishura <[EMAIL PROTECTED] > wrote: > > > > Hi Tim, > > > > On 6/7/06, Tim Ellison wrote: > > > > > > Heads up that I completed the implementation of j.l.Enum today; so you > > > can go mad and use enum types in classlib code for real now. > > > > > > Cool! > > > > I wrote a bunch of tests but if you could hammer on it and try to break > > > it that would be good :-) > > > > > > And did you run it? :-) It fails for me :-( > > > > Thanks, > > Stepan. > > > > If you take a look at the implementation [1] of valueOf(Class, String) > > > it uses reflection to get the enum constant values. I'm not sure how > > > 'popular' the valueOf() method is, but since the values don't change > > > they are a good candidate for being cached if it proves to be called > > > frequently. I'm happy to do that if people think it is worthwhile. > > > > > > Regards, > > > Tim > > > > > > > > > [1] > > > > > > > > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166&view=markup > > > > > > -- 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
Re: [apps] welkin (was Re: [VOTE] Acceptance of Harmony-528: ...)
On 6/6/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: That's interesting I suspect that BasicHTML and LineListener are dependencies of JApplet because I don't use sound nor HTML rendering in there... but I do extend JApplet. Yes, unfortunately JApplet is not there yet :-( Some assumptions regarding BasicHTML and sound (I can't promise I'm 100% correct): All Swing components support HTML-formatted text (not done in Harmony yet). BasicHTML is the entry point for that. I suppose that RI implementation performs check BasicHTML.isHTMLString() for all text lines of swing components. Therefore BasicHTML is triggered even application has no HTML formatting. So, we can forget about this class for now - Harmony doesn't need it for the time being and should perfectly work for plain text. About sound... Just an assumption that it was requested from L&F for some component (L&F should provide audio action maps). It is also not currently implemented for Harmony and should not prevent applications from being run sucessfully. Hmmm... BTW, is Harmony's Java2D hardware accelerated or software drawn? Our 2D implementation is based on GDI/GDI+ technologies. Therefore it is as accelerated as those technologies are :-). Regards, -- Anton Avtamonov, 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]
