Re: classlib test suite status emails?
On 4/11/06, Mark Hindess wrote: I've submitted a JIRA containing a fix that is something close to what Stepan suggested. Having module test targets append the name of the module to a build/test_report/test.errors (or test.failures) and the top level target fails if those files exist at the end of the run. Hi Mark, HARMONY-331 was commited to the trunk so is there any chance to have classlib test suite status emails sent to the commits list? Thanks, Stepan. The diff to make this change would be so much easier if we'd refactor the build files - perhaps as I suggested in HARMONY-293. I'm going to update this JIRA to fix it with respect to all the recent moves and test additions but I'd be interested in peoples views on this in the meantime. I think refactoring will make life much easier. -Mark. On 4/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: Yes. I was using the failureproperty mechanism. Trying to get this property propogated back to the top level ant file was what I was having trouble with. I had the same problem. I wanted the whole thing to halt on any failure, and it didn't work... the top level ant script didn't pay attention... Using a file as you suggest might help. I'll give that a try shortly... Incidentally, I'm seeing 12 failures and 3 errors on r393111. (And there are typos - mathc should be match - in the failure messages for java.security.cert testMatch and testClone.) Regards, Mark. On 4/11/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 4/11/06, Mark Hindess wrote: Stepan, I have another build running (but without notifications going to the list) that runs: 1) build (with reference jdk) 2) build with what we created with 1) 3) test 4) create classlists and compare with class load data for applications (tomcat, geronimo, continuum, etc.) 5) generate JAPI results I'd like to fail this build at step 3, but I can't see an easy way to get 'ant -f make/build.xml test' to run all tests and then fail if any of the module test sub-targets had test failures. I could parse the output I suppose, but I'd rather get ant to propagate the junit tasks failure property back up to the top level. I've tried a couple of things and none seem to work. Any suggestions welcome. Mark, did you try failureproperty parameter for junit task? We may add it to ant sub-targets to raise a flag, for example, create file TESTS.FAILED in the root, when tests for some module fail. And in the end of tests suite run check whether this file exists on not. Thanks, Stepan. Regards, Mark. On 4/11/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi, I've checked out at morning last updates, built the code base and run the tests …and there are 24 tests failures! There are 9 tests failures in org.apache.harmony.tests.java.nio.channels.DatagramChannelTest – I saw these failures before from time to time. It seems that tests depend on some race conditions because they may pass if I rerun them. Paulex, are these tests passing for you? And there are new 15 test failures. So now if I'll make a code update or a bug fix how I can be 100% sure that I don't do any regression? Currently if a commit breaks the Harmony classlib build a notification with subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 will be send to harmony-commits mailing list. Is it possible to have the same for tests? I mean that after completing automatic build the existing classlib tests suite should be run. If there are failing tests then a report notification with corresponding subject will be send. Thanks, Stepan Mishura Intel Middleware Products Division -- Mark Hindess [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] Thanks, Stepan Mishura Intel Middleware Products Division -- Mark Hindess [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 :
Re: matching reference implementation exception behaviour
On 4/11/06, Mark Hindess wrote: Based on the goal of being least confusing to users, I'm in favour of matching the behaviour rather than the spec when there is any doubt - users will expect something that runs on reference jre to run on harmony and fail in the same way(s). Based on the same goal, I also think matching 5.0 behaviour is the correct thing to do. If Harmony is going to be a 5.0 implementation our users will naturally expect things to behave the same way as a 5.0 reference implementation. JIRA issues should have a clear resolution/category to record these decisions - and any discussion on the mailing list should be summarised in the JIRA so that we can refer people to the decision. And so that we can revisit them when, as Geir says, we have achieved world domination. Incidentally, it would be good to have some input on HARMONY-266 and HARMONY-315. (I think Stepan and I are the only ones discussing them and we have opposite views. ;-) See: Mark, as far as there are no other opinions I'd suggest to fix HARMONY-315 in case of null provider and leave this JIRA issue open for a while. What do you think? Thanks, Stepan. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] and: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Regards, Mark. On 4/11/06, Mikhail Loenko [EMAIL PROTECTED] wrote: It's not too late to think about it once again and probably revisit the decision. As I understand goal #1 is to meet needs of as many potential users as we can and decision to be spec incompatible in favor of new hot RI version might be not the best one. Thanks, Mikhail 2006/4/11, Geir Magnusson Jr [EMAIL PROTECTED]: I think that people will steadily move up in versions, and maybe most importantly, we *are* trying to build Java SE 5, not J2SE 1.4... geir Mikhail Loenko wrote: BTW, when we were deciding that we follow RI rather then the spec, we cared about breaking existing implementations. But if RI changed its behavior from being compatible to the spec in 1.4 to being incompatible in 1.5 then do we believe that existing applications more likely stick to the latest (1.5) version? Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? Example JIRA-266 and Re: [jira] Created: (HARMONY-266) java.security.Signature.getInstance(String,Provider) should match 5.0 reference implementations behaviour mail thread. Thanks, Mikhail 2006/4/11, Geir Magnusson Jr [EMAIL PROTECTED]: Paulex Yang wrote: Mark You just point out a serious issue ;-) . The RI is just a concept, in fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and on different platforms(win32, linux32, still even more in future)...In fact sometimes they have different behavior themselves, it is very reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different exceptions thrown(more reasonable IAE instead of NPE, for example), or more seriously, different results returned... Samples are available upon request:). Actually, there only is one RI for any given spec, and in this case, I guess we judge it to be the latest version of a spec that comes from Sun? (The question isn't if it comes from Sun - as the spec lead, they supply the RI - but rather what version...) geir -- Mark Hindess [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] Thanks, Stepan Mishura Intel Middleware Products Division
Re: matching reference implementation exception behaviour
On 4/13/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 4/11/06, Mark Hindess wrote: Based on the goal of being least confusing to users, I'm in favour of matching the behaviour rather than the spec when there is any doubt - users will expect something that runs on reference jre to run on harmony and fail in the same way(s). Based on the same goal, I also think matching 5.0 behaviour is the correct thing to do. If Harmony is going to be a 5.0 implementation our users will naturally expect things to behave the same way as a 5.0 reference implementation. JIRA issues should have a clear resolution/category to record these decisions - and any discussion on the mailing list should be summarised in the JIRA so that we can refer people to the decision. And so that we can revisit them when, as Geir says, we have achieved world domination. Incidentally, it would be good to have some input on HARMONY-266 and HARMONY-315. (I think Stepan and I are the only ones discussing them and we have opposite views. ;-) See: Mark, as far as there are no other opinions I'd suggest to fix HARMONY-315 in case of null provider and leave this JIRA issue open for a while. What do you think? Sounds like a good plan. Thanks Stepan. Hopefully others will step up with opinions about the other two cases. Regards, Mark. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] and: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Regards, Mark. On 4/11/06, Mikhail Loenko [EMAIL PROTECTED] wrote: It's not too late to think about it once again and probably revisit the decision. As I understand goal #1 is to meet needs of as many potential users as we can and decision to be spec incompatible in favor of new hot RI version might be not the best one. Thanks, Mikhail 2006/4/11, Geir Magnusson Jr [EMAIL PROTECTED]: I think that people will steadily move up in versions, and maybe most importantly, we *are* trying to build Java SE 5, not J2SE 1.4... geir Mikhail Loenko wrote: BTW, when we were deciding that we follow RI rather then the spec, we cared about breaking existing implementations. But if RI changed its behavior from being compatible to the spec in 1.4 to being incompatible in 1.5 then do we believe that existing applications more likely stick to the latest (1.5) version? Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5? Example JIRA-266 and Re: [jira] Created: (HARMONY-266) java.security.Signature.getInstance(String,Provider) should match 5.0 reference implementations behaviour mail thread. Thanks, Mikhail 2006/4/11, Geir Magnusson Jr [EMAIL PROTECTED]: Paulex Yang wrote: Mark You just point out a serious issue ;-) . The RI is just a concept, in fact we have many RIs, Sun's JDK, BEA's JDK, even different versions, Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and on different platforms(win32, linux32, still even more in future)...In fact sometimes they have different behavior themselves, it is very reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different exceptions thrown(more reasonable IAE instead of NPE, for example), or more seriously, different results returned... Samples are available upon request:). Actually, there only is one RI for any given spec, and in this case, I guess we judge it to be the latest version of a spec that comes from Sun? (The question isn't if it comes from Sun - as the spec lead, they supply the RI - but rather what version...) geir -- Mark Hindess [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] Thanks, Stepan Mishura Intel Middleware Products Division -- Mark Hindess [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: DONE : Use jsr14 target for compiles
FYI. I'm updating security related modules to be 1.5 compatible. I'll need to make some changes in luni module to make it buildable, for example, if no objections, I'm planning to commit Enum class. Thanks, Mikhail 2006/4/13, LvJimmy，Jing [EMAIL PROTECTED]: The best news! Let's cheer for it :) 2006/4/13, George Harley [EMAIL PROTECTED]: Builds OK and tests work on Debian Linux too (thanks Mark). Best regards, George George Harley wrote: Hi, Changes applied in SVN revision 393521. Everything built OK and all tests passed for me on Windows XP prior to commit. Please holler if this change messes things up for you or if you spot an error in my changes. Like I have to ask ... :-) Best regards, George - 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: DONE : Use jsr14 target for compiles
Great! pls. go ahead, Mikhail. I also hold some classes to be converted to *real* Enum:). Mikhail Loenko wrote: FYI. I'm updating security related modules to be 1.5 compatible. I'll need to make some changes in luni module to make it buildable, for example, if no objections, I'm planning to commit Enum class. Thanks, Mikhail 2006/4/13, LvJimmy，Jing [EMAIL PROTECTED]: The best news! Let's cheer for it :) 2006/4/13, George Harley [EMAIL PROTECTED]: Builds OK and tests work on Debian Linux too (thanks Mark). Best regards, George George Harley wrote: Hi, Changes applied in SVN revision 393521. Everything built OK and all tests passed for me on Windows XP prior to commit. Please holler if this change messes things up for you or if you spot an error in my changes. Like I have to ask ... :-) Best regards, George - 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] -- Paulex Yang 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: DONE : Use jsr14 target for compiles
Finally, Java 5 new features are coming! I can't wait to update some mock Enum classes to REAL Enum classes ! On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: FYI. I'm updating security related modules to be 1.5 compatible. I'll need to make some changes in luni module to make it buildable, for example, if no objections, I'm planning to commit Enum class. Thanks, Mikhail 2006/4/13, LvJimmy，Jing [EMAIL PROTECTED]: The best news! Let's cheer for it :) 2006/4/13, George Harley [EMAIL PROTECTED]: Builds OK and tests work on Debian Linux too (thanks Mark). Best regards, George George Harley wrote: Hi, Changes applied in SVN revision 393521. Everything built OK and all tests passed for me on Windows XP prior to commit. Please holler if this change messes things up for you or if you spot an error in my changes. Like I have to ask ... :-) Best regards, George - 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] -- Andrew Zhang China Software Development Lab, IBM
Re: svn commit: r393521 - in /incubator/harmony/enhanced/classlib/trunk: make/ modules/applet/make/ modules/applet/make/common/ modules/archive/make/ modules/archive/make/common/ modules/auth/make/ mo
1) As we discussed yesterday, I have submitted a jira to add a global property. 2) Yes, but there are several scripts that can kick things off. At the top-level with make/build.xml and make/build-test.xml. But also within each module directory with make/build.xml. So 2) is not trivial. George's change modifies all of these. My patch modifies all of these so that a top-level property is defined once (and can be overriden on the ant command line). Regards, Mark. On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: idle curiosity... 1) why not make both 'source' and 'target' settable by a property, and 2) educate me on ant - why couldn't this have been set in a property in the script that kicked things off and have the value propagate down? [EMAIL PROTECTED] wrote: Author: gharley Date: Wed Apr 12 10:03:36 2006 New Revision: 393521 URL: http://svn.apache.org/viewcvs?rev=393521view=rev Log: Temporary move to compile with modern compiler using the jsr14 target until 5.0 VM support becomes available. [snip] -- Mark Hindess [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: svn commit: r393521 - in /incubator/harmony/enhanced/classlib/trunk: make/ modules/applet/make/ modules/applet/make/common/ modules/archive/make/ modules/archive/make/common/ modules/auth/make/ mo
Mark Hindess wrote: 1) As we discussed yesterday, I have submitted a jira to add a global property. 2) Yes, but there are several scripts that can kick things off. At the top-level with make/build.xml and make/build-test.xml. But also within each module directory with make/build.xml. How about a user property file for ant? So 2) is not trivial. George's change modifies all of these. My patch modifies all of these so that a top-level property is defined once (and can be overriden on the ant command line). Regards, Mark. On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: idle curiosity... 1) why not make both 'source' and 'target' settable by a property, and 2) educate me on ant - why couldn't this have been set in a property in the script that kicked things off and have the value propagate down? [EMAIL PROTECTED] wrote: Author: gharley Date: Wed Apr 12 10:03:36 2006 New Revision: 393521 URL: http://svn.apache.org/viewcvs?rev=393521view=rev Log: Temporary move to compile with modern compiler using the jsr14 target until 5.0 VM support becomes available. [snip] -- Mark Hindess [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: Long,long testcase name...
Yes, when they *break*. And how do you find the failed test? you look at the name and the stacktrace. If I told you it was test12343532() you'd find it just as quickly as if I told you it was test_foo_bar_woogie_java_net_thing_exception_wuggawugga_parameter_string_int_boolean_jata_util_fwoppy() because you'd just search for that 'token' in the file. Actually, you probably would get the stacktrace and find it from there, in which case the relevant information is the line number in the file :) Usually you will also have a line number in stacktrace :) So finding the place of failure is not a problem at all... -- Alexey A. Petrenko Intel Middleware Products Division
Re: Long,long testcase name...
Alexey Petrenko wrote: Yes, when they *break*. And how do you find the failed test? you look at the name and the stacktrace. If I told you it was test12343532() you'd find it just as quickly as if I told you it was test_foo_bar_woogie_java_net_thing_exception_wuggawugga_parameter_string_int_boolean_jata_util_fwoppy() because you'd just search for that 'token' in the file. Actually, you probably would get the stacktrace and find it from there, in which case the relevant information is the line number in the file :) Usually you will also have a line number in stacktrace :) So finding the place of failure is not a problem at all... Isn't that what I just said? :) 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: svn commit: r393521 - in /incubator/harmony/enhanced/classlib/trunk: make/ modules/applet/make/ modules/applet/make/common/ modules/archive/make/ modules/archive/make/common/ modules/auth/make/ mo
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: How about a user property file for ant? I've thought about this before. But I've never had a reason to use one. For one off testing I'll just use something like ant -Dbuild.compiler=blah but I've never had a reason to permanently override the settings in the default ant files. I'm sure the time will come but I couldn't see much point in adding one until I had a pressing reason. Regards, Mark. -- Mark Hindess [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: DONE : Use jsr14 target for compiles
I had to touch more util files then I originally expected. Finally, when testing finishs I'll commit the changes. Thanks, Mikhail 2006/4/13, Andrew Zhang [EMAIL PROTECTED]: Finally, Java 5 new features are coming! I can't wait to update some mock Enum classes to REAL Enum classes ! On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: FYI. I'm updating security related modules to be 1.5 compatible. I'll need to make some changes in luni module to make it buildable, for example, if no objections, I'm planning to commit Enum class. Thanks, Mikhail 2006/4/13, LvJimmy，Jing [EMAIL PROTECTED]: The best news! Let's cheer for it :) 2006/4/13, George Harley [EMAIL PROTECTED]: Builds OK and tests work on Debian Linux too (thanks Mark). Best regards, George George Harley wrote: Hi, Changes applied in SVN revision 393521. Everything built OK and all tests passed for me on Windows XP prior to commit. Please holler if this change messes things up for you or if you spot an error in my changes. Like I have to ask ... :-) Best regards, George - 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] -- 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]
Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
If I do a clean checkout and run: ant -f make/depends.xml download ant -f make/build.xml ant -f make/build-test.xml compile-support cd modules/crypto ant -f make/build.xml test I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0 compiler and get the same error: An exception has occurred in the compiler (1.5.0_06). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. I assume since everyone else is quietly working on adding 5.0 code that I am the only one with this problem? I'm about to try the same test under windows, but thought I'd mention this hear first. Regards, Mark. -- Mark Hindess [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] unmodified generic GNU Classpath JVM can now run Classlib hello world
On 4/12/06, Mark Hindess [EMAIL PROTECTED] wrote: On 4/12/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 4/12/06, Mark Hindess [EMAIL PROTECTED] wrote: 1) Copy the luni-kernel and security-kernel stubs and add implementation rather than doing it in place. The stubs are just for compilation we shouldn't add anything VM (or VM adapter) specific to them. hmm not sure what you are suggesting. The stubs allow the build to finish properly but the resultant binary won't run on any JVM because the stubs are hollow. Exactly! I'm saying we should leave them like that. I agree with you. This is good. Have you thought about copying IBM VME makefiles and modifying them for the purpose? I am assuming these makefiles are Apache licensed. We should copy the hollow stubs to a classpathadapter project tree and modify those rather than modifying the copies in the classlib project. Aside: Since classlib is just compiling against these stub, it doesn't really matter if we modify them to add classpath adapter specific implementation. But I think it might be confusing to others coming to implement these kernel classes for a different VM. So we should keep them hollow and not make the classpath adapter special. Then when we want to use the adapter, we overwrite the hollow stubs in the deploy directory. As I said: I think we should be looking to create something, that when combined with JCHEVM, can be dropped in to the deploy tree in the same way that the current IBM VME is dropped in. HTH, Mark. -- Mark Hindess [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] -- 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: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
Hi Mark, Ive just found the same thing while building the crypto tests in windows using J9 50. All tests up to there are ok. The output I get is similar to yours: compile.tests: [echo] Compiling CRYPTO tests from C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java [javac] Compiling 31 source files to C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test [javac] An exception has occurred in the compiler (1.5.0). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. Ill take a look and see if I can find which class it's compiling at the time. Regards, Oliver Mark Hindess wrote: If I do a clean checkout and run: ant -f make/depends.xml download ant -f make/build.xml ant -f make/build-test.xml compile-support cd modules/crypto ant -f make/build.xml test I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0 compiler and get the same error: An exception has occurred in the compiler (1.5.0_06). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. I assume since everyone else is quietly working on adding 5.0 code that I am the only one with this problem? I'm about to try the same test under windows, but thought I'd mention this hear first. Regards, Mark. -- Mark Hindess [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] -- 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: [classlib] unmodified generic GNU Classpath JVM can now run Classlib hello world
No. The IBM VME is not Apache licensed. To quote the download site: The IBM Development Package for Apache Harmony is complementary to, but not part of, the Apache Harmony Project. Read the license. Regards, -Mark. On 4/13/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 4/12/06, Mark Hindess [EMAIL PROTECTED] wrote: On 4/12/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 4/12/06, Mark Hindess [EMAIL PROTECTED] wrote: 1) Copy the luni-kernel and security-kernel stubs and add implementation rather than doing it in place. The stubs are just for compilation we shouldn't add anything VM (or VM adapter) specific to them. hmm not sure what you are suggesting. The stubs allow the build to finish properly but the resultant binary won't run on any JVM because the stubs are hollow. Exactly! I'm saying we should leave them like that. I agree with you. This is good. Have you thought about copying IBM VME makefiles and modifying them for the purpose? I am assuming these makefiles are Apache licensed. We should copy the hollow stubs to a classpathadapter project tree and modify those rather than modifying the copies in the classlib project. Aside: Since classlib is just compiling against these stub, it doesn't really matter if we modify them to add classpath adapter specific implementation. But I think it might be confusing to others coming to implement these kernel classes for a different VM. So we should keep them hollow and not make the classpath adapter special. Then when we want to use the adapter, we overwrite the hollow stubs in the deploy directory. As I said: I think we should be looking to create something, that when combined with JCHEVM, can be dropped in to the deploy tree in the same way that the current IBM VME is dropped in. HTH, Mark. -- Mark Hindess [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] -- 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] -- Mark Hindess [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: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
Excluding these two tests: javax/crypto/SecretKeyFactoryTest1.java javax/crypto/SecretKeyFactoryTest2.java then the compilation works. -Mark. On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote: Hi Mark, Ive just found the same thing while building the crypto tests in windows using J9 50. All tests up to there are ok. The output I get is similar to yours: compile.tests: [echo] Compiling CRYPTO tests from C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java [javac] Compiling 31 source files to C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test [javac] An exception has occurred in the compiler (1.5.0). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. Ill take a look and see if I can find which class it's compiling at the time. Regards, Oliver Mark Hindess wrote: If I do a clean checkout and run: ant -f make/depends.xml download ant -f make/build.xml ant -f make/build-test.xml compile-support cd modules/crypto ant -f make/build.xml test I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0 compiler and get the same error: An exception has occurred in the compiler (1.5.0_06). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. I assume since everyone else is quietly working on adding 5.0 code that I am the only one with this problem? I'm about to try the same test under windows, but thought I'd mention this hear first. Regards, Mark. -- Mark Hindess [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] -- 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] -- Mark Hindess [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: svn commit: r393797 [1/3] - in /incubator/harmony/enhanced/classlib/trunk/modules: auth/src/main/java/common/javax/security/sasl/ luni-kernel/src/main/java/java/lang/ luni/src/main/java/java/lang/
Yes, sure. I've got your message after commit. Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: Please can we fix/understand the compilation jsr14 problems before committing more 5.0 code? Regards, Mark. -- Mark Hindess [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: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
We may compile the tests old way... Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: Excluding these two tests: javax/crypto/SecretKeyFactoryTest1.java javax/crypto/SecretKeyFactoryTest2.java then the compilation works. -Mark. On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote: Hi Mark, Ive just found the same thing while building the crypto tests in windows using J9 50. All tests up to there are ok. The output I get is similar to yours: compile.tests: [echo] Compiling CRYPTO tests from C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java [javac] Compiling 31 source files to C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test [javac] An exception has occurred in the compiler (1.5.0). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. Ill take a look and see if I can find which class it's compiling at the time. Regards, Oliver Mark Hindess wrote: If I do a clean checkout and run: ant -f make/depends.xml download ant -f make/build.xml ant -f make/build-test.xml compile-support cd modules/crypto ant -f make/build.xml test I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0 compiler and get the same error: An exception has occurred in the compiler (1.5.0_06). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. I assume since everyone else is quietly working on adding 5.0 code that I am the only one with this problem? I'm about to try the same test under windows, but thought I'd mention this hear first. Regards, Mark. -- Mark Hindess [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] -- 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] -- Mark Hindess [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: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
I think that would be a workaround once we understand the cause. geir Mikhail Loenko wrote: We may compile the tests old way... Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: Excluding these two tests: javax/crypto/SecretKeyFactoryTest1.java javax/crypto/SecretKeyFactoryTest2.java then the compilation works. -Mark. On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote: Hi Mark, Ive just found the same thing while building the crypto tests in windows using J9 50. All tests up to there are ok. The output I get is similar to yours: compile.tests: [echo] Compiling CRYPTO tests from C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java [javac] Compiling 31 source files to C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test [javac] An exception has occurred in the compiler (1.5.0). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. Ill take a look and see if I can find which class it's compiling at the time. Regards, Oliver Mark Hindess wrote: If I do a clean checkout and run: ant -f make/depends.xml download ant -f make/build.xml ant -f make/build-test.xml compile-support cd modules/crypto ant -f make/build.xml test I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0 compiler and get the same error: An exception has occurred in the compiler (1.5.0_06). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. I assume since everyone else is quietly working on adding 5.0 code that I am the only one with this problem? I'm about to try the same test under windows, but thought I'd mention this hear first. Regards, Mark. -- Mark Hindess [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] -- 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] -- Mark Hindess [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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
This fixes the *1.java case:
@@ -391,9 +391,13 @@
}
}
try {
-skF[i].getKeySpec(secKeySpec,
-(defaultAlgorithm.equals(defaultAlgorithm2)
-? DESedeKeySpec.class : DESKeySpec.class));
+Class c;
+if (defaultAlgorithm.equals(defaultAlgorithm2)) {
+c = DESedeKeySpec.class;
+} else {
+c = DESKeySpec.class;
+}
+skF[i].getKeySpec(secKeySpec, c);
fail(getKeySpec(secKey, Class):
InvalidKeySpecException must be thrown);
} catch (InvalidKeySpecException e) {
}
Just looking at the 2.java case and will submit a JIRA with both.
-Mark.
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think that would be a workaround once we understand the cause.
geir
Mikhail Loenko wrote:
We may compile the tests old way...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Excluding these two tests:
javax/crypto/SecretKeyFactoryTest1.java
javax/crypto/SecretKeyFactoryTest2.java
then the compilation works.
-Mark.
On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Mark,
Ive just found the same thing while building the crypto tests in windows
using J9 50. All tests up to there are ok. The output I get is similar
to yours:
compile.tests:
[echo] Compiling CRYPTO tests from
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java
[javac] Compiling 31 source files to
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test
[javac] An exception has occurred in the compiler (1.5.0). Please
file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the
following
diagnostic in your report. Thank you.
Ill take a look and see if I can find which class it's compiling at the
time.
Regards,
Oliver
Mark Hindess wrote:
If I do a clean checkout and run:
ant -f make/depends.xml download
ant -f make/build.xml
ant -f make/build-test.xml compile-support
cd modules/crypto
ant -f make/build.xml test
I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0
compiler and get the same error:
An exception has occurred in the compiler (1.5.0_06). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
I assume since everyone else is quietly working on adding 5.0 code
that I am the only one with this problem?
I'm about to try the same test under windows, but thought I'd mention
this hear first.
Regards,
Mark.
--
Mark Hindess [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]
--
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]
--
Mark Hindess [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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Hindess [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: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
Turns out this fixed the compilation on its own. Have submitted the
JIRA HARMONY-344 to record this problem. I hope this doesn't happen
too often now we are using unsupported compiler options but if it does
I hope it's always this simple to work around.
-Mark.
On 4/13/06, Mark Hindess [EMAIL PROTECTED] wrote:
This fixes the *1.java case:
@@ -391,9 +391,13 @@
}
}
try {
-skF[i].getKeySpec(secKeySpec,
-(defaultAlgorithm.equals(defaultAlgorithm2)
-? DESedeKeySpec.class : DESKeySpec.class));
+Class c;
+if (defaultAlgorithm.equals(defaultAlgorithm2)) {
+c = DESedeKeySpec.class;
+} else {
+c = DESKeySpec.class;
+}
+skF[i].getKeySpec(secKeySpec, c);
fail(getKeySpec(secKey, Class):
InvalidKeySpecException must be thrown);
} catch (InvalidKeySpecException e) {
}
Just looking at the 2.java case and will submit a JIRA with both.
-Mark.
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think that would be a workaround once we understand the cause.
geir
Mikhail Loenko wrote:
We may compile the tests old way...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Excluding these two tests:
javax/crypto/SecretKeyFactoryTest1.java
javax/crypto/SecretKeyFactoryTest2.java
then the compilation works.
-Mark.
On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Mark,
Ive just found the same thing while building the crypto tests in windows
using J9 50. All tests up to there are ok. The output I get is similar
to yours:
compile.tests:
[echo] Compiling CRYPTO tests from
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java
[javac] Compiling 31 source files to
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test
[javac] An exception has occurred in the compiler (1.5.0). Please
file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the
following
diagnostic in your report. Thank you.
Ill take a look and see if I can find which class it's compiling at the
time.
Regards,
Oliver
Mark Hindess wrote:
If I do a clean checkout and run:
ant -f make/depends.xml download
ant -f make/build.xml
ant -f make/build-test.xml compile-support
cd modules/crypto
ant -f make/build.xml test
I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0
compiler and get the same error:
An exception has occurred in the compiler (1.5.0_06). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
I assume since everyone else is quietly working on adding 5.0 code
that I am the only one with this problem?
I'm about to try the same test under windows, but thought I'd mention
this hear first.
Regards,
Mark.
--
Mark Hindess [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]
--
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]
--
Mark Hindess [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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
Re: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
Thanks Mark
This fixes the compilation problems I saw in ~1.java and ~2.java. I can
now run the crypto testsuite through in Windows ok with no failures. I
will run the whole set of testsuites for all modules and post if I see
anything similar elsewhere.
Mark Hindess wrote:
This fixes the *1.java case:
@@ -391,9 +391,13 @@
}
}
try {
-skF[i].getKeySpec(secKeySpec,
-(defaultAlgorithm.equals(defaultAlgorithm2)
-? DESedeKeySpec.class : DESKeySpec.class));
+Class c;
+if (defaultAlgorithm.equals(defaultAlgorithm2)) {
+c = DESedeKeySpec.class;
+} else {
+c = DESKeySpec.class;
+}
+skF[i].getKeySpec(secKeySpec, c);
fail(getKeySpec(secKey, Class):
InvalidKeySpecException must be thrown);
} catch (InvalidKeySpecException e) {
}
Just looking at the 2.java case and will submit a JIRA with both.
-Mark.
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think that would be a workaround once we understand the cause.
geir
Mikhail Loenko wrote:
We may compile the tests old way...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Excluding these two tests:
javax/crypto/SecretKeyFactoryTest1.java
javax/crypto/SecretKeyFactoryTest2.java
then the compilation works.
-Mark.
On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Mark,
Ive just found the same thing while building the crypto tests in windows
using J9 50. All tests up to there are ok. The output I get is similar
to yours:
compile.tests:
[echo] Compiling CRYPTO tests from
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java
[javac] Compiling 31 source files to
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test
[javac] An exception has occurred in the compiler (1.5.0). Please
file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the
following
diagnostic in your report. Thank you.
Ill take a look and see if I can find which class it's compiling at the
time.
Regards,
Oliver
Mark Hindess wrote:
If I do a clean checkout and run:
ant -f make/depends.xml download
ant -f make/build.xml
ant -f make/build-test.xml compile-support
cd modules/crypto
ant -f make/build.xml test
I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0
compiler and get the same error:
An exception has occurred in the compiler (1.5.0_06). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
I assume since everyone else is quietly working on adding 5.0 code
that I am the only one with this problem?
I'm about to try the same test under windows, but thought I'd mention
this hear first.
Regards,
Mark.
--
Mark Hindess [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]
--
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]
--
Mark Hindess [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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Hindess [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]
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To
Re: svn commit: r393797 [1/3] - in /incubator/harmony/enhanced/classlib/trunk/modules: auth/src/main/java/common/javax/security/sasl/ luni-kernel/src/main/java/java/lang/ luni/src/main/java/java/lang/
FYI: I also see failures compiling the security tests after this commit: [exec] [javac] Compiling 339 source files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/bin/test [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/AlgorithmParametersTest.java:181: getParameterSpec(java.lang.Class) in java.security.AlgorithmParameters cannot be applied to (java.lang.Class) [exec] [javac] ap.getParameterSpec(new Object().getClass()); [exec] [javac] ^ [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/AlgorithmParametersTest.java:218: getParameterSpec(java.lang.Class) in java.security.AlgorithmParameters cannot be applied to (java.lang.Class) [exec] [javac] ap.getParameterSpec(new Object().getClass()); [exec] [javac] ^ [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/KeyStore1Test.java:1089: entryInstanceOf(java.lang.String,java.lang.Class) in java.security.KeyStore cannot be applied to (java.lang.String,java.lang.Class) [exec] [javac] kss[i].entryInstanceOf(aliases[j], privKey.getClass())); [exec] [javac]^ -Mark. On 4/13/06, Mark Hindess [EMAIL PROTECTED] wrote: No problem. Just checking. Oliver and I are looking at it and I think we can narrow it down enough that it wont stop us using jsr14. -Mark. On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Yes, sure. I've got your message after commit. Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: Please can we fix/understand the compilation jsr14 problems before committing more 5.0 code? Regards, Mark. -- Mark Hindess [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] -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Mark Hindess [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: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
I've just created workspave from scratch and built it according to instructions.
Everything passed.
Windows XP, BEA 1.5
Thanks,
Mikhail
2006/4/13, Oliver Deakin [EMAIL PROTECTED]:
Thanks Mark
This fixes the compilation problems I saw in ~1.java and ~2.java. I can
now run the crypto testsuite through in Windows ok with no failures. I
will run the whole set of testsuites for all modules and post if I see
anything similar elsewhere.
Mark Hindess wrote:
This fixes the *1.java case:
@@ -391,9 +391,13 @@
}
}
try {
-skF[i].getKeySpec(secKeySpec,
-(defaultAlgorithm.equals(defaultAlgorithm2)
-? DESedeKeySpec.class : DESKeySpec.class));
+Class c;
+if (defaultAlgorithm.equals(defaultAlgorithm2)) {
+c = DESedeKeySpec.class;
+} else {
+c = DESKeySpec.class;
+}
+skF[i].getKeySpec(secKeySpec, c);
fail(getKeySpec(secKey, Class):
InvalidKeySpecException must be thrown);
} catch (InvalidKeySpecException e) {
}
Just looking at the 2.java case and will submit a JIRA with both.
-Mark.
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think that would be a workaround once we understand the cause.
geir
Mikhail Loenko wrote:
We may compile the tests old way...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Excluding these two tests:
javax/crypto/SecretKeyFactoryTest1.java
javax/crypto/SecretKeyFactoryTest2.java
then the compilation works.
-Mark.
On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Mark,
Ive just found the same thing while building the crypto tests in windows
using J9 50. All tests up to there are ok. The output I get is similar
to yours:
compile.tests:
[echo] Compiling CRYPTO tests from
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java
[javac] Compiling 31 source files to
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test
[javac] An exception has occurred in the compiler (1.5.0). Please
file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the
following
diagnostic in your report. Thank you.
Ill take a look and see if I can find which class it's compiling at the
time.
Regards,
Oliver
Mark Hindess wrote:
If I do a clean checkout and run:
ant -f make/depends.xml download
ant -f make/build.xml
ant -f make/build-test.xml compile-support
cd modules/crypto
ant -f make/build.xml test
I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0
compiler and get the same error:
An exception has occurred in the compiler (1.5.0_06). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
I assume since everyone else is quietly working on adding 5.0 code
that I am the only one with this problem?
I'm about to try the same test under windows, but thought I'd mention
this hear first.
Regards,
Mark.
--
Mark Hindess [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]
--
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]
--
Mark Hindess [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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Hindess [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
Re: svn commit: r393797 [1/3] - in /incubator/harmony/enhanced/classlib/trunk/modules: auth/src/main/java/common/javax/security/sasl/ luni-kernel/src/main/java/java/lang/ luni/src/main/java/java/lang/
I've reproduced failure in 'security' module when created ws from scratch will look at it Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: FYI: I also see failures compiling the security tests after this commit: [exec] [javac] Compiling 339 source files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/bin/test [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/AlgorithmParametersTest.java:181: getParameterSpec(java.lang.Class) in java.security.AlgorithmParameters cannot be applied to (java.lang.Class) [exec] [javac] ap.getParameterSpec(new Object().getClass()); [exec] [javac] ^ [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/AlgorithmParametersTest.java:218: getParameterSpec(java.lang.Class) in java.security.AlgorithmParameters cannot be applied to (java.lang.Class) [exec] [javac] ap.getParameterSpec(new Object().getClass()); [exec] [javac] ^ [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/KeyStore1Test.java:1089: entryInstanceOf(java.lang.String,java.lang.Class) in java.security.KeyStore cannot be applied to (java.lang.String,java.lang.Class) [exec] [javac] kss[i].entryInstanceOf(aliases[j], privKey.getClass())); [exec] [javac]^ -Mark. On 4/13/06, Mark Hindess [EMAIL PROTECTED] wrote: No problem. Just checking. Oliver and I are looking at it and I think we can narrow it down enough that it wont stop us using jsr14. -Mark. On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Yes, sure. I've got your message after commit. Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: Please can we fix/understand the compilation jsr14 problems before committing more 5.0 code? Regards, Mark. -- Mark Hindess [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] -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Mark Hindess [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: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
And with the Sun compiler? It should be trivial to reproduce.
-Mark.
On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I've just created workspave from scratch and built it according to
instructions.
Everything passed.
Windows XP, BEA 1.5
Thanks,
Mikhail
2006/4/13, Oliver Deakin [EMAIL PROTECTED]:
Thanks Mark
This fixes the compilation problems I saw in ~1.java and ~2.java. I can
now run the crypto testsuite through in Windows ok with no failures. I
will run the whole set of testsuites for all modules and post if I see
anything similar elsewhere.
Mark Hindess wrote:
This fixes the *1.java case:
@@ -391,9 +391,13 @@
}
}
try {
-skF[i].getKeySpec(secKeySpec,
-(defaultAlgorithm.equals(defaultAlgorithm2)
-? DESedeKeySpec.class :
DESKeySpec.class));
+Class c;
+if (defaultAlgorithm.equals(defaultAlgorithm2)) {
+c = DESedeKeySpec.class;
+} else {
+c = DESKeySpec.class;
+}
+skF[i].getKeySpec(secKeySpec, c);
fail(getKeySpec(secKey, Class):
InvalidKeySpecException must be thrown);
} catch (InvalidKeySpecException e) {
}
Just looking at the 2.java case and will submit a JIRA with both.
-Mark.
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think that would be a workaround once we understand the cause.
geir
Mikhail Loenko wrote:
We may compile the tests old way...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Excluding these two tests:
javax/crypto/SecretKeyFactoryTest1.java
javax/crypto/SecretKeyFactoryTest2.java
then the compilation works.
-Mark.
On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Mark,
Ive just found the same thing while building the crypto tests in
windows
using J9 50. All tests up to there are ok. The output I get is similar
to yours:
compile.tests:
[echo] Compiling CRYPTO tests from
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java
[javac] Compiling 31 source files to
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test
[javac] An exception has occurred in the compiler (1.5.0). Please
file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and the
following
diagnostic in your report. Thank you.
Ill take a look and see if I can find which class it's compiling at
the
time.
Regards,
Oliver
Mark Hindess wrote:
If I do a clean checkout and run:
ant -f make/depends.xml download
ant -f make/build.xml
ant -f make/build-test.xml compile-support
cd modules/crypto
ant -f make/build.xml test
I get a compiler error. I've tried using both an IBM 5.0 and Sun 5.0
compiler and get the same error:
An exception has occurred in the compiler (1.5.0_06). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug
Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
I assume since everyone else is quietly working on adding 5.0 code
that I am the only one with this problem?
I'm about to try the same test under windows, but thought I'd mention
this hear first.
Regards,
Mark.
--
Mark Hindess [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]
--
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]
--
Mark Hindess [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: svn commit: r393797 [1/3] - in /incubator/harmony/enhanced/classlib/trunk/modules: auth/src/main/java/common/javax/security/sasl/ luni-kernel/src/main/java/java/lang/ luni/src/main/java/java/lang/
Please can you commit HARMONY-343 - to fix the clean target - so we get to see these failures before they get committed? -Mark On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've reproduced failure in 'security' module when created ws from scratch will look at it Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: FYI: I also see failures compiling the security tests after this commit: [exec] [javac] Compiling 339 source files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/bin/test [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/AlgorithmParametersTest.java:181: getParameterSpec(java.lang.Class) in java.security.AlgorithmParameters cannot be applied to (java.lang.Class) [exec] [javac] ap.getParameterSpec(new Object().getClass()); [exec] [javac] ^ [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/AlgorithmParametersTest.java:218: getParameterSpec(java.lang.Class) in java.security.AlgorithmParameters cannot be applied to (java.lang.Class) [exec] [javac] ap.getParameterSpec(new Object().getClass()); [exec] [javac] ^ [exec] [javac] /home/hybld/continuum-1.0.2/apps/continuum/working-directory/8/classlib/modules/security/src/test/java/common/java/security/KeyStore1Test.java:1089: entryInstanceOf(java.lang.String,java.lang.Class) in java.security.KeyStore cannot be applied to (java.lang.String,java.lang.Class) [exec] [javac] kss[i].entryInstanceOf(aliases[j], privKey.getClass())); [exec] [javac]^ -Mark. On 4/13/06, Mark Hindess [EMAIL PROTECTED] wrote: No problem. Just checking. Oliver and I are looking at it and I think we can narrow it down enough that it wont stop us using jsr14. -Mark. On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Yes, sure. I've got your message after commit. Thanks, Mikhail 2006/4/13, Mark Hindess [EMAIL PROTECTED]: Please can we fix/understand the compilation jsr14 problems before committing more 5.0 code? Regards, Mark. -- Mark Hindess [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] -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Mark Hindess [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] -- Mark Hindess [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: Contribution of RMI framework
Cool! How does this compare to the other RMI framework that also has been donated? Any thoughts? geir Zakharov, Vasily M wrote: Hi, all, I would like to announce the next code contribution to Harmony project on behalf of Intel corporation. This contribution contains the implementation of RMI framework. The archive with this contribution can be found at: http://issues.apache.org/jira/browse/HARMONY-337 The Remote Method Invocation (RMI) framework enables an object in one virtual machine to call methods of an object in another one, to create applications distributed on various Java virtual machines on the same or different hosts. For more information please see the documentation contained in the bundle. The code is a result of efforts of Intel Middleware Product Division team. One should be able to run this code with a 1.4+ compatible JRE/VM (was tested using commercial VMs). No classes require special support from the VM. All code is pure Java. The implementation is done according to Java 1.4 specification of RMI. The archive contains the README file that explains the building and running process for this code. If any additional comments or clarifications are needed, feel free to contact me. I will be happy to answer all questions about this contribution and to participate in its further development/maintenance and integration into Harmony. Vasily Zakharov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
Can you not fix it anyway? Please. It's a trivial refactoring.
Regards,
Mark.
On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I do not have one :)
Will try...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
And with the Sun compiler? It should be trivial to reproduce.
-Mark.
On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I've just created workspave from scratch and built it according to
instructions.
Everything passed.
Windows XP, BEA 1.5
Thanks,
Mikhail
2006/4/13, Oliver Deakin [EMAIL PROTECTED]:
Thanks Mark
This fixes the compilation problems I saw in ~1.java and ~2.java. I can
now run the crypto testsuite through in Windows ok with no failures. I
will run the whole set of testsuites for all modules and post if I see
anything similar elsewhere.
Mark Hindess wrote:
This fixes the *1.java case:
@@ -391,9 +391,13 @@
}
}
try {
-skF[i].getKeySpec(secKeySpec,
-(defaultAlgorithm.equals(defaultAlgorithm2)
-? DESedeKeySpec.class :
DESKeySpec.class));
+Class c;
+if (defaultAlgorithm.equals(defaultAlgorithm2)) {
+c = DESedeKeySpec.class;
+} else {
+c = DESKeySpec.class;
+}
+skF[i].getKeySpec(secKeySpec, c);
fail(getKeySpec(secKey, Class):
InvalidKeySpecException must be thrown);
} catch (InvalidKeySpecException e) {
}
Just looking at the 2.java case and will submit a JIRA with both.
-Mark.
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think that would be a workaround once we understand the cause.
geir
Mikhail Loenko wrote:
We may compile the tests old way...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Excluding these two tests:
javax/crypto/SecretKeyFactoryTest1.java
javax/crypto/SecretKeyFactoryTest2.java
then the compilation works.
-Mark.
On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Mark,
Ive just found the same thing while building the crypto tests in
windows
using J9 50. All tests up to there are ok. The output I get is
similar
to yours:
compile.tests:
[echo] Compiling CRYPTO tests from
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java
[javac] Compiling 31 source files to
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test
[javac] An exception has occurred in the compiler (1.5.0).
Please
file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program and
the
following
diagnostic in your report. Thank you.
Ill take a look and see if I can find which class it's compiling
at the
time.
Regards,
Oliver
Mark Hindess wrote:
If I do a clean checkout and run:
ant -f make/depends.xml download
ant -f make/build.xml
ant -f make/build-test.xml compile-support
cd modules/crypto
ant -f make/build.xml test
I get a compiler error. I've tried using both an IBM 5.0 and
Sun 5.0
compiler and get the same error:
An exception has occurred in the compiler (1.5.0_06). Please
file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug
Parade
for duplicates. Include your program and the following
diagnostic in
your report. Thank you.
I assume since everyone else is quietly working on adding 5.0
code
that I am the only one with this problem?
I'm about to try the same test under windows, but thought I'd
mention
this hear first.
Regards,
Mark.
--
Mark Hindess [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]
--
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]
--
Mark Hindess [EMAIL PROTECTED]
Re: Long,long testcase name...
On Wed, Apr 12, 2006 at 10:49:19AM -0400, Geir Magnusson Jr wrote: But these are the names of *test case methods*. Yes indeed. Lazy consensus works well when the thing we don't care about is the thing where we let the people that do care have their way with them, innit? Very efficient! Can someone give me a use case where having this gibberish name really, practically, adds any value? No doubt that's not possible given certain definitions of use case, value, and practicality. If you're like me, you type Alt+Ctrl+T in IntelliJ while having a method-to-test selected and it generates the test case name. So there is a use case (me writing a test), quite a practical one, and the value is that it saves me from having to rename a method. My environment is set up well for this kind of convention. Arguably, that's not important since I'm not writing tests for harmony right now. And even less important since most developers arond here seem to be using eclipse. Similarly, I often try and keep my methods sorted alphabetically (again, a convention, chosen since IntelliJ can do it automatically). If you name tests after the method they test and after what they do to that method, it results in a nicely organised testcase. Also not very relevant here. But it might be use cases. Sounds more like making good use of a convention (and here we enter the convention over configuration meme which nowadays you can't get away with without a reference to ruby on rails. Soon it'll be religious...). The only use case for a convention is that it is a convention. Qualifying one convention as gibberish makes me wonder what the qualification is for all the other stuff. Its simple. There are some people out there that do it like that, some tools that are tailored for use by those people, hence it is some sort of convention. There is probably a convention or two in all the tests that we have right now too. Apparently its gibberish-ish too, otherwise this thread would not be there. In the end, I could argue it doesn't matter (since it could be in Urdu for me...) but before we all waste the time to construct these 'tokens' that have embedded meaning, I'd love to hear a use case... I think I have just argued that what matters is that there is *a* convention. All I did was mention one that I knew of. I try not to invent any of my own. Urdu doesn't seem to be the right one, but it might be a lot of fun (like recursive acronyms, or pronouncing luni like looney)! ciao! LSD - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribution of RMI framework
Vasily, good to know that there is someone out there who has also been working on rmi; I believe we'll have a lot to share and discuss about it. Thanks, Daniel - Original Message - From: Zakharov, Vasily M [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Wednesday, April 12, 2006 9:53 PM Subject: Contribution of RMI framework Hi, all, I would like to announce the next code contribution to Harmony project on behalf of Intel corporation. This contribution contains the implementation of RMI framework. The archive with this contribution can be found at: http://issues.apache.org/jira/browse/HARMONY-337 The Remote Method Invocation (RMI) framework enables an object in one virtual machine to call methods of an object in another one, to create applications distributed on various Java virtual machines on the same or different hosts. For more information please see the documentation contained in the bundle. The code is a result of efforts of Intel Middleware Product Division team. One should be able to run this code with a 1.4+ compatible JRE/VM (was tested using commercial VMs). No classes require special support from the VM. All code is pure Java. The implementation is done according to Java 1.4 specification of RMI. The archive contains the README file that explains the building and running process for this code. If any additional comments or clarifications are needed, feel free to contact me. I will be happy to answer all questions about this contribution and to participate in its further development/maintenance and integration into Harmony. Vasily Zakharov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Long,long testcase name...
Leo Simons wrote: On Wed, Apr 12, 2006 at 10:49:19AM -0400, Geir Magnusson Jr wrote: But these are the names of *test case methods*. Yes indeed. Lazy consensus works well when the thing we don't care about is the thing where we let the people that do care have their way with them, innit? Very efficient! Can someone give me a use case where having this gibberish name really, practically, adds any value? No doubt that's not possible given certain definitions of use case, value, and practicality. If you're like me, you type Alt+Ctrl+T in IntelliJ while having a method-to-test selected and it generates the test case name. So there is a use case (me writing a test), quite a practical one, and the value is that it saves me from having to rename a method. My environment is set up well for this kind of convention. Arguably, that's not important since I'm not writing tests for harmony right now. And even less important since most developers arond here seem to be using eclipse. Similarly, I often try and keep my methods sorted alphabetically (again, a convention, chosen since IntelliJ can do it automatically). If you name tests after the method they test and after what they do to that method, it results in a nicely organised testcase. Also not very relevant here. But it might be use cases. Sounds more like making good use of a convention (and here we enter the convention over configuration meme which nowadays you can't get away with without a reference to ruby on rails. Soon it'll be religious...). The only use case for a convention is that it is a convention. Qualifying one convention as gibberish makes me wonder what the qualification is for all the other stuff. Its simple. There are some people out there that do it like that, some tools that are tailored for use by those people, hence it is some sort of convention. There is probably a convention or two in all the tests that we have right now too. Apparently its gibberish-ish too, otherwise this thread would not be there. Professional! :) I remember a famous saying, the code must be written for reading. A good naming style may help developers read and understand. I don't care if its name are test1 or something else, but it may take someone new in Harmony into trouble. Make the code and test clear are helpful, not for ourselves, but for those new comers. One day, with Harmony spreading all over the world, I don't want to hear anyone saying: Woo, who's that guy writing these tests named 'test1,test2,test3', it takes me a lot of time on understanding them, even a mid-school student can do better than this! I agreed that our naming convention must: 1. make it understandable for everyone, what does this method try to do, or at least contain a hint (most important) 2. easy to distinguish if there are some similar ones 3. as short/easy as possible for people to read Any comments? In the end, I could argue it doesn't matter (since it could be in Urdu for me...) but before we all waste the time to construct these 'tokens' that have embedded meaning, I'd love to hear a use case... I think I have just argued that what matters is that there is *a* convention. All I did was mention one that I knew of. I try not to invent any of my own. Urdu doesn't seem to be the right one, but it might be a lot of fun (like recursive acronyms, or pronouncing luni like looney)! ciao! Means Goodbye? The first Italian word I've learned! :) LSD - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compiler error on linux with IBM 5.0 and Sun 5.0 compilers
Thanks, Stepan for fixing that
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Can you not fix it anyway? Please. It's a trivial refactoring.
Regards,
Mark.
On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I do not have one :)
Will try...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
And with the Sun compiler? It should be trivial to reproduce.
-Mark.
On 4/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I've just created workspave from scratch and built it according to
instructions.
Everything passed.
Windows XP, BEA 1.5
Thanks,
Mikhail
2006/4/13, Oliver Deakin [EMAIL PROTECTED]:
Thanks Mark
This fixes the compilation problems I saw in ~1.java and ~2.java. I
can
now run the crypto testsuite through in Windows ok with no failures. I
will run the whole set of testsuites for all modules and post if I see
anything similar elsewhere.
Mark Hindess wrote:
This fixes the *1.java case:
@@ -391,9 +391,13 @@
}
}
try {
-skF[i].getKeySpec(secKeySpec,
-(defaultAlgorithm.equals(defaultAlgorithm2)
-? DESedeKeySpec.class :
DESKeySpec.class));
+Class c;
+if (defaultAlgorithm.equals(defaultAlgorithm2)) {
+c = DESedeKeySpec.class;
+} else {
+c = DESKeySpec.class;
+}
+skF[i].getKeySpec(secKeySpec, c);
fail(getKeySpec(secKey, Class):
InvalidKeySpecException must be thrown);
} catch (InvalidKeySpecException e) {
}
Just looking at the 2.java case and will submit a JIRA with both.
-Mark.
On 4/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think that would be a workaround once we understand the cause.
geir
Mikhail Loenko wrote:
We may compile the tests old way...
Thanks,
Mikhail
2006/4/13, Mark Hindess [EMAIL PROTECTED]:
Excluding these two tests:
javax/crypto/SecretKeyFactoryTest1.java
javax/crypto/SecretKeyFactoryTest2.java
then the compilation works.
-Mark.
On 4/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Hi Mark,
Ive just found the same thing while building the crypto tests
in windows
using J9 50. All tests up to there are ok. The output I get is
similar
to yours:
compile.tests:
[echo] Compiling CRYPTO tests from
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\src\test\java
[javac] Compiling 31 source files to
C:\PROGRA~1\eclipse\workspace\classlib\modules\crypto\bin\test
[javac] An exception has occurred in the compiler (1.5.0).
Please
file a bug
at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after
checking the Bug Parade for duplicates. Include your program
and the
following
diagnostic in your report. Thank you.
Ill take a look and see if I can find which class it's
compiling at the
time.
Regards,
Oliver
Mark Hindess wrote:
If I do a clean checkout and run:
ant -f make/depends.xml download
ant -f make/build.xml
ant -f make/build-test.xml compile-support
cd modules/crypto
ant -f make/build.xml test
I get a compiler error. I've tried using both an IBM 5.0 and
Sun 5.0
compiler and get the same error:
An exception has occurred in the compiler (1.5.0_06). Please
file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the
Bug Parade
for duplicates. Include your program and the following
diagnostic in
your report. Thank you.
I assume since everyone else is quietly working on adding 5.0
code
that I am the only one with this problem?
I'm about to try the same test under windows, but thought I'd
mention
this hear first.
Regards,
Mark.
--
Mark Hindess [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]
--
Oliver Deakin
IBM United Kingdom Limited
Re: Contribution of RMI framework
I think we need compare contributions method by method to assemble the best classlib Thanks, Mikhail 2006/4/14, Daniel Gandara [EMAIL PROTECTED]: Vasily, good to know that there is someone out there who has also been working on rmi; I believe we'll have a lot to share and discuss about it. Thanks, Daniel - Original Message - From: Zakharov, Vasily M [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Sent: Wednesday, April 12, 2006 9:53 PM Subject: Contribution of RMI framework Hi, all, I would like to announce the next code contribution to Harmony project on behalf of Intel corporation. This contribution contains the implementation of RMI framework. The archive with this contribution can be found at: http://issues.apache.org/jira/browse/HARMONY-337 The Remote Method Invocation (RMI) framework enables an object in one virtual machine to call methods of an object in another one, to create applications distributed on various Java virtual machines on the same or different hosts. For more information please see the documentation contained in the bundle. The code is a result of efforts of Intel Middleware Product Division team. One should be able to run this code with a 1.4+ compatible JRE/VM (was tested using commercial VMs). No classes require special support from the VM. All code is pure Java. The implementation is done according to Java 1.4 specification of RMI. The archive contains the README file that explains the building and running process for this code. If any additional comments or clarifications are needed, feel free to contact me. I will be happy to answer all questions about this contribution and to participate in its further development/maintenance and integration into Harmony. Vasily Zakharov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
