[classlib] trouble invoking build from 'afar'
I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ To demonstrate, go to enhanced/classlib and run the following ant script : ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. target name=default ant dir=trunk/ /target /project It bombs because there is some confusion about basedir or something : C:\dev\apache\harmony\enhanced\classlib\trunk\modules\accessibility\build.xml:23: Cannot find C:\dev\apache\harmony\enhanced\classlib\trunk/../../make/properties.xml imported from C:\dev\apache\harmony\enhanced\classlib\trunk\modules\access ibility\build.xml I'll dig into this in the morning, but if any of you ant gurus could propose a fix... 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] Warning - our long paths can be a problem for WinXP
I had same problems several days ago, and I finally resolved it in same way - move the local copy to c:\harmony. IIRC, some html files in some sandbox directory has very long names. Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - 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: [testing] locale dependent tests
Andrew Zhang wrote: On 7/19/06, Richard Liang [EMAIL PROTECTED] wrote: Tim Ellison wrote: Richard Liang wrote: Although the spec does not require the round-trip of applyPattern and toPattern, we still want to get one *certain* pattern through toPattern. Now the problem is the returned pattern is locale-dependent. I'm uncertain about the reason to remove the assertion: 1) Because the behavior is not required by spec, or 2) Because the behavior is locale-dependent It would seem that rather than forcing the locale to be en_US to make the test assertions valid, you could work with the default locale and guard any assertions that are locale-specific. It would seem a shame to loose the diversity of testing on multiple locale machines if the tests always force everyone to look like an American (horror! ;-) ) I would expect the fix therefore to be something like, if locale is en_US go ahead and assert more round-tripping code, otherwise can't test it as the spec allows variances. If a test case passes in all locales, could we think that the behavior tested by the test case is locale-independent? We still have to think about how to test locale-dependent behavior. For example, java.util.Locale.getDisplayName() and java.lang.String.toUpperCase(). To verify both the code logic and locale data, shall we have some tests like ABC_en_US_Test, ABC_en_UK_Test, and ABC_ru_RU_Test? I still confuse what we want to test, the logic or the data? I think most (if not all) i18n related methods actually have same single executable with multiple resource bundles, i.e., the single executable should be locale-independent, the different return value is due to the resource data difference. I think at least for now, we should pay our attention to logic of single executable, and leave the data verification to the i18n libraries' author, say, ICU, they have much more knowledge and authority (at least than me) on this area. If we can get agree on the above, so the i18n related test cases organization are easier to judge: the logic is locale-independent, so ideally the tests should be locale-independent, but we have some exceptional cases, say, the en_UK in MessageFormat case, so we cannot make our tests rely on the default locale, then we just specify one locale(en_US) to the tests, and supplement some exceptional case when we find some. i.e., I don't think we need ABC_en_US_Test, or so. Comments? Hi Richard, For getDisplayName, getDisplayLanguage() and methods like so, which are locale-dependent, I suggest we write implementation tests for them. The test may look like: 1. get default locale 2. get i18n string from ResourceBundle directly 3. get i18n string by locale-dependent method 4. assertEquals If we write test cases like this, these tests are probably locale-independent, because: the executable is probably single. I don't think we should have many locale-dependent methods, we just have many methods with locale-dependent data. Sounds reasonable? Any comments? Thank you! Best regards, Richard Regards, Tim -- Richard Liang China Software Development Lab, IBM -- 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: [classlib][nio]the conflict of RI and spec?
Andrew Zhang wrote:
On 7/19/06, Paulex Yang [EMAIL PROTECTED] wrote:
I tried the test, and it failed as you said with RI on my WinXP. And I
also tried to pass in a read/write FileChannel got from
RandomAccessFile, the test passes.
Paulex, the test fails on my machine!
Seems RI returns 2*length instead of length.
For failure details, please refer to [1].
Oops, I meant it didn't throw exception, I didn't assert the return
value :-[ . Anyway, the fact remains: RI has different behavior for
readonly and readwrite channels.
I consider this is RI's bug, because
no way to have such different behavior in this clear test. So I think we
should follow spec.
I also suggest to report this to Sun JDK bug db as well, because I think
it is not trivial. And I don't believe Sun will at last decide, instead
to fix this, to modify the document as the behavior is implementation
dependent if the source channel has fewer than count bytes remaining...
;-)
Maybe it will be fixed as: For FileChannel, the channel will be
resized to
the postion+count bytes if position+count is greater than current file
channel size. :) Just kidding.
As our compatiblity guideline, we should comply with spec.
But will the behaviour of RI be considered as illogical? Personally I
think RI's behaviour breaks spec, and is only a bit(very limited)
logical.
Any suggestions/comments?
Thanks.
Jimmy, Jing Lv wrote:
Hi:
I find a conflict that RI does not behave as spec says in
java.nio.channels.FileChannel.transforFrom(ReadableByteChannel src,
long position,long count).
The spec says:...Fewer than the requested number of bytes will be
transferred if the source channel has fewer than count bytes
remaining...[1]. As expected, invoking this method with a count
larger than the number of bytes remaining in the ReadableByteChannel,
RI should return a number of bytes exactly transfered. But in fact, RI
throws an IOException. I run the test[2] on windowsXP SP2 with
RI1.5.0_01 and RI1.5.0_06, and on Linux(redhat 9) with RI1.5.0_02 and
RI1.5.0_06, and get the same result.
Currently Harmony behave well on this. I guess this is a bug of
RI, and Harmony implementation is good. If no objection, I suggest add
this test to Harmony.
Any opinions? Thanks!
[1] spec of FileChannel:
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html
[2] the test:
public void test_transferFromLReadableByteChannelJJ_overflow()
throws Exception {
String content = test content;
int length = content.length();
File readFile = File.createTempFile(testfile1, tmp);
File writeFile = File.createTempFile(testfile2, tmp);
FileOutputStream fos = new FileOutputStream(readFile);
try {
fos.write(content.getBytes());
} finally {
fos.close();
}
FileChannel fc1 = new FileInputStream(readFile).getChannel();
FileChannel fc2 = new
FileOutputStream(writeFile).getChannel();
try {
long result = fc2.transferFrom(fc1, 0, length * 2);
assertEquals(length, result);
} finally {
fc1.close();
fc2.close();
}
}
--
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]
[1]
junit.framework.AssertionFailedError: expected:12 but was:24
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:136)
at junit.framework.Assert.assertEquals(Assert.java:142)
at
com.andrew.FileChannelTest.test_transferFromLReadableByteChannelJJ_overflow2
(FileChannelTest.java:55)
... ...
--
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: [classlib] trouble invoking build from 'afar'
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ To demonstrate, go to enhanced/classlib and run the following ant script : ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. target name=default ant dir=trunk/ /target /project It bombs because there is some confusion about basedir or something : C:\dev\apache\harmony\enhanced\classlib\trunk\modules\accessibility\build.xml:23: Cannot find C:\dev\apache\harmony\enhanced\classlib\trunk/../../make/properties.xml imported from C:\dev\apache\harmony\enhanced\classlib\trunk\modules\access ibility\build.xml I'll dig into this in the morning, but if any of you ant gurus could propose a fix... The following fix eliminates your issue: ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. *ant antfile=trunk/build.xml inheritall=false target=build/* /project Thanks, Vladimir. 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: [testing] locale dependent tests
Sounds reasonable. SY, Alexey 2006/7/20, Paulex Yang [EMAIL PROTECTED]: Andrew Zhang wrote: On 7/19/06, Richard Liang [EMAIL PROTECTED] wrote: Tim Ellison wrote: Richard Liang wrote: Although the spec does not require the round-trip of applyPattern and toPattern, we still want to get one *certain* pattern through toPattern. Now the problem is the returned pattern is locale-dependent. I'm uncertain about the reason to remove the assertion: 1) Because the behavior is not required by spec, or 2) Because the behavior is locale-dependent It would seem that rather than forcing the locale to be en_US to make the test assertions valid, you could work with the default locale and guard any assertions that are locale-specific. It would seem a shame to loose the diversity of testing on multiple locale machines if the tests always force everyone to look like an American (horror! ;-) ) I would expect the fix therefore to be something like, if locale is en_US go ahead and assert more round-tripping code, otherwise can't test it as the spec allows variances. If a test case passes in all locales, could we think that the behavior tested by the test case is locale-independent? We still have to think about how to test locale-dependent behavior. For example, java.util.Locale.getDisplayName() and java.lang.String.toUpperCase(). To verify both the code logic and locale data, shall we have some tests like ABC_en_US_Test, ABC_en_UK_Test, and ABC_ru_RU_Test? I still confuse what we want to test, the logic or the data? I think most (if not all) i18n related methods actually have same single executable with multiple resource bundles, i.e., the single executable should be locale-independent, the different return value is due to the resource data difference. I think at least for now, we should pay our attention to logic of single executable, and leave the data verification to the i18n libraries' author, say, ICU, they have much more knowledge and authority (at least than me) on this area. If we can get agree on the above, so the i18n related test cases organization are easier to judge: the logic is locale-independent, so ideally the tests should be locale-independent, but we have some exceptional cases, say, the en_UK in MessageFormat case, so we cannot make our tests rely on the default locale, then we just specify one locale(en_US) to the tests, and supplement some exceptional case when we find some. i.e., I don't think we need ABC_en_US_Test, or so. Comments? Hi Richard, For getDisplayName, getDisplayLanguage() and methods like so, which are locale-dependent, I suggest we write implementation tests for them. The test may look like: 1. get default locale 2. get i18n string from ResourceBundle directly 3. get i18n string by locale-dependent method 4. assertEquals If we write test cases like this, these tests are probably locale-independent, because: the executable is probably single. I don't think we should have many locale-dependent methods, we just have many methods with locale-dependent data. Sounds reasonable? Any comments? Thank you! Best regards, Richard Regards, Tim -- Richard Liang China Software Development Lab, IBM -- 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] -- 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: [build] status
The issue mentioned below disapperead after the latest changes for class library. Nevertheless I'm not clear a clue for this build error. In any case thanks for this fix. Vladimir. On 7/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Can anybody say about the build status on Windows we have now? Unfortunately, I cannot build for the recent sources due to the following issue: [exec] winFont.obj : error LNK2019: unresolved external symbol void __cde l throwNPException(struct JNIEnv_ *,char const *) ( ?throwNPException@@YAXPAUJN Env_@@[EMAIL PROTECTED]) referenced in function _Java_org_apache_harmony_awt_gl_font_Native [EMAIL PROTECTED] [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals [exec] NMAKE : fatal error U1077: 'link' : return code '0x460' [exec] Stop. Any ideas? Thanks, Vladimir. On 7/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto: [EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter nLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) 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] Warning - our long paths can be a problem for WinXP
Where was the problem? Compiling? SY, Alexey 2006/7/20, Geir Magnusson Jr [EMAIL PROTECTED]: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] Warning - our long paths can be a problem for WinXP
FYI, from http://linuxboxadmin.com/articles/filefriction.php : Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: C:\Documents and Settings\USER\My Documents\. Regards, David. On 20.07.2006, at 07:53, Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [classlib] Warning - our long paths can be a problem for WinXP
It also could be the problem of command line length while executing compiler for example. 2006/7/20, David Tanzer [EMAIL PROTECTED]: FYI, from http://linuxboxadmin.com/articles/filefriction.php : Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: C:\Documents and Settings\USER\My Documents\. Regards, David. On 20.07.2006, at 07:53, Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [build] status
This was the build break I tried to own up to yesterday. It was caused by my refactoring of exception function - to have one set not several. (I missed the extern C clause and included it in some C++ code.) -Mark. On 20 July 2006 at 14:30, Vladimir Gorr [EMAIL PROTECTED] wrote: The issue mentioned below disapperead after the latest changes for class library. Nevertheless I'm not clear a clue for this build error. In any case thanks for this fix. Vladimir. On 7/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Can anybody say about the build status on Windows we have now? Unfortunately, I cannot build for the recent sources due to the following issue: [exec] winFont.obj : error LNK2019: unresolved external symbol void __cde l throwNPException(struct JNIEnv_ *,char const *) ( ?throwNPException@@YAXPAUJN Env_@@[EMAIL PROTECTED]) referenced in function _Java_org_apache_harmony_awt_gl_font_Native [EMAIL PROTECTED] [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals [exec] NMAKE : fatal error U1077: 'link' : return code '0x460' [exec] Stop. Any ideas? Thanks, Vladimir. On 7/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto: [EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long...
Re: [drlvm] using the harmony launcher
Andrey Chernyshev wrote: On 7/17/06, Oliver Deakin [EMAIL PROTECTED] wrote: Andrey Chernyshev wrote: SNIP So, IMHO one of the first things that should be done after entering DestroyJavaVM is to check for pending exceptions, and clear them if they're going to interfere with the shutdown sequence. OK, I have added a simple check into the DestroyJavaVM method which does processing of the pending exceptions in HARMONY-927. Great! Thanks, Oliver Thanks, Andrey. I've just created a simple launcher that: - creates a Java VM - invokes the main method of a class that throws a RuntimeException - calls DestroyJavaVM without clearing the pending exception Both the RI and IBM VMs exit without any complaints, so I think that drlvm should match this behaviour also. Regards, Oliver (3) CreateJavaVM can only be called once for now – many internal data structures in DRLVM are kept as global variables (jni_env, java_vm, Global_Env e.t.c.). Therefore, it will be hard to organize the multiple instances of JavaVM unless all these things are encapsulated somewhere (into JNIEnv?). (4) Launcher wants the vm dll in the default directory unless the option is specified. Should we realign the drlvm build output and move all dll's into the default subdir? yup, or put it into a deploy/jdk/jre/bin/drlvm directory and use the launcher options to specify its location. (5) What to do with the _org.apache.harmony.vmi.portlib option that launcher is offering to VM? This passes the classlib port library function table to the VM. I think this just makes the classlib port library available to the VM for it to use/query if it wishes. I think it is fine for the drlvm to ignore this option if it wants to. Regards, Oliver Most likely there are more issues that I'm overlooking at the moment. Please consider the suggested patch is a workaround to make the things working, I'm wondering if there is a more graceful way to do this. Thanks, Andrey. On 7/11/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: OK, so I'm going to add CreateJavaVM into vm\vmcore\src\jni\jni.cpp and also add implementation into DestroyVM (stub is already seem to be present there) based on destroy_vm(). Then we'll see how it works with the launcher. Thanks, Andrey. On 7/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This has been my thinking - even if not perfect, lets get it working using the launcher and then fix as required. It's arguable if that brokenness matters at this point, and I think that there's plenty to be gained from having it work via the launcher. geir Rana Dasgupta wrote: create_vm() looks quite close/complete to being a complete prototype for CreateJavaVM, but I think more work is needed in DestroyVM which prototypes DestroyJavaVM for functional completeness. It is non waiting on user threads, it does not send the corresponding JVMTI shutdown events, I also don't know if it handles shutdown hooks cleanly ( but these may not be critical right now for hooking up to the launcher ). What do you think? When I ran a non trivial test.. upto 32 threads instantiating a very large number of objects with -XcleanupOnExit which uses DestroyVM, it exited cleanly. Maybe OK to hookup and fix bugs as we go. Thanks, Rana On 7/10/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: Yes, it seems like the launcher will need at least JNI_CreateJavaVM and DestroyJavaVM functions. I couldn't find implementation for CreateJavaVM in drlvm codebase. Perhaps create_vm() function in vm\vmcore\src\init\vm_main.cpp can be adopted for that purpose? Is there are any tricks and caveats one should be aware of before trying to produce CreateJavaVM from it? I've also seen a prototype for DestroyJavaVM in vm\vmcore\src\init\vm.cpp - comment says it needs to be improved to wait till all Java threads are completed. Any more ideas what needs to be done to implement those? Thanks, Andrey. - 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] -- Andrey Chernyshev Intel Middleware Products Division -- Oliver Deakin IBM United Kingdom Limited -- Oliver Deakin IBM United Kingdom Limited - Terms of use :
Re: [classlib] Warning - our long paths can be a problem for WinXP
You're right, that's a possibility too. But the command line can be quite long under windows [1] (depending on how you execute the program) so my guess would be that the limitation is the file name length. Regards, David. [1] http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx On 20.07.2006, at 09:35, Alexey Petrenko wrote: It also could be the problem of command line length while executing compiler for example. 2006/7/20, David Tanzer [EMAIL PROTECTED]: FYI, from http://linuxboxadmin.com/articles/filefriction.php : Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: C:\Documents and Settings\USER\My Documents\. Regards, David. On 20.07.2006, at 07:53, Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- 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] smime.p7s Description: S/MIME cryptographic signature
Re: [classlib] Warning - our long paths can be a problem for WinXP
Yep, I think that we should start from the error message. Geir? 2006/7/20, David Tanzer [EMAIL PROTECTED]: You're right, that's a possibility too. But the command line can be quite long under windows [1] (depending on how you execute the program) so my guess would be that the limitation is the file name length. Regards, David. [1] http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx On 20.07.2006, at 09:35, Alexey Petrenko wrote: It also could be the problem of command line length while executing compiler for example. 2006/7/20, David Tanzer [EMAIL PROTECTED]: FYI, from http://linuxboxadmin.com/articles/filefriction.php : Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: C:\Documents and Settings\USER\My Documents\. Regards, David. On 20.07.2006, at 07:53, Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- 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] -- 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][nio]the conflict of RI and spec?
On 7/19/06, Paulex Yang [EMAIL PROTECTED] wrote: I tried the test, and it failed as you said with RI on my WinXP. And I also tried to pass in a read/write FileChannel got from RandomAccessFile, the test passes. I consider this is RI's bug, because no way to have such different behavior in this clear test. So I think we should follow spec. I agree that this is RI bug. RandomAccessFile(rw) works OK because the channel is writable and can be extended by map() method. FileInputStream or RandomAccessFile(r) returns redable channel and we get 'Access Is Denied when map() tries to change its size. The description of such a process could be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6416884 , see item 2 in evaludation. + I examined Sun's bug database I have not found any bug like this reported before. + Note, that this test is failed even with writable source channel: the 'result' is 2*length -- Mikhail Fursov
Re: [classlib] Testing conventions - a proposal
Hi George, Wow, they are fast guys! Thanks for the link. Do you know when do they plan to release 5.0 officially? Regards, 2006/7/19, George Harley [EMAIL PROTECTED]: Hi Alexei, I just downloaded the latest working build of TestNG 5.0 [1] and support for the jvm attribute is in there. This is not the official release build. Best regards, George [1] http://testng.org/testng-5.0.zip Alexei Zakharov wrote: Hi George, Agree, we may experience problems in case of VM hang or crash. I suggest this only as a temporary solution. BTW, the fact that TestNG ant task still doesn't have such attributes looks like a sign for me - TestNG can be still immature in some aspects. Still comparing TestNG and JUnit. Regards, 2006/7/19, George Harley [EMAIL PROTECTED]: Hi Alexei, It's encouraging to hear that (Ant + TestNG + sample tests) all worked fine together on Harmony. In answer to your question I suppose that the ability to fork the tests in a separate VM means that we do not run the risk of possible bugs in Harmony affecting the test harness and therefore the outcome of the tests. Best regards, George Alexei Zakharov wrote: Probably my previous message was not clear enough. Why can't we just invoke everything including ant on top of Harmony for now? At least I was able to build and run test-14 examples from TestNG 4.7 distribution solely on top of j9 + our classlib today. C:\Java\testng-4.7\test-14set JAVA_HOME=c:\Java\harmony\enhanced\classlib\trunk \deploy\jdk\jre C:\Java\testng-4.7\test-14ant -Dbuild.compiler=org.eclipse.jdt.core.JDTCompiler Adapter run Buildfile: build.xml prepare: compile: [echo] -- Compiling JDK 1.4 tests -- run: [echo] -- Running JDK 1.4 tests -- [echo] -- testng-4.7-jdk14.jar -- [testng-14] === [testng-14] TestNG JDK 1.4 [testng-14] Total tests run: 179, Failures: 10, Skips: 0 [testng-14] === ... Exactly the same results as with Sun JDK 1.4. Note: you may need to hatch the build.xml a little bit to achieve this. Thanks, 2006/7/19, George Harley [EMAIL PROTECTED]: Hi Richard, Actually the Ant task always runs the tests in a forked VM. At present, however, the task does not support specifying the forked VM (i.e. there is no equivalent to the JUnit Ant task's jvm attribute). This matter has already been raised with the TestNG folks who seem happy to introduce this. In the meantime we could run the tests using the Ant java task. Best regards, George Richard Liang wrote: According to TestNG Ant Task [1], it seems that the TestNG Ant task does not support to fork a new JVM, that is, we must launch ant using Harmony itself. Any comments? Thanks a lot. [1]http://testng.org/doc/ant.html Best regards, Richard George Harley wrote: Andrew Zhang wrote: On 7/18/06, George Harley [EMAIL PROTECTED] wrote: Oliver Deakin wrote: George Harley wrote: SNIP! Here the annotation on MyTestClass applies to all of its test methods. So what are the well-known TestNG groups that we could define for use inside Harmony ? Here are some of my initial thoughts: * type.impl -- tests that are specific to Harmony So tests are implicitly API unless specified otherwise? I'm slightly confused by your definition of impl tests as tests that are specific to Harmony. Does this mean that impl tests are only those that test classes in org.apache.harmony packages? I thought that impl was our way of saying tests that need to go on the bootclasspath. I think I just need a little clarification... Hi Oliver, I was using the definition of implementation-specific tests that we currently have on the Harmony testing conventions web page. That is, implementation-specific tests are those that are dependent on some aspect of the Harmony implementation and would therefore not pass when run against the RI or other conforming implementations. It's orthogonal to the classpath/bootclasspath issue. * state.broken.platform id -- tests bust on a specific platform * state.broken -- tests broken on every platform but we want to decide whether or not to run from our suite configuration * os.platform id -- tests that are to be run only on the specified platform (a test could be member of more than one of these) And the defaults for these are an unbroken state and runs on any platform. That makes sense... Will the platform ids be organised in a similar way to the platform ids we've discussed before for organisation of native code [1]? The actual string used
Re: [classlib] Testing conventions - a proposal
Richard Liang wrote:
George Harley wrote:
Richard Liang wrote:
George Harley wrote:
Hi,
If annotations were to be used to help us categorise tests in order
to simplify the definition of test configurations - what's included
and excluded etc - then a core set of annotations would need to be
agreed by the project. Consider the possibilities that the TestNG
@Test annotation offers us in this respect.
First, if a test method was identified as being broken and needed
to be excluded from all test runs while awaiting investigation then
it would be a simple matter of setting its enabled field like this:
@Test(enabled=false)
public void myTest() {
...
}
Temporarily disabling a test method in this way means that it can
be left in its original class and we do not have to refer to it in
any suite configuration (e.g. in the suite xml file).
If a test method was identified as being broken on a specific
platform then we could make use of the groups field of the @Test
type by making the method a member of a group that identifies its
predicament. Something like this:
@Test(groups={state.broken.win.IA32})
public void myOtherTest() {
...
}
The configuration for running tests on Windows would then
specifically exclude any test method (or class) that was a member
of that group.
Making a test method or type a member of a well-known group
(well-known in the sense that the name and meaning has been agreed
within the project) is essentially adding some descriptive
attributes to the test. Like adjectives (the groups) and nouns (the
tests) in the English language. To take another example, if there
was a test class that contained methods only intended to be run on
Windows and that were all specific to Harmony (i.e. not API tests)
then one could envisage the following kind of annotation:
@Test(groups={type.impl, os.win.IA32})
public class MyTestClass {
public void testOne() {
...
}
public void testTwo() {
...
}
@Test(enabled=false)
public void brokenTest() {
...
}
}
Here the annotation on MyTestClass applies to all of its test methods.
So what are the well-known TestNG groups that we could define for
use inside Harmony ? Here are some of my initial thoughts:
* type.impl -- tests that are specific to Harmony
* state.broken.platform id -- tests bust on a specific platform
* state.broken -- tests broken on every platform but we want to
decide whether or not to run from our suite configuration
* os.platform id -- tests that are to be run only on the
specified platform (a test could be member of more than one of these)
What does everyone else think ? Does such a scheme sound reasonable ?
Just one question: What's the default test annotation? I mean the
successful api tests which will be run on every platform. Thanks a lot.
Best regards,
Richard
Hi Richard,
I think that just the basic @Test annotation on its own will suffice.
Any better suggestions are welcome.
Just thinking about how to filter out the target test groups :-)
I tried to use the following groups to define the win.IA32 API tests,
but it seems that the tests with the default annotation @Test cannot
be selected. Do I miss anything? Thanks a lot.
groups
run
include name=.* /
include name=os.win.IA32 /
exclude name=type.impl /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
exclude name=os.linux.IA32 /
/run
/groups
The groups I defined:
@Test
@Test(groups={os.win.IA32})
@Test(groups={os.win.IA32, state.broken.win.IA32})
@Test(groups={type.impl})
@Test(groups={state.broken})
@Test(groups={os.linux.IA32})
@Test(groups={state.broken.linux.IA32})
Best regards,
Richard.
Hi Richard,
Infuriating isn't it ?
The approach I have adopted so far is to aim for a single testng.xml
file per module that could be used for all platforms that we run tests
on. The thought of multiple testng.xml files for each module, with each
XML file including platform-specific data duplicated across the files
(save for a few platform identifiers) seemed less than optimal.
So how do we arrive at this single testng.xml file with awareness of its
runtime platform ? And how can that knowledge be applied in the file to
filter just the particular test groups that we want ? Well, the approach
that seems to work best for me so far is to use the make use of some
BeanShell script in which we can detect the platform id as a system
property and then use that inside some pretty straightforward
Java/BeanShell code to select precisely the groups we want to run in a
particular test.
For example, in the following Ant fragment we use the testng task to
launch the tests pointing at a specific testng.xml file
(testng-with-beanshell.xml) and also setting the platform identifier as
a system property
Re: [classlib] Testing conventions - a proposal
Alexei Zakharov wrote: Hi George, Wow, they are fast guys! Thanks for the link. Do you know when do they plan to release 5.0 officially? Regards, Hi Alexei, Actually, I just saw this announcement in my news reader about 15 minutes ago ... http://beust.com/weblog/archives/000400.html Best regards, George 2006/7/19, George Harley [EMAIL PROTECTED]: Hi Alexei, I just downloaded the latest working build of TestNG 5.0 [1] and support for the jvm attribute is in there. This is not the official release build. Best regards, George [1] http://testng.org/testng-5.0.zip Alexei Zakharov wrote: Hi George, Agree, we may experience problems in case of VM hang or crash. I suggest this only as a temporary solution. BTW, the fact that TestNG ant task still doesn't have such attributes looks like a sign for me - TestNG can be still immature in some aspects. Still comparing TestNG and JUnit. Regards, 2006/7/19, George Harley [EMAIL PROTECTED]: Hi Alexei, It's encouraging to hear that (Ant + TestNG + sample tests) all worked fine together on Harmony. In answer to your question I suppose that the ability to fork the tests in a separate VM means that we do not run the risk of possible bugs in Harmony affecting the test harness and therefore the outcome of the tests. Best regards, George Alexei Zakharov wrote: Probably my previous message was not clear enough. Why can't we just invoke everything including ant on top of Harmony for now? At least I was able to build and run test-14 examples from TestNG 4.7 distribution solely on top of j9 + our classlib today. C:\Java\testng-4.7\test-14set JAVA_HOME=c:\Java\harmony\enhanced\classlib\trunk \deploy\jdk\jre C:\Java\testng-4.7\test-14ant -Dbuild.compiler=org.eclipse.jdt.core.JDTCompiler Adapter run Buildfile: build.xml prepare: compile: [echo] -- Compiling JDK 1.4 tests -- run: [echo] -- Running JDK 1.4 tests -- [echo] -- testng-4.7-jdk14.jar -- [testng-14] === [testng-14] TestNG JDK 1.4 [testng-14] Total tests run: 179, Failures: 10, Skips: 0 [testng-14] === ... Exactly the same results as with Sun JDK 1.4. Note: you may need to hatch the build.xml a little bit to achieve this. Thanks, 2006/7/19, George Harley [EMAIL PROTECTED]: Hi Richard, Actually the Ant task always runs the tests in a forked VM. At present, however, the task does not support specifying the forked VM (i.e. there is no equivalent to the JUnit Ant task's jvm attribute). This matter has already been raised with the TestNG folks who seem happy to introduce this. In the meantime we could run the tests using the Ant java task. Best regards, George Richard Liang wrote: According to TestNG Ant Task [1], it seems that the TestNG Ant task does not support to fork a new JVM, that is, we must launch ant using Harmony itself. Any comments? Thanks a lot. [1]http://testng.org/doc/ant.html Best regards, Richard George Harley wrote: Andrew Zhang wrote: On 7/18/06, George Harley [EMAIL PROTECTED] wrote: Oliver Deakin wrote: George Harley wrote: SNIP! Here the annotation on MyTestClass applies to all of its test methods. So what are the well-known TestNG groups that we could define for use inside Harmony ? Here are some of my initial thoughts: * type.impl -- tests that are specific to Harmony So tests are implicitly API unless specified otherwise? I'm slightly confused by your definition of impl tests as tests that are specific to Harmony. Does this mean that impl tests are only those that test classes in org.apache.harmony packages? I thought that impl was our way of saying tests that need to go on the bootclasspath. I think I just need a little clarification... Hi Oliver, I was using the definition of implementation-specific tests that we currently have on the Harmony testing conventions web page. That is, implementation-specific tests are those that are dependent on some aspect of the Harmony implementation and would therefore not pass when run against the RI or other conforming implementations. It's orthogonal to the classpath/bootclasspath issue. * state.broken.platform id -- tests bust on a specific platform * state.broken -- tests broken on every platform but we want to decide whether or not to run from our suite configuration * os.platform id -- tests that are to be run only on the specified platform (a test could be member of more than one of these) And the defaults for these are an unbroken state and runs on any
Re: [drlvm] proposals for VM internationalization
Hello all.
Salikh Zakirov wrote:
far below are results of my experiments with Log4cxx's ResourceBundle.
(I've managed to find it in Log4cxx documentation after carefully
rereading your original post).
The good news is that it does localization (severely limited).
The prototype has following good properties
* The unlocalized message is used as the message key
The message key should be message pattern (not a message), because
some parameters may be in this message. E.g.:
Message pattern with integer parameter: %d
or
Message pattern with one parameter: {0}
* No extra entities were introduced (like non-printable message keys)
What about very long message pattern (e.g. see help message from
VM)? For these cases messageId key should be used.
* The localizable messages are marked by _() notation and can
be extracted from the source code automatically
To my mind solution is graceful for localizable messages extraction.
But should we care about this? Once, these messages should be gathered
and put into properties file.
I propose the following solution:
Modify VM's LoggerString class. The first parameter of composite
message should be message key. If it equals empty string then the
message should not be localized. E.g.:
WARN( Not localizable message with two parameters: 1 and 10)
WARN(localizable message with two parameters: %d and %d 1 10)
or
WARN(localizable message with two parameters: {0} and {1} 1 10)
The things that I have not implemented yet (to save time and make at least
something available):
* loading the system locale value
* reading the locale-specific localization file
* converting the localized messages to locale-specific encoding
What do you mean there?
* converting the unlocalized messages from source encoding (US-ASCII) to
UTF-16 (wchar_t[])
There is big question. We can use there char[] strings. Log4cxx
automatically converts char* to wchar_t*.
Also, we can use utf8 coding for wide characters.
The issues that I have encountered but haven't yet worked out a solution:
* PropertyResourceBundle.getString().c_str() returns the
pointer to the stack
location. To make it work, I had to use wcsdup(), thus introducing
an unacceptable memory leak.
I think there must be some way to get the pointer to original bundle
contents,
but haven't figured out how to achieve it.
May be that's the way:
LOG4CXX_DECODE_WCHAR(chstr, wchrstr);
LOG4CXX_ENCODE_CHAR(charstr, chstr);
charstr.c_str()
* PropertyResourceBundle expects the good property format, so the
unlocalized
messages needs to be mangled to property-compatible form
(in the patch below, the only transformation replaced spaces ' ' with
underscores '_',
but it needs to be generalized).
I agree with you.
Given the number of issues PropertyResourceBundle introduces, and the number
of
services it provides (parsing property-format and constructing in-memory
hashmap),
I think that it would be easier to reimplement the functionality without
using PropertyResourceBundle,
and change the storage on-disk file format to allow unmangled messages be
the keys.
In conclusion there are my suggestions for VM's internationalization:
1. Extend log4cxx::helpers::PropertyResourceBundle class which should
allow lazy (on demand) load of properties.
2. Extend log4cxx::helpers::Properties class to allow string with
spaces as a key.
3. Choose model:
a. _(message key) – localizable ; message – not localizable
b. message key – localizable ; – not localizable.
4. Decide between two variants: printf format specifications or
{number} should be used inside message pattern for parameters.
Thanks Dmitry.
===
From: Salikh Zakirov [EMAIL PROTECTED]
Date: Thu, 13 Jul 2006 12:06:05 +0400
Subject: [PATCH] Dummy l10n implemenation based on Log4cxx
---
vm/include/l10n.h | 31 +++
vm/port/include/loggerstring.h |9 +
vm/vmcore/src/init/l10n.cpp| 66
vm/vmcore/src/init/vm_main.cpp |2 +
4 files changed, 108 insertions(+), 0 deletions(-)
diff --git a/vm/include/l10n.h b/vm/include/l10n.h
new file mode 100755
index 000..bb3edfe
--- /dev/null
+++ b/vm/include/l10n.h
@@ -0,0 +1,31 @@
+#ifndef _L10N_H
+#define _L10N_H
+
+#include string
+#include log4cxx/helpers/propertyresourcebundle.h
+#include log4cxx/helpers/exception.h
+#include wchar.h
+#include cxxlog.h
+
+extern log4cxx::helpers::ResourceBundlePtr
l10n_resource_bundle;
+
+inline const wchar_t* _(const wchar_t* message)
+{
+if (!l10n_resource_bundle) return message;
+try {
+wchar_t* mangled = wcsdup(message);
+wchar_t* c = mangled;
+while (*c) {
+if (*c == L' ') *c = L'_';
+c++;
+}
+std::wstring localized =
l10n_resource_bundle-getString(mangled);
+free(mangled);
+return wcsdup(localized.c_str()); // FIXME: leak
+} catch (log4cxx::helpers::MissingResourceException )
Re: [classlib] resolution of rmi/math/crypto duplication?
2006/7/19, Geir Magnusson Jr [EMAIL PROTECTED]: While it's not a critical thing, this seems like something we want to put to bed. Tim tried taking a run at this for one of these last week, and I'd like to try again. Would some number of days of discussion (like 3) plus a vote be an acceptable way to get this resolved? I think yes Thanks, Mikhail 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: [classlib][nio]the conflict of RI and spec?
Jimmy,
Please add readFile.delete() and writeFile.delete() in the end of test
or .deleteOnExit() in any place. Files created by createTempFile are
not cleaned up automatically.
On 7/19/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Hi:
I find a conflict that RI does not behave as spec says in
java.nio.channels.FileChannel.transforFrom(ReadableByteChannel src,
long position,long count).
The spec says:...Fewer than the requested number of bytes will be
transferred if the source channel has fewer than count bytes
remaining...[1]. As expected, invoking this method with a count larger
than the number of bytes remaining in the ReadableByteChannel, RI should
return a number of bytes exactly transfered. But in fact, RI throws an
IOException. I run the test[2] on windowsXP SP2 with RI1.5.0_01 and
RI1.5.0_06, and on Linux(redhat 9) with RI1.5.0_02 and RI1.5.0_06, and
get the same result.
Currently Harmony behave well on this. I guess this is a bug of RI,
and Harmony implementation is good. If no objection, I suggest add this
test to Harmony.
Any opinions? Thanks!
[1] spec of FileChannel:
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html
[2] the test:
public void test_transferFromLReadableByteChannelJJ_overflow()
throws Exception {
String content = test content;
int length = content.length();
File readFile = File.createTempFile(testfile1, tmp);
File writeFile = File.createTempFile(testfile2, tmp);
FileOutputStream fos = new FileOutputStream(readFile);
try {
fos.write(content.getBytes());
} finally {
fos.close();
}
FileChannel fc1 = new FileInputStream(readFile).getChannel();
FileChannel fc2 = new FileOutputStream(writeFile).getChannel();
try {
long result = fc2.transferFrom(fc1, 0, length * 2);
assertEquals(length, result);
} finally {
fc1.close();
fc2.close();
}
}
--
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]
--
Regards,
Anton Luht,
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]
[classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more robust
Hm... I commented on dev-list on this issue already in using classlib launcher in DRLVM. JNI specification explicitly states that: - After an exception has been raised, the native code must first clear the exception before making other JNI calls. When there is a pending exception, the only JNI functions that are safe to call are ExceptionOccurred(), ExceptionDescribe(), and ExceptionClear(). - See [1] at the end of Exception Handling section (and the end of the page). So, it's nice that VM won't crash if entered JNI function in exception state, but it is obviously resposibility of native code (launcher in our case) to check pending exceptions and process them as necessary _before_ calling into JNI. Regards, Pavel Pervov. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp770 On 7/20/06, Geir Magnusson Jr (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-927?page=all ] Geir Magnusson Jr closed HARMONY-927. - DRLVM's DestroyVM needs to be more robust - Key: HARMONY-927 URL: http://issues.apache.org/jira/browse/HARMONY-927 Project: Harmony Issue Type: Bug Components: DRLVM Reporter: Andrey Chernyshev Assigned To: Geir Magnusson Jr Attachments: destroy_vm.patch drlvm should handle the fact that an exception already exists on entering DestroyJavaVM, and clear it before trying to resolve the VMStart class. Here is a small patch that adds a simple check into the shutdown method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
On 20 July 2006 at 15:34, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
What platform? Works for me on Linux (debian testing).
-Mark.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--=_Part_57416_17500570.1153395298489--
-
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] Warning - our long paths can be a problem for WinXP
Paulex Yang wrote: I had same problems several days ago, and I finally resolved it in same way - move the local copy to c:\harmony. IIRC, some html files in some sandbox directory has very long names. These were ser files in modules/security/src/test/something... We should note this somewhere for the next poor soul using winxp... Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. 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: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Add this line to the test to clarify the situation:
System.out.println(ss.getInetAddress());
I think that for PC with multiple network adapters serversocket IP must be
specified manually.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--
Mikhail Fursov
Re: [classlib] Warning - our long paths can be a problem for WinXP
I wonder if it's fixed in Vista :) On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Paulex Yang wrote: I had same problems several days ago, and I finally resolved it in same way - move the local copy to c:\harmony. IIRC, some html files in some sandbox directory has very long names. These were ser files in modules/security/src/test/something... We should note this somewhere for the next poor soul using winxp... Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. 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] -- Mikhail Fursov
Re: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Hello Mark,
I run the example on MS Windows XP, Harmony classlib+DRLVM dated 11 july
2006.
c:\testc:\Harmony\bin\ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310, debug
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 July 2006 at 15:34, Victor A Martynov [EMAIL PROTECTED]
wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
What platform? Works for me on Linux (debian testing).
-Mark.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--=_Part_57416_17500570.1153395298489--
-
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] trouble invoking build from 'afar'
Vladimir Gorr wrote: On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ [SNIP] The following fix eliminates your issue: ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. *ant antfile=trunk/build.xml inheritall=false target=build/* /project Thanks. That works. I don't understand why ant dir=trunk inheritall=false target=build/ doesn't. I thought when I saw your answer the real problem was that I didn't use 'inheritall=false', but that's not the case. 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] Uncertain behavior of new Socket(0.0.0.0, 1099);
The documentation of java.net.Socket says nothing about 0.0.0.0 address,
but documentation on java.net.DatagramSocket has a reference to it:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramSocket.html
If the IP address is 0.0.0.0, the socket will be bound to the wildcard
address, an IP address chosen by the kernel.
So it's normal to use 0.0.0.0 and we have a bug.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello Mark,
I run the example on MS Windows XP, Harmony classlib+DRLVM dated 11 july
2006.
c:\testc:\Harmony\bin\ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310, debug
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 July 2006 at 15:34, Victor A Martynov [EMAIL PROTECTED]
wrote:
Hello,
I'm having trouble with an application. This problem concerns
creating
java.net.Socket on host 0.0.0.0.
What platform? Works for me on Linux (debian testing).
-Mark.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--=_Part_57416_17500570.1153395298489--
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
Re: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Hello Mikhail,
Here are the results of running the modified test:
---
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099, 0,
InetAddress.getByName(0.0.0.0));
System.out.println(ss.getInetAddress());
Socket s = new Socket(0.0.0.0, 1099);
}
}
---
c:\testjava Test
/0.0.0.0
c:\testC:/Harmony/bin/ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310, debug
c:\testC:/Harmony/bin/ij Test
/0.0.0.0
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:10)
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Add this line to the test to clarify the situation:
System.out.println(ss.getInetAddress());
I think that for PC with multiple network adapters serversocket IP must be
specified manually.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--
Mikhail Fursov
Re: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Mikhail Fursov wrote:
Add this line to the test to clarify the situation:
System.out.println(ss.getInetAddress());
I think that for PC with multiple network adapters serversocket IP must be
specified manually.
I don't think so. 0.0.0.0 should mean all of them, right?
geir
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Testing conventions - a proposal
George,
I remember my past experience with BeanShell - I was trying to create
the custom BeanShell task for ant 1.6.1. I can't say I haven't
succeeded. But I remember this as a rather unpleasant experience. At
that time BeanShell appeared to me as a not very well tested
framework. Please don't throw rocks on me now, I am just talking about
my old impressions. Probably BeanShell has become better since then.
But... Do we really need BS here? Why can't we manage everything from
build.xml without extra testng.xml files? I mean something like this:
!-- determines the OS --
condition property=platform value=win.IA32
os family=Windows/
/condition
condition property=platform value=linux.IA32
and
os name=linux/
os family=unix/
/and
/condition
property name=groups.included value=os.any, os.${platform}/
property name=groups.excluded value=state.broken,
state.broken.${platform}/
target name=run description=Run tests
taskdef name=testng classname=org.testng.TestNGAntTask
classpath=${jdk15.testng.jar}/
testng classpathref=run.cp
outputdir=${testng.report.dir}
groups=${groups.included}
excludedGroups=${groups.excluded}
classfileset dir=. includes=**/*.class/
/testng
/target
Does this make sense?
Thanks,
2006/7/20, George Harley [EMAIL PROTECTED]:
Richard Liang wrote:
George Harley wrote:
Richard Liang wrote:
George Harley wrote:
Hi,
If annotations were to be used to help us categorise tests in order
to simplify the definition of test configurations - what's included
and excluded etc - then a core set of annotations would need to be
agreed by the project. Consider the possibilities that the TestNG
@Test annotation offers us in this respect.
First, if a test method was identified as being broken and needed
to be excluded from all test runs while awaiting investigation then
it would be a simple matter of setting its enabled field like this:
@Test(enabled=false)
public void myTest() {
...
}
Temporarily disabling a test method in this way means that it can
be left in its original class and we do not have to refer to it in
any suite configuration (e.g. in the suite xml file).
If a test method was identified as being broken on a specific
platform then we could make use of the groups field of the @Test
type by making the method a member of a group that identifies its
predicament. Something like this:
@Test(groups={state.broken.win.IA32})
public void myOtherTest() {
...
}
The configuration for running tests on Windows would then
specifically exclude any test method (or class) that was a member
of that group.
Making a test method or type a member of a well-known group
(well-known in the sense that the name and meaning has been agreed
within the project) is essentially adding some descriptive
attributes to the test. Like adjectives (the groups) and nouns (the
tests) in the English language. To take another example, if there
was a test class that contained methods only intended to be run on
Windows and that were all specific to Harmony (i.e. not API tests)
then one could envisage the following kind of annotation:
@Test(groups={type.impl, os.win.IA32})
public class MyTestClass {
public void testOne() {
...
}
public void testTwo() {
...
}
@Test(enabled=false)
public void brokenTest() {
...
}
}
Here the annotation on MyTestClass applies to all of its test methods.
So what are the well-known TestNG groups that we could define for
use inside Harmony ? Here are some of my initial thoughts:
* type.impl -- tests that are specific to Harmony
* state.broken.platform id -- tests bust on a specific platform
* state.broken -- tests broken on every platform but we want to
decide whether or not to run from our suite configuration
* os.platform id -- tests that are to be run only on the
specified platform (a test could be member of more than one of these)
What does everyone else think ? Does such a scheme sound reasonable ?
Just one question: What's the default test annotation? I mean the
successful api tests which will be run on every platform. Thanks a lot.
Best regards,
Richard
Hi Richard,
I think that just the basic @Test annotation on its own will suffice.
Any better suggestions are welcome.
Just thinking about how to filter out the target test groups :-)
I tried to use the following groups to define the win.IA32 API tests,
but it seems that the tests with the default annotation @Test cannot
be selected. Do I miss anything? Thanks a lot.
groups
run
include name=.* /
include name=os.win.IA32 /
exclude name=type.impl /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
exclude name=os.linux.IA32 /
/run
/groups
The groups I defined:
@Test
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more robust
patch welcome ;) geir Pavel Pervov wrote: Hm... I commented on dev-list on this issue already in using classlib launcher in DRLVM. JNI specification explicitly states that: - After an exception has been raised, the native code must first clear the exception before making other JNI calls. When there is a pending exception, the only JNI functions that are safe to call are ExceptionOccurred(), ExceptionDescribe(), and ExceptionClear(). - See [1] at the end of Exception Handling section (and the end of the page). So, it's nice that VM won't crash if entered JNI function in exception state, but it is obviously resposibility of native code (launcher in our case) to check pending exceptions and process them as necessary _before_ calling into JNI. Regards, Pavel Pervov. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp770 On 7/20/06, Geir Magnusson Jr (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-927?page=all ] Geir Magnusson Jr closed HARMONY-927. - DRLVM's DestroyVM needs to be more robust - Key: HARMONY-927 URL: http://issues.apache.org/jira/browse/HARMONY-927 Project: Harmony Issue Type: Bug Components: DRLVM Reporter: Andrey Chernyshev Assigned To: Geir Magnusson Jr Attachments: destroy_vm.patch drlvm should handle the fact that an exception already exists on entering DestroyJavaVM, and clear it before trying to resolve the VMStart class. Here is a small patch that adds a simple check into the shutdown method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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] Warning - our long paths can be a problem for WinXP
checking out of subversion! geir Alexey Petrenko wrote: Where was the problem? Compiling? SY, Alexey 2006/7/20, Geir Magnusson Jr [EMAIL PROTECTED]: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. 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: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Ivanov, Alexey A wrote: Hi all. BTW, my default locale is Russian That's the reason. DecimalFormatTest is locale-dependent, but the test logic doesn't take it into account. In Russian locale, comma is used as decimal separator but not dot. And it is the reason why some tests fail. I see two ways to resolve the problem: 1. Make tests locale-independent by explicitly specifying DecimalFormatSymbols. 2. Fetch these symbols from the DecimalFormat object, and modify the expected values using these data. 3. Specify a locale to the DecimalFormat in the test, should be similar with option 1, actually I suspect they are both necessary, because either locale setting or DecimalFormatSymbols setting should be part of DecimalFormat logic. I prefer the first approach since this ensures we test the underlying logic. [1] I can prepare patch if nobody objects. As for ChoiceFormatTest failure, there seems to be a bug in ChoiceFormatter which can't parse negative numbers. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mb ox/[EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 4:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test BTW, my default locale is Russian 2006/7/18, Alexei Zakharov [EMAIL PROTECTED]: Sure, DecimalFormatTest: Testcase: test_parseLjava_lang_String_Ljava_text_ParsePosition took 0 sec FAILED null junit.framework.AssertionFailedError at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_parseLja va_l ang_String_Ljava_text_ParsePosition(DecimalFormatTest.java:66) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setDecimalSeparatorAlwaysShownZ took 0 sec FAILED Wrong set result expected: but was:..., junit.framework.ComparisonFailure: Wrong set result expected: but was:..., at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setDecim alSe paratorAlwaysShownZ(DecimalFormatTest.java:1361) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMaximumFractionDigitsI took 0 sec FAILED Wrong maximum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong maximum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMaxim umFr actionDigitsI(DecimalFormatTest.java:1410) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumFractionDigitsI took 0,016 sec FAILED Wrong minimum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong minimum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMinim umFr actionDigitsI(DecimalFormatTest.java:1436) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumIntegerDigitsI took 0 sec FAILED Incorrect integer expected:... but was:...,... junit.framework.ComparisonFailure: Incorrect integer expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMinim umIn tegerDigitsI(DecimalFormatTest.java:1452) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) ChoiceFormatTest: === Testcase: test_toPattern took 0,016 sec Caused an ERROR null java.lang.IllegalArgumentException at java.text.ChoiceFormat.applyPattern(ChoiceFormat.java:126) at java.text.ChoiceFormat.init(ChoiceFormat.java:65) at org.apache.harmony.text.tests.java.text.ChoiceFormatTest.test_toPattern (Cho iceFormatTest.java:421) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Does this make sense? Regards, 2006/7/18, Tim Ellison [EMAIL PROTECTED]: Can you send details (e.g. a walkback) from the failing tests? Thanks Tim Alexei Zakharov wrote: Are you talking about HARMONY-910? I've applied it and MessageFormatTest is ok now (thanks, Richard!) But ChoiceFormatTest and DecimalFormatTest continue failing. 2006/7/18, Geir Magnusson Jr [EMAIL PROTECTED]: Read back to the [build] status thread I think that Richard has the fix done... Alexei Zakharov wrote: Nathan, SNIP -- Alexei Zakharov, Intel Middleware Product Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Warning - our long paths can be a problem for WinXP
Geir Magnusson Jr wrote: Paulex Yang wrote: I had same problems several days ago, and I finally resolved it in same way - move the local copy to c:\harmony. IIRC, some html files in some sandbox directory has very long names. These were ser files in modules/security/src/test/something... We should note this somewhere for the next poor soul using winxp... Agree, which page is better place to go[1][2][3]? (or any other pages?) [1] http://incubator.apache.org/harmony/svn.html [2] http://incubator.apache.org/harmony/faq.html [3] http://incubator.apache.org/harmony/documentation/build_website.html Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. 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] -- 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: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Hello Mark,
I checked the behavior of the test on Linux. It seems that the problem
exists on MS Windows only:
--
[EMAIL PROTECTED]:~ uname -a
Linux server 2.6.5-7.145lxset1-smp #1 SMP Thu Jan 27 09:19:29 UTC 2005 i686
i686 i386 GNU/Linux
[EMAIL PROTECTED]:~ Harmony/bin/ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Linux/ia32/gcc 3.3.4, debug
[EMAIL PROTECTED]:~ Harmony/bin/ij Test
/0.0.0.0
[EMAIL PROTECTED]:~ java Test
/0.0.0.0
[EMAIL PROTECTED]:~
--
The fact that Windows and Linux version behavior is different makes me think
that it is a bug in LUNI rather than the bug in RI.
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 July 2006 at 15:34, Victor A Martynov [EMAIL PROTECTED]
wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
What platform? Works for me on Linux (debian testing).
-Mark.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--=_Part_57416_17500570.1153395298489--
-
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] Uncertain behavior of new Socket(0.0.0.0, 1099);
On 7/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
The documentation of java.net.Socket says nothing about 0.0.0.0 address,
but documentation on java.net.DatagramSocket has a reference to it:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramSocket.html
If the IP address is 0.0.0.0, the socket will be bound to the wildcard
address, an IP address chosen by the kernel.
Hello Mikhail, they are different. New DatagramSocket(0.0.0.0,port) means
the datagram socket will be bound to 0.0.0.0, but new Socket(0.0.0.0,port)
means new a socket bound with a system free port and then connect to (
0.0.0.0, port).
I didn't investigate Harmony implementation code, but I guess it's caused by
difference of system call. On windows, 0.0.0.0 is regarded as a invalid
address, while on Linux, it's valid.
I'll take a deep look at the code later on.
So it's normal to use 0.0.0.0 and we have a bug.
Agree. I think we should follow RI this time.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello Mark,
I run the example on MS Windows XP, Harmony classlib+DRLVM dated 11 july
2006.
c:\testc:\Harmony\bin\ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310,
debug
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 July 2006 at 15:34, Victor A Martynov
[EMAIL PROTECTED]
wrote:
Hello,
I'm having trouble with an application. This problem concerns
creating
java.net.Socket on host 0.0.0.0.
What platform? Works for me on Linux (debian testing).
-Mark.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable
{
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--=_Part_57416_17500570.1153395298489--
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] trouble invoking build from 'afar'
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'm having a little trouble w/ classlib build when invoking from an ant task outside of trunk/ [SNIP] The following fix eliminates your issue: ?xml version=1.0 encoding=UTF-8? project name=test default=default basedir=. *ant antfile=trunk/build.xml inheritall=false target=build/* /project Thanks. That works. I don't understand why ant dir=trunk inheritall=false target=build/ doesn't. It seems this is new bug if I correctly undrstand the ant sub-task documentation: *When the antfile attribute is omitted, the file build.xml in the supplied directory (dir attribute) is used.* Thanks, Vladimir. I thought when I saw your answer the real problem was that I didn't use 'inheritall=false', but that's not the case. 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] Uncertain behavior of new Socket(0.0.0.0, 1099);
We have a bug. 0.0.0.0 should be all adapters, and is legit.
Can you file a JIRA?
Victor A Martynov wrote:
Hello Mikhail,
Here are the results of running the modified test:
---
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099, 0,
InetAddress.getByName(0.0.0.0));
System.out.println(ss.getInetAddress());
Socket s = new Socket(0.0.0.0, 1099);
}
}
---
c:\testjava Test
/0.0.0.0
c:\testC:/Harmony/bin/ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310, debug
c:\testC:/Harmony/bin/ij Test
/0.0.0.0
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:10)
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Add this line to the test to clarify the situation:
System.out.println(ss.getInetAddress());
I think that for PC with multiple network adapters serversocket IP
must be
specified manually.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--
Mikhail Fursov
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[general] centralization of the NOTICE, COPYRIGHT, etc files
If you haven't guessed from my random checkins, questions, and befuddlement, I'm finishing off a first cut at a federated build. The plan is to cut a hdk and a jre snapshot. The HDK will contain the jre, but I thought it would be more conventional for users to get a plain jre and not have to figure out what a HDK is. Now, I want to coalesce the NOTICE, COPYRIGHT, 3rd party, etc files into one project-wide file in enhanced/trunk/ and replace the ones we have in classlib/, drlvm/ etc with a NOTICE, etc file that points to the root one. Any complaints, suggestions? 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] Uncertain behavior of new Socket(0.0.0.0, 1099);
2006/7/20, Alexey Petrenko [EMAIL PROTECTED]:
That's a different types of sockets. You specify address to BIND for
DatagramSocket and address to CONNECT for Socket.
Address to bind can be chosen by underlying system.
But how do you suggest to choose address to connect? :)
I'll check the IP protocol spec for the meaning of 0.0.0.0 address. If
there is any...
I could not find anything in the IP spec. But C headers defines
0.0.0.0 as a value for INADDR_ANY constant... Ant it is used to bind a
socket to all the local addresses.
So I think that exception is OK here.
SY, Alexey
2006/7/20, Mikhail Fursov [EMAIL PROTECTED]:
The documentation of java.net.Socket says nothing about 0.0.0.0 address,
but documentation on java.net.DatagramSocket has a reference to it:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramSocket.html
If the IP address is 0.0.0.0, the socket will be bound to the wildcard
address, an IP address chosen by the kernel.
So it's normal to use 0.0.0.0 and we have a bug.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello Mark,
I run the example on MS Windows XP, Harmony classlib+DRLVM dated 11 july
2006.
c:\testc:\Harmony\bin\ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310, debug
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 July 2006 at 15:34, Victor A Martynov [EMAIL PROTECTED]
wrote:
Hello,
I'm having trouble with an application. This problem concerns
creating
java.net.Socket on host 0.0.0.0.
What platform? Works for me on Linux (debian testing).
-Mark.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--=_Part_57416_17500570.1153395298489--
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
--
Alexey A. Petrenko
Intel Middleware Products Division
--
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] Uncertain behavior of new Socket(0.0.0.0, 1099);
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mikhail Fursov wrote:
Add this line to the test to clarify the situation:
System.out.println(ss.getInetAddress());
I think that for PC with multiple network adapters serversocket IP must
be
specified manually.
I don't think so. 0.0.0.0 should mean all of them, right?
Yes. a socket listens on 0.0.0.0 means on it listens on all of network
interfaces on this machine. It's often used for binding function.
But the behaviour of connecting to 0.0.0.0 is unspeicified. At least,
windows treats it as invalid target address, while linux allows it.
geir
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
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]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Yes, you're right - any of them.
BTW I tried to build debug version of classlib to have HYSOCKDEBUG enabled
and have a problem with build (lack of experience)
I tried to add -DDEBUG flag to classlib\trunk\depends\build\defines.mak and
rerun ant build but nothing was rebuilded.
What is the right way to rebuild classlib to enable logging like
HYSOCKDEBUG?
On 7/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mikhail Fursov wrote:
Add this line to the test to clarify the situation:
System.out.println(ss.getInetAddress());
I think that for PC with multiple network adapters serversocket IP must
be
specified manually.
I don't think so. 0.0.0.0 should mean all of them, right?
geir
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble with an application. This problem concerns creating
java.net.Socket on host 0.0.0.0.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
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]
--
Mikhail Fursov
Re: [classlib] Uncertain behavior of new Socket(0.0.0.0, 1099);
Hi Mikhail,
I don't think this description of DatagramSocket constructor is
somehow applicable to the Victor's example. In this description we
deal with *local* address to bind DatagramSocket to (to receive
DatagramPackets). But in the example above 0.0.0.0 is used as a
*destination* address for plain Socket to establish a connection to.
This is the completely different case IMHO. BTW, I'm not sure it is
possible to establish a connection to a wildcard address.
Regards,
2006/7/20, Mikhail Fursov [EMAIL PROTECTED]:
The documentation of java.net.Socket says nothing about 0.0.0.0 address,
but documentation on java.net.DatagramSocket has a reference to it:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramSocket.html
If the IP address is 0.0.0.0, the socket will be bound to the wildcard
address, an IP address chosen by the kernel.
So it's normal to use 0.0.0.0 and we have a bug.
On 7/20/06, Victor A Martynov [EMAIL PROTECTED] wrote:
Hello Mark,
I run the example on MS Windows XP, Harmony classlib+DRLVM dated 11 july
2006.
c:\testc:\Harmony\bin\ij -version
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310, debug
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
On 7/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 July 2006 at 15:34, Victor A Martynov [EMAIL PROTECTED]
wrote:
Hello,
I'm having trouble with an application. This problem concerns
creating
java.net.Socket on host 0.0.0.0.
What platform? Works for me on Linux (debian testing).
-Mark.
The test below illustrates this problem:
import java.net.*;
public class Test {
public static void main(String args[]) throws Throwable {
ServerSocket ss = new ServerSocket(1099);
Socket s = new Socket(0.0.0.0, 1099);
}
}
The output on RI and on Harmony differs:
c:\testjava Test
c:\testC:/Harmony/bin/ij Test
java.net.ConnectException: 0.0.0.0/0.0.0.0:1099 - The address is not
available
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:238)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(
PlainSocketImpl.java:200)
at java.net.Socket.startupSocket(Socket.java:715)
at java.net.Socket.init(Socket.java:139)
at Test.main(Test.java:7)
I wonder whether it is a bug in RI or a bug in LUNI of Harmony?
=
Warm Regards,
Victor Martynov,
Intel Middleware Product Division
--=_Part_57416_17500570.1153395298489--
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (HARMONY-927) DRLVM's DestroyVM needs to be more robust
I agree Pavel - it should be fixed in the launcher. But, as I said in [1], we should give some consideration to the fact that the RI and IBM vms exit gracefully under the same circumstances, and that perhaps we should also try to fix this in the drlvm to match their behaviour. I started to think of ways simply calling ExceptionClear wouldnt result in a clean exit from drlvm. An OutOfMemoryError followed by DestroyJavaVM would probably still result in a failure in VMStart, so just calling ExceptionClear might not be enough to guarantee clean exit - however it does make the exit more likely to complete successfully, so I think it is a change worth making. Is there any reason against making the change? Thinking about this makes me wonder how drlvm will exit cleanly when there is an OutOfMemoryError when running it from the drlvm launcher. If the heap is full, surely trying to run shutdown code in VMStart is dangerous anyway? Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] Pavel Pervov wrote: Hm... I commented on dev-list on this issue already in using classlib launcher in DRLVM. JNI specification explicitly states that: - After an exception has been raised, the native code must first clear the exception before making other JNI calls. When there is a pending exception, the only JNI functions that are safe to call are ExceptionOccurred(), ExceptionDescribe(), and ExceptionClear(). - See [1] at the end of Exception Handling section (and the end of the page). So, it's nice that VM won't crash if entered JNI function in exception state, but it is obviously resposibility of native code (launcher in our case) to check pending exceptions and process them as necessary _before_ calling into JNI. Regards, Pavel Pervov. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp770 On 7/20/06, Geir Magnusson Jr (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-927?page=all ] Geir Magnusson Jr closed HARMONY-927. - DRLVM's DestroyVM needs to be more robust - Key: HARMONY-927 URL: http://issues.apache.org/jira/browse/HARMONY-927 Project: Harmony Issue Type: Bug Components: DRLVM Reporter: Andrey Chernyshev Assigned To: Geir Magnusson Jr Attachments: destroy_vm.patch drlvm should handle the fact that an exception already exists on entering DestroyJavaVM, and clear it before trying to resolve the VMStart class. Here is a small patch that adds a simple check into the shutdown method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Doing the minimum to support Java 5 classfiles
Alexey Varlamov wrote: Good news: with patches for HARMONY-677, I was able to run 1.5 classes on DRLVM + classlib built with target=1.5. But, I had some fun with the default javac (tried Sun jdk1.5.0_06 and jrockit-jdk1.5.0-windows-ia32), which outwits itself in optimizing String concatenations. Alexey, FYI I've applied a workaround to StringBuilder in r423942. 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] Testing conventions - a proposal
Alexei Zakharov wrote:
George,
I remember my past experience with BeanShell - I was trying to create
the custom BeanShell task for ant 1.6.1. I can't say I haven't
succeeded. But I remember this as a rather unpleasant experience. At
that time BeanShell appeared to me as a not very well tested
framework. Please don't throw rocks on me now, I am just talking about
my old impressions. Probably BeanShell has become better since then.
Hi Alexei,
No rocks. I promise :-)
But... Do we really need BS here? Why can't we manage everything from
build.xml without extra testng.xml files? I mean something like this:
!-- determines the OS --
condition property=platform value=win.IA32
os family=Windows/
/condition
condition property=platform value=linux.IA32
and
os name=linux/
os family=unix/
/and
/condition
property name=groups.included value=os.any, os.${platform}/
property name=groups.excluded value=state.broken,
state.broken.${platform}/
target name=run description=Run tests
taskdef name=testng classname=org.testng.TestNGAntTask
classpath=${jdk15.testng.jar}/
testng classpathref=run.cp
outputdir=${testng.report.dir}
groups=${groups.included}
excludedGroups=${groups.excluded}
classfileset dir=. includes=**/*.class/
/testng
/target
Does this make sense?
Thanks,
Yes, that makes sense and if it gives the degree of control that we need
then I would be all for it. The simpler the better.
It looks like you are using an os.any group for those test methods
(the majority) which may be run anywhere. That's a different approach to
what I have been doing. I have been thinking more along the lines of
avoiding the creation of groups that cover the majority of tests and
trying to focus on groups that identify those edge cases like
platform-specific, temporarily broken, temporarily broken on platform
os.blah etc. This means my tests that are run anywhere and are
public api type (as opposed to being specific to the Harmony
implementation) are just annotated with @Test. I guess that the
equivalent in your scheme would be annotated as @Test(groups =
{os.any, type.api}) ?
If I have inferred correct from your Ant fragment then I think it means
requiring more information on the annotations. I'm not throwing rocks at
that idea (remember my promise ?), just trying to draw out the
differences in our approaches. When I get a chance I will try and
explore your idea further.
I really appreciate your input here.
Best regards,
George
2006/7/20, George Harley [EMAIL PROTECTED]:
Richard Liang wrote:
George Harley wrote:
Richard Liang wrote:
George Harley wrote:
Hi,
If annotations were to be used to help us categorise tests in order
to simplify the definition of test configurations - what's included
and excluded etc - then a core set of annotations would need to be
agreed by the project. Consider the possibilities that the TestNG
@Test annotation offers us in this respect.
First, if a test method was identified as being broken and needed
to be excluded from all test runs while awaiting investigation then
it would be a simple matter of setting its enabled field like this:
@Test(enabled=false)
public void myTest() {
...
}
Temporarily disabling a test method in this way means that it can
be left in its original class and we do not have to refer to it in
any suite configuration (e.g. in the suite xml file).
If a test method was identified as being broken on a specific
platform then we could make use of the groups field of the @Test
type by making the method a member of a group that identifies its
predicament. Something like this:
@Test(groups={state.broken.win.IA32})
public void myOtherTest() {
...
}
The configuration for running tests on Windows would then
specifically exclude any test method (or class) that was a member
of that group.
Making a test method or type a member of a well-known group
(well-known in the sense that the name and meaning has been agreed
within the project) is essentially adding some descriptive
attributes to the test. Like adjectives (the groups) and nouns (the
tests) in the English language. To take another example, if there
was a test class that contained methods only intended to be run on
Windows and that were all specific to Harmony (i.e. not API tests)
then one could envisage the following kind of annotation:
@Test(groups={type.impl, os.win.IA32})
public class MyTestClass {
public void testOne() {
...
}
public void testTwo() {
...
}
@Test(enabled=false)
public void brokenTest() {
...
}
}
Here the annotation on MyTestClass applies to all of its test
methods.
So what are the well-known TestNG groups that we could define for
use inside Harmony ? Here are some of my initial thoughts:
* type.impl -- tests that are specific to Harmony
* state.broken.platform id -- tests bust on a
RE: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Investigation shows that ChoiceFormatTest fails because of the same reason as DecimalFormatTest. ChoiceFormat uses DecimalFormat to parse template passed. And the template contains 1.0is 1+, so that DecimalFormat stops parsing when it encounters '.' because dot is not decimal separator in Russian locale. This is definitely not what was expected. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 3:02 PM To: harmony-dev@incubator.apache.org Subject: RE: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Hi all. BTW, my default locale is Russian That's the reason. DecimalFormatTest is locale-dependent, but the test logic doesn't take it into account. In Russian locale, comma is used as decimal separator but not dot. And it is the reason why some tests fail. I see two ways to resolve the problem: 1. Make tests locale-independent by explicitly specifying DecimalFormatSymbols. 2. Fetch these symbols from the DecimalFormat object, and modify the expected values using these data. I prefer the first approach since this ensures we test the underlying logic. [1] I can prepare patch if nobody objects. As for ChoiceFormatTest failure, there seems to be a bug in ChoiceFormatter which can't parse negative numbers. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.m b ox/[EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 4:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test BTW, my default locale is Russian 2006/7/18, Alexei Zakharov [EMAIL PROTECTED]: Sure, DecimalFormatTest: Testcase: test_parseLjava_lang_String_Ljava_text_ParsePosition took 0 sec FAILED null junit.framework.AssertionFailedError at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_parseLj a va_l ang_String_Ljava_text_ParsePosition(DecimalFormatTest.java:66) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setDecimalSeparatorAlwaysShownZ took 0 sec FAILED Wrong set result expected: but was:..., junit.framework.ComparisonFailure: Wrong set result expected: but was:..., at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setDeci m alSe paratorAlwaysShownZ(DecimalFormatTest.java:1361) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMaximumFractionDigitsI took 0 sec FAILED Wrong maximum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong maximum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMaxi m umFr actionDigitsI(DecimalFormatTest.java:1410) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumFractionDigitsI took 0,016 sec FAILED Wrong minimum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong minimum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMini m umFr actionDigitsI(DecimalFormatTest.java:1436) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumIntegerDigitsI took 0 sec FAILED Incorrect integer expected:... but was:...,... junit.framework.ComparisonFailure: Incorrect integer expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMini m umIn tegerDigitsI(DecimalFormatTest.java:1452) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) ChoiceFormatTest: === Testcase: test_toPattern took 0,016 sec Caused an ERROR null java.lang.IllegalArgumentException at java.text.ChoiceFormat.applyPattern(ChoiceFormat.java:126) at java.text.ChoiceFormat.init(ChoiceFormat.java:65) at org.apache.harmony.text.tests.java.text.ChoiceFormatTest.test_toPatter n (Cho iceFormatTest.java:421) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Does this make sense? Regards, 2006/7/18, Tim Ellison [EMAIL PROTECTED]: Can you send details (e.g. a walkback) from the failing tests? Thanks Tim Alexei Zakharov wrote: Are you talking about HARMONY-910? I've applied it and MessageFormatTest is ok now (thanks, Richard!) But ChoiceFormatTest and DecimalFormatTest continue failing. 2006/7/18, Geir Magnusson Jr [EMAIL PROTECTED]: Read back to the [build] status thread I think that Richard has the fix done... Alexei Zakharov wrote: Nathan, SNIP -- Alexei Zakharov, Intel Middleware Product Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use :
Re: [build] status
Hello buildmasters,
One note: ant fetch-depends seem not to work behind proxy - it fails
after timeout. Adding proxy settings to depends.properties didn't
help.
The problem solved after I've added
setproxy proxyhost=${http.proxyHost} proxyport=${http.proxyPort}/
in the beginning of 'download' target in depends.xml
--
Regards,
Anton Luht,
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: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Andrew Zhang wrote:
Hi everyone,
I have one more question:
Which exception should be thrown whose error code is unused?
Let's consider native throwJavaNetSocketException quoted from nethelp.c:
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, java/net/SocketException);
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
There are only several error numbers need to be handled in javal classlib.
For most of them, throw java.net.SocketException is enough.
So shall we throw subclass of SocketException for several special error
codes or for all error codes? Suggestions?
Just the ones that need it.
What's the name of subclass of SocketException? Need your suggestions. :)
I never thought it should be a subclass anyway, so I'm not going to
suggest a name humpf :-)
sidebarever thought about stuffing the errno into a private/default
vis. variable on SocketException?/sidebar
Regards,
Tim
Thanks!
Best regards,
On 7/19/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi everyone,
If no one objects, I'd like to throw subclass of SocketException in
native
code to fix this problem. Any suggestions, please kindly let me know.
Thanks!
On 7/18/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Seems most people prefer subclass to SocketException with
ErrorCodeException cause.
Does anyone prefer the latter? or both are acceptable?
I think we'd better made an agreement about this issue.
Mikhail, how do you think about it? Which one do you prefer? :) I'll
fix
Harmony-815 once decision is made.
Thanks!
On 7/18/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
IMHO, throwing a subclass certainly fits to specification and can
hardly break compatibility with RI. I consider this is the proper
workaround for now.
Just my $0.02 :)
--
Alexey Varlamov
In this case, I guess if we set the cause to null when catching the
SocketException will properly solve the problem. However it seems
difficult as Throwable.initCause() can be called only once.
If throwing a subclass may also break compatibility guideline, I
still
suggest return value, though it may break the current
infrastructure(currently, all errors throw exception), it is still
easy
to deal with, only some of operation, read/write, require a little
change, and we no longer need try...catch in Java code
BTW, I find the code shall also deal with InterruptIOException.
-
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
--
Andrew Zhang
China Software Development Lab, IBM
--
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: [testing] locale dependent tests
Paulex Yang wrote: I still confuse what we want to test, the logic or the data? I think most (if not all) i18n related methods actually have same single executable with multiple resource bundles, i.e., the single executable should be locale-independent, the different return value is due to the resource data difference. I think at least for now, we should pay our attention to logic of single executable, and leave the data verification to the i18n libraries' author, say, ICU, they have much more knowledge and authority (at least than me) on this area. Agreed If we can get agree on the above, so the i18n related test cases organization are easier to judge: the logic is locale-independent, Ah, that is why I was trying to determine. If the logic is locale-independent then picking a locale to test with is ok; but it was unclear that was the case when changing locale caused assertion failures. so ideally the tests should be locale-independent, but we have some exceptional cases, say, the en_UK in MessageFormat case, Do you mean that in this case the logic /is/ locale dependent? I'm confused again g. so we cannot make our tests rely on the default locale, then we just specify one locale(en_US) to the tests, and supplement some exceptional case when we find some. i.e., I don't think we need ABC_en_US_Test, or so. Right, I don't think we need to have test_en_US blah, unless perhaps we pick one as the base for locale-dependent tests, otherwise we just run all tests in the machine default locale. 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] choose one [x-net] || [security] for HARMONY-536 (JSSE provider)
Geir Magnusson Jr wrote: I've asked Sun about this. It would be nice if people could re-use their root cert store. What format does IBM and BEA use? FWIW the IBM Java SDK passes through the Sun format JKS. Besides JKS there is also the BouncyCastle format (BKS) and a GNU keystore format. Take your pick. 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: [site] added roadmap/todo to the harmony site
Just to say, good stuff -- this is on my out-of-control 'must reply to' list. Tim Geir Magnusson Jr wrote: I took what we had in the roadmap thread and put on the site in the roadmap section. I also cobbled together a first cut at a 1 year timeline (very simple - classlib done by end of year, start testing then, expect 1 quarter testing, and then release) I will summarize the DRLVM part tomorrow and get that up there. I think then we can break out into sub-threads for the timelines (DRLVM and classlib) and go into more detail. I also added a buildtest section and a drlvm section (content into DRLVM tomorrow). We also need to augment the docunmentation section. - 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] choose one [x-net] || [security] for HARMONY-536 (JSSE provider)
Tim Ellison wrote: Geir Magnusson Jr wrote: I've asked Sun about this. It would be nice if people could re-use their root cert store. What format does IBM and BEA use? FWIW the IBM Java SDK passes through the Sun format JKS. Does passes through means it's able to use it? Besides JKS there is also the BouncyCastle format (BKS) and a GNU keystore format. Take your pick. Well, I was just thinking that if people already have cacerts w/ additions, they may want to drop them into place and use them w/o having to convert... 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]
[announce] Apache mail a bit behind, if you haven't noticed it..
Earlier this morning, 2.7M emails were generated by a wayward commit (in another project). This put the ASF delivery system into a bit of a backlog, which is why mail has been slow and weird today. Thanks for your patience. It's catching up, but there are a few hours left before normalcy. This may or may not come through quickly :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] hdk and jre for review...
I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony (I'm still battling windows...) The VM was built in release mode, and I have to say, it's not too shabby! If no one has any objections or showstoppers, I'd like to post both linux and win to our snapshot download site. As this is a snapshot, I'm looking for a basic smoketest or pointing any stupidity or gross mistakes I may have made. If not, I'd like to go forward, and just iterate. 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: [general] hdk and jre for review...
Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony I get a 404. -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] hdk and jre for review...
That's because I'm a moron and my userid is 'geirm' http://people.apache.org/~geirm/harmony I'm uploading windows versions now. Note they have no AWT/Swing support right now. geir Stefano Mazzocchi wrote: Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony I get a 404. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio]the conflict of RI and spec?
Anton Luht wrote:
Jimmy,
Please add readFile.delete() and writeFile.delete() in the end of test
or .deleteOnExit() in any place. Files created by createTempFile are
not cleaned up automatically.
Ah yes, sorry for that, thanks!
So temp files may not controlled by OS itself even they are in temp
directory of OS?
On 7/19/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Hi:
I find a conflict that RI does not behave as spec says in
java.nio.channels.FileChannel.transforFrom(ReadableByteChannel src,
long position,long count).
The spec says:...Fewer than the requested number of bytes will be
transferred if the source channel has fewer than count bytes
remaining...[1]. As expected, invoking this method with a count larger
than the number of bytes remaining in the ReadableByteChannel, RI should
return a number of bytes exactly transfered. But in fact, RI throws an
IOException. I run the test[2] on windowsXP SP2 with RI1.5.0_01 and
RI1.5.0_06, and on Linux(redhat 9) with RI1.5.0_02 and RI1.5.0_06, and
get the same result.
Currently Harmony behave well on this. I guess this is a bug of RI,
and Harmony implementation is good. If no objection, I suggest add this
test to Harmony.
Any opinions? Thanks!
[1] spec of FileChannel:
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html
[2] the test:
public void test_transferFromLReadableByteChannelJJ_overflow()
throws Exception {
String content = test content;
int length = content.length();
File readFile = File.createTempFile(testfile1, tmp);
File writeFile = File.createTempFile(testfile2, tmp);
FileOutputStream fos = new FileOutputStream(readFile);
try {
fos.write(content.getBytes());
} finally {
fos.close();
}
FileChannel fc1 = new FileInputStream(readFile).getChannel();
FileChannel fc2 = new FileOutputStream(writeFile).getChannel();
try {
long result = fc2.transferFrom(fc1, 0, length * 2);
assertEquals(length, result);
} finally {
fc1.close();
fc2.close();
}
}
--
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]
--
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]
[classlib][java.math] combination of math packages
Dear all, On behalf of ITC, I have submitted as H-935 a new implementation of java.math combining previously donated implementations. It includes what we think are the best features of H-380 (donated by Intel) and the best features of H-199 (donated by ITC). We have also fixed some bugs from both implementations and done some further optimizations on methods from both of them. We have also included a few optimizations from H-551, we expect to include the remaining optimizations soon. We have also improved the performance test suite from H-551 and included further tests, among them realistic applications from cryptography. Check the README file included in the package mathPerformanceTestsUpdate.zip (H-935) for some more details about the new features of the test suite. A sample of the output obtained with the performance test suite can be found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html A comparative analysis on a method-by-method basis between H-380 and H-199 can be found at http://www.fitc.unc.edu.ar/javadev/math/docs.html We will include further documentation soon. In the meantime, a brief description of the main issues follows: Internal representation of BigInteger: taken from H-380 (Sign-magnitude representation). Design: taken from H-199 (well-defined static libraries grouped by functionality). Serialization: taken from H-380 (it was not implemented in H-199). Most methods and constructors were taken from one of the previous donations and then tuned for consistency with the internal representation, for bug removal and for further optimizations. Very often large parts were reprogrammed (e.g.: shiftRight, bitLength, bitCount, not, setTrueCoded, modInverse, and many more). Nevertheless we can roughly say that the new version started by taking: 1) Methods of BigDecimal: most of them from H-199 because of efficiency. 2) Representation-dependent methods of BigInteger: most of them from H-380. 3) Representation-independent methods of BigInteger: most of them from H-199 for efficiency. 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf, BigDecimal.valueOf, etc. We also took their performance test suite, improve it and added further benchmarks. We plan to introduce remaining optimizations from H-551 and to optimize other methods (modPow, modInverse, nextProbablePrime, etc.) in order to bridge the gap in efficiency with the RI. Best regards, Daniel Fridlender ITC http://issues.apache.org/jira/browse/HARMONY-935 - 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] choose one [x-net] || [security] for HARMONY-536 (JSSE provider)
2006/7/21, Geir Magnusson Jr [EMAIL PROTECTED]: Tim Ellison wrote: Geir Magnusson Jr wrote: I've asked Sun about this. It would be nice if people could re-use their root cert store. What format does IBM and BEA use? FWIW the IBM Java SDK passes through the Sun format JKS. Does passes through means it's able to use it? Besides JKS there is also the BouncyCastle format (BKS) and a GNU keystore format. Take your pick. Well, I was just thinking that if people already have cacerts w/ additions, they may want to drop them into place and use them w/o having to convert... ...or we can make this conversion as easy as possible. I think we should learn our keytool doing it. BTW, can you please share some you think common scenarios people use when operate with certs? That would help us understand additional requirements for our keytool. Thanks, Mikhail geir Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][java.math] combination of math packages
cool! 2006/7/21, Daniel Fridlender [EMAIL PROTECTED]: Dear all, On behalf of ITC, I have submitted as H-935 a new implementation of java.math combining previously donated implementations. It includes what we think are the best features of H-380 (donated by Intel) and the best features of H-199 (donated by ITC). We have also fixed some bugs from both implementations and done some further optimizations on methods from both of them. We have also included a few optimizations from H-551, we expect to include the remaining optimizations soon. We have also improved the performance test suite from H-551 and included further tests, among them realistic applications from cryptography. Check the README file included in the package mathPerformanceTestsUpdate.zip (H-935) for some more details about the new features of the test suite. A sample of the output obtained with the performance test suite can be found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html A comparative analysis on a method-by-method basis between H-380 and H-199 can be found at http://www.fitc.unc.edu.ar/javadev/math/docs.html We will include further documentation soon. In the meantime, a brief description of the main issues follows: Internal representation of BigInteger: taken from H-380 (Sign-magnitude representation). Design: taken from H-199 (well-defined static libraries grouped by functionality). Serialization: taken from H-380 (it was not implemented in H-199). Most methods and constructors were taken from one of the previous donations and then tuned for consistency with the internal representation, for bug removal and for further optimizations. Very often large parts were reprogrammed (e.g.: shiftRight, bitLength, bitCount, not, setTrueCoded, modInverse, and many more). Nevertheless we can roughly say that the new version started by taking: 1) Methods of BigDecimal: most of them from H-199 because of efficiency. 2) Representation-dependent methods of BigInteger: most of them from H-380. 3) Representation-independent methods of BigInteger: most of them from H-199 for efficiency. 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf, BigDecimal.valueOf, etc. We also took their performance test suite, improve it and added further benchmarks. We plan to introduce remaining optimizations from H-551 and to optimize other methods (modPow, modInverse, nextProbablePrime, etc.) in order to bridge the gap in efficiency with the RI. Best regards, Daniel Fridlender ITC http://issues.apache.org/jira/browse/HARMONY-935 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] centralization of the NOTICE, COPYRIGHT, etc files
Geir, I have been working off and on with on putting together a contribution for this purpose. It has all the things you mentioned plus some more things. If you like, I would be glad to put it together shortly and submit for The List's inspection and approval. What do you say? Dan Lydick [Original Message] From: Geir Magnusson Jr [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 7/20/06 2:07:14 PM Subject: [general] centralization of the NOTICE, COPYRIGHT, etc files If you haven't guessed from my random checkins, questions, and befuddlement, I'm finishing off a first cut at a federated build. The plan is to cut a hdk and a jre snapshot. The HDK will contain the jre, but I thought it would be more conventional for users to get a plain jre and not have to figure out what a HDK is. Now, I want to coalesce the NOTICE, COPYRIGHT, 3rd party, etc files into one project-wide file in enhanced/trunk/ and replace the ones we have in classlib/, drlvm/ etc with a NOTICE, etc file that points to the root one. Any complaints, suggestions? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] centralization of the NOTICE, COPYRIGHT, etc files
Well, go for it! See what I have in there now and see what you think... geir bootjvm wrote: Geir, I have been working off and on with on putting together a contribution for this purpose. It has all the things you mentioned plus some more things. If you like, I would be glad to put it together shortly and submit for The List's inspection and approval. What do you say? Dan Lydick [Original Message] From: Geir Magnusson Jr [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 7/20/06 2:07:14 PM Subject: [general] centralization of the NOTICE, COPYRIGHT, etc files If you haven't guessed from my random checkins, questions, and befuddlement, I'm finishing off a first cut at a federated build. The plan is to cut a hdk and a jre snapshot. The HDK will contain the jre, but I thought it would be more conventional for users to get a plain jre and not have to figure out what a HDK is. Now, I want to coalesce the NOTICE, COPYRIGHT, 3rd party, etc files into one project-wide file in enhanced/trunk/ and replace the ones we have in classlib/, drlvm/ etc with a NOTICE, etc file that points to the root one. Any complaints, suggestions? 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][java.math] combination of math packages
Excellent. Maybe we can put this dual math thing to bed? Daniel Fridlender wrote: Dear all, On behalf of ITC, I have submitted as H-935 a new implementation of java.math combining previously donated implementations. It includes what we think are the best features of H-380 (donated by Intel) and the best features of H-199 (donated by ITC). We have also fixed some bugs from both implementations and done some further optimizations on methods from both of them. We have also included a few optimizations from H-551, we expect to include the remaining optimizations soon. We have also improved the performance test suite from H-551 and included further tests, among them realistic applications from cryptography. Check the README file included in the package mathPerformanceTestsUpdate.zip (H-935) for some more details about the new features of the test suite. A sample of the output obtained with the performance test suite can be found at http://www.fitc.unc.edu.ar/javadev/math/benchmarking.html A comparative analysis on a method-by-method basis between H-380 and H-199 can be found at http://www.fitc.unc.edu.ar/javadev/math/docs.html We will include further documentation soon. In the meantime, a brief description of the main issues follows: Internal representation of BigInteger: taken from H-380 (Sign-magnitude representation). Design: taken from H-199 (well-defined static libraries grouped by functionality). Serialization: taken from H-380 (it was not implemented in H-199). Most methods and constructors were taken from one of the previous donations and then tuned for consistency with the internal representation, for bug removal and for further optimizations. Very often large parts were reprogrammed (e.g.: shiftRight, bitLength, bitCount, not, setTrueCoded, modInverse, and many more). Nevertheless we can roughly say that the new version started by taking: 1) Methods of BigDecimal: most of them from H-199 because of efficiency. 2) Representation-dependent methods of BigInteger: most of them from H-380. 3) Representation-independent methods of BigInteger: most of them from H-199 for efficiency. 4) From H-551: caches, BigInteger.compareArrays, BigInteger.valueOf, BigDecimal.valueOf, etc. We also took their performance test suite, improve it and added further benchmarks. We plan to introduce remaining optimizations from H-551 and to optimize other methods (modPow, modInverse, nextProbablePrime, etc.) in order to bridge the gap in efficiency with the RI. Best regards, Daniel Fridlender ITC http://issues.apache.org/jira/browse/HARMONY-935 - 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] choose one [x-net] || [security] for HARMONY-536 (JSSE provider)
Mikhail Loenko wrote: 2006/7/21, Geir Magnusson Jr [EMAIL PROTECTED]: Tim Ellison wrote: Geir Magnusson Jr wrote: I've asked Sun about this. It would be nice if people could re-use their root cert store. What format does IBM and BEA use? FWIW the IBM Java SDK passes through the Sun format JKS. Does passes through means it's able to use it? Besides JKS there is also the BouncyCastle format (BKS) and a GNU keystore format. Take your pick. Well, I was just thinking that if people already have cacerts w/ additions, they may want to drop them into place and use them w/o having to convert... ...or we can make this conversion as easy as possible. I think we should learn our keytool doing it. BTW, can you please share some you think common scenarios people use when operate with certs? That would help us understand additional requirements for our keytool. Well, in my experience, I had to maintain a set of certs on my servers. But this is different - this is really about being able to let people reuse their root certs from vendor to vendor. I wonder why Sun chose a proprietary route... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Suggestion (was: Re: [jira] Closed: (HARMONY-932) [classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] , int, Integer.MAX_VALUE) throws NotYetConnectedException while RI throws IndexOutOf
Hi Vladimir,
I noticed the same problem is existing in many places of NIO module.
How about writing a utility function for array index exception check? like:
void assertArrayIndex(Object[] array, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length array.length
){
throw new IndexOutOfBoundsException();
}
}
How do you think about it? Any suggestions?
Thanks!
Best regards,
On 7/21/06, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-932?page=all ]
Paulex Yang closed HARMONY-932.
---
Estimated Complexity: Novice
Verified by Vladimir.
[classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] , int,
Integer.MAX_VALUE) throws NotYetConnectedException while RI throws
IndexOutOfBoundsException
-
Key: HARMONY-932
URL: http://issues.apache.org/jira/browse/HARMONY-932
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
Assigned To: Paulex Yang
Attachments: DatagramChannelImpl.patch
The Harmony methods java.nio.?hannel.DatagramChannel.read/write(ByteBuffer[]
, int, Integer.MAX_VALUE) throws NotYetConnectedException while RI throws
IndexOutOfBoundsException.
test.java ==
import java.nio.channels.*;
import java.nio.*;
public class test {
public static void main (String[] args) {
try {
DatagramChannel.open().read(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
try {
DatagramChannel.open().write(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
}
}
=
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -cp . -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.read(DatagramChannelImpl.java
:366)
at test.main(test.java:8)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.write(DatagramChannelImpl.java
:429)
at test.main(test.java:13)
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp .
-showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
OutOfMemoryError
---end of stacktrace
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -cp .
-showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors, as applicable.
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.read(
DatagramChannelImpl.java:387)
at test.main(test.java:8)
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.write(
DatagramChannelImpl.java:477)
at test.main(test.java:13)
C:\tmp\tmp17C:\harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\ij
-Dvm.assert_dialog=false -cp . -showversion test
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc 1310,
debug
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.read(
DatagramChannelImpl.java:387)
at test.main(test.java:8)
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.write(
DatagramChannelImpl.java:477)
at test.main(test.java:13)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Andrew Zhang
China Software Development Lab, IBM
Re: Suggestion (was: Re: [jira] Closed: (HARMONY-932) [classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] , int, Integer.MAX_VALUE) throws NotYetConnectedException while RI throws IndexO
Seems, the same problem is existing not in NIO module only. In any case, it
will be useful to use one method instead of many copies of code. That's for
me, I just can't find the appropriate class for 'package' functions so fix
it inline.
Seems, the function like:
void assertArrayIndex(int arrayLength, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length
arrayLength){
throw new IndexOutOfBoundsException();
}
}
or may be even something like that
void assertArrayIndex(int arrayLength, int offset, int length){
if (offset 0)
throw new IndexOutOfBoundsException(Negative offset);
if (length 0) throw new
IndexOutOfBoundsException(Negative length);
if ((long)offset + (long)length arrayLength)
throw new IndexOutOfBoundsException(offset+length exceed buffer
size);
}
Thanks, Vladimir
On 7/21/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi Vladimir,
I noticed the same problem is existing in many places of NIO module.
How about writing a utility function for array index exception check?
like:
void assertArrayIndex(Object[] array, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length array.length
){
throw new IndexOutOfBoundsException();
}
}
How do you think about it? Any suggestions?
Thanks!
Best regards,
On 7/21/06, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-932?page=all ]
Paulex Yang closed HARMONY-932.
---
Estimated Complexity: Novice
Verified by Vladimir.
[classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] ,
int,
Integer.MAX_VALUE) throws NotYetConnectedException while RI throws
IndexOutOfBoundsException
-
Key: HARMONY-932
URL: http://issues.apache.org/jira/browse/HARMONY-932
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
Assigned To: Paulex Yang
Attachments: DatagramChannelImpl.patch
The Harmony methods java.nio.?hannel.DatagramChannel.read/write
(ByteBuffer[]
, int, Integer.MAX_VALUE) throws NotYetConnectedException while RI
throws
IndexOutOfBoundsException.
test.java ==
import java.nio.channels.*;
import java.nio.*;
public class test {
public static void main (String[] args) {
try {
DatagramChannel.open().read(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
try {
DatagramChannel.open().write(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
}
}
=
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -cp . -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.read(
DatagramChannelImpl.java
:366)
at test.main(test.java:8)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.write(
DatagramChannelImpl.java
:429)
at test.main(test.java:13)
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp .
-showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
OutOfMemoryError
---end of stacktrace
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -cp .
-showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors, as applicable.
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.read(
DatagramChannelImpl.java:387)
at test.main(test.java:8)
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.write(
DatagramChannelImpl.java:477)
at test.main(test.java:13)
C:\tmp\tmp17C:\harmony\drlvm\trunk\build\win_ia32_msvc_debug\deploy\jre\bin\ij
-Dvm.assert_dialog=false -cp . -showversion test
Apache Harmony DRLVM HEAD-4807 (2006-05-02), Windows/ia32/msvc
RE: [general] hdk and jre for review...
I think you may need to chmod the windows snapshots. All I get are forbidden responses and the files aren't globally readable in SFTP. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 7:22 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] hdk and jre for review... That's because I'm a moron and my userid is 'geirm' http://people.apache.org/~geirm/harmony I'm uploading windows versions now. Note they have no AWT/Swing support right now. geir Stefano Mazzocchi wrote: Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony I get a 404. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] hdk and jre for review...
-Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:17 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [general] hdk and jre for review... I think you may need to chmod the windows snapshots. All I get are forbidden responses and the files aren't globally readable in SFTP. forbidden responses? SFTP? -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 7:22 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] hdk and jre for review... That's because I'm a moron and my userid is 'geirm' http://people.apache.org/~geirm/harmony I'm uploading windows versions now. Note they have no AWT/Swing support right now. geir Stefano Mazzocchi wrote: Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony I get a 404. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] hdk and jre for review...
2006/7/21, Magnusson, Geir [EMAIL PROTECTED]: -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:17 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [general] hdk and jre for review... I think you may need to chmod the windows snapshots. All I get are forbidden responses and the files aren't globally readable in SFTP. forbidden responses? SFTP? Dunno about sftp, but http gives the following response: Forbidden You don't have permission to access /~geirm/harmony/incubator-harmony-hdk-r424020-windows-x86-snapshot.zip on this server. -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] hdk and jre for review...
Thanks - fixed. Please verify I thought he meant the chmod-like setting *inside* the zip. Geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:28 AM To: harmony-dev@incubator.apache.org Subject: Re: [general] hdk and jre for review... 2006/7/21, Magnusson, Geir [EMAIL PROTECTED]: -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:17 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [general] hdk and jre for review... I think you may need to chmod the windows snapshots. All I get are forbidden responses and the files aren't globally readable in SFTP. forbidden responses? SFTP? Dunno about sftp, but http gives the following response: Forbidden You don't have permission to access /~geirm/harmony/incubator-harmony-hdk-r424020-windows-x86-snapshot.zip on this server. -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] hdk and jre for review...
-Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 11:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [general] hdk and jre for review... -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:17 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [general] hdk and jre for review... I think you may need to chmod the windows snapshots. All I get are forbidden responses and the files aren't globally readable in SFTP. forbidden responses? SFTP? HTTP 403 - Forbidden SFTP - ssh ftp - FileZilla is my friend I connected to the server with FileZill and looked at the files, all of the windows and hash files have permissions set to rwx-- and the linux files are set to rwxr--r--. HTTPD honors the file system's restrictions. -Nathan -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 7:22 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] hdk and jre for review... That's because I'm a moron and my userid is 'geirm' http://people.apache.org/~geirm/harmony I'm uploading windows versions now. Note they have no AWT/Swing support right now. geir Stefano Mazzocchi wrote: Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony I get a 404. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] hdk and jre for review...
Verified. -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] hdk and jre for review...
I fixed. Try now -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:35 AM To: harmony-dev@incubator.apache.org Subject: RE: [general] hdk and jre for review... -Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 11:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [general] hdk and jre for review... -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:17 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [general] hdk and jre for review... I think you may need to chmod the windows snapshots. All I get are forbidden responses and the files aren't globally readable in SFTP. forbidden responses? SFTP? HTTP 403 - Forbidden SFTP - ssh ftp - FileZilla is my friend I connected to the server with FileZill and looked at the files, all of the windows and hash files have permissions set to rwx-- and the linux files are set to rwxr--r--. HTTPD honors the file system's restrictions. -Nathan -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 7:22 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] hdk and jre for review... That's because I'm a moron and my userid is 'geirm' http://people.apache.org/~geirm/harmony I'm uploading windows versions now. Note they have no AWT/Swing support right now. geir Stefano Mazzocchi wrote: Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony I get a 404. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] hdk and jre for review...
I can download it now and just about to do some smoke tests, but I noticed that the windows JRE zip contains the entire HDK build and seems to be exactly like the HDK zip. -Nathan -Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 11:39 PM To: harmony-dev@incubator.apache.org Subject: RE: [general] hdk and jre for review... I fixed. Try now -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:35 AM To: harmony-dev@incubator.apache.org Subject: RE: [general] hdk and jre for review... -Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 11:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [general] hdk and jre for review... -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:17 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [general] hdk and jre for review... I think you may need to chmod the windows snapshots. All I get are forbidden responses and the files aren't globally readable in SFTP. forbidden responses? SFTP? HTTP 403 - Forbidden SFTP - ssh ftp - FileZilla is my friend I connected to the server with FileZill and looked at the files, all of the windows and hash files have permissions set to rwx-- and the linux files are set to rwxr--r--. HTTPD honors the file system's restrictions. -Nathan -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 7:22 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] hdk and jre for review... That's because I'm a moron and my userid is 'geirm' http://people.apache.org/~geirm/harmony I'm uploading windows versions now. Note they have no AWT/Swing support right now. geir Stefano Mazzocchi wrote: Geir Magnusson Jr wrote: I have a HDK and JRE for linux on http://people.apache.org/~geir/harmony I get a 404. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] hdk and jre for review...
I tried running Eclipse 3.2 on the Windows JRE build and it launches the splash screen and the workspace selection dialog, but after you click ok, it pukes and spits out the following to standard error. ERROR: Destructive unwinding: C++ objects detected on stack! droping 0x05BDF430 setting curr 0x05BDFF68 The Eclipse log is full of message about not being able to load certain classes. Here's the first exception stack trace. Also note the 'java.version' and 'java.vendor'; I presume we'll need to change those eventually. !SESSION 2006-07-21 00:00:08.362 --- eclipse.buildId=M20060629-1905 java.version=11.2.0 java.vendor=Intel DRL BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US !ENTRY org.eclipse.osgi 4 0 2006-07-21 00:00:09.153 !MESSAGE An error occurred while automatically activating bundle org.eclipse.core.runtime.compatibility (25). !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.plugins.CompatibilityActivator.start() of bundle org.eclipse.core.runtime.compatibility. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(Bu ndleContextImpl.java:1014) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleConte xtImpl.java:970) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.j ava:317) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle .java:256) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.preFindLocalCla ss(EclipseLazyStarter.java:86) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(Classpat hManager.java:409) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(Defa ultClassLoader.java:188) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleL oader.java:339) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader .java:391) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader .java:352) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultCl assLoader.java:83) at java.lang.ClassLoader.loadClass() at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader .java:276) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.jav a:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBu ndle.java:1245) at org.eclipse.core.internal.runtime.CompatibilityHelper.getPluginDescriptor(Co mpatibilityHelper.java:63) at org.eclipse.core.runtime.Plugin.initializeDescriptor(Plugin.java:706) at org.eclipse.core.runtime.Plugin.start(Plugin.java:692) at org.eclipse.core.internal.runtime.PlatformActivator.start(PlatformActivator. java:39) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleConte xtImpl.java:995) at java.security.AccessController.doPrivilegedImpl() at java.security.AccessController.doPrivileged() at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(Bu ndleContextImpl.java:989) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleConte xtImpl.java:970) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.j ava:317) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundl e.java:329) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.ja va:1037) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(Sta rtLevelManager.java:573) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLeve lManager.java:495) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(S tartLevelManager.java:275) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(Sta rtLevelManager.java:455) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager. java:189) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManage r.java:291) Caused by: java.lang.NoClassDefFoundError: org/eclipse/core/runtime/Plugin at java.lang.reflect.VMReflection.getMethodReturnType() at java.lang.reflect.Method$MethodData.initReturnType() at java.lang.reflect.Method.getReturnType() at java.lang.Class$ReflectionData.isMethodMatches() at java.lang.Class$ReflectionData.mergeMethods() at java.lang.Class$ReflectionData.initPublicMethods() at java.lang.Class.getMethod() at org.eclipse.core.internal.runtime.CompatibilityHelper.setPlugin(Compatibilit yHelper.java:48) at org.eclipse.core.internal.plugins.CompatibilityActivator.start(Compatibility
Re: Suggestion (was: Re: [jira] Closed: (HARMONY-932) [classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] , int, Integer.MAX_VALUE) throws NotYetConnectedException while RI throws IndexO
Hi everybody,
How about placing these methods in utli.java in o.a.h.module.util package?
Best regards,
Andrew
On 7/21/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
Seems, the same problem is existing not in NIO module only. In any case,
it
will be useful to use one method instead of many copies of code. That's
for
me, I just can't find the appropriate class for 'package' functions so fix
it inline.
Seems, the function like:
void assertArrayIndex(int arrayLength, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length
arrayLength){
throw new IndexOutOfBoundsException();
}
}
or may be even something like that
void assertArrayIndex(int arrayLength, int offset, int length){
if (offset 0)
throw new IndexOutOfBoundsException(Negative offset);
if (length 0) throw new
IndexOutOfBoundsException(Negative length);
if ((long)offset + (long)length arrayLength)
throw new IndexOutOfBoundsException(offset+length exceed
buffer
size);
}
Thanks, Vladimir
On 7/21/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi Vladimir,
I noticed the same problem is existing in many places of NIO module.
How about writing a utility function for array index exception check?
like:
void assertArrayIndex(Object[] array, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length
array.length
){
throw new IndexOutOfBoundsException();
}
}
How do you think about it? Any suggestions?
Thanks!
Best regards,
On 7/21/06, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-932?page=all ]
Paulex Yang closed HARMONY-932.
---
Estimated Complexity: Novice
Verified by Vladimir.
[classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] ,
int,
Integer.MAX_VALUE) throws NotYetConnectedException while RI throws
IndexOutOfBoundsException
-
Key: HARMONY-932
URL:
http://issues.apache.org/jira/browse/HARMONY-932
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
Assigned To: Paulex Yang
Attachments: DatagramChannelImpl.patch
The Harmony methods java.nio.?hannel.DatagramChannel.read/write
(ByteBuffer[]
, int, Integer.MAX_VALUE) throws NotYetConnectedException while RI
throws
IndexOutOfBoundsException.
test.java ==
import java.nio.channels.*;
import java.nio.*;
public class test {
public static void main (String[] args) {
try {
DatagramChannel.open().read(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
try {
DatagramChannel.open().write(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
}
}
=
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -cp . -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05
)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.read(
DatagramChannelImpl.java
:366)
at test.main(test.java:8)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.write(
DatagramChannelImpl.java
:429)
at test.main(test.java:13)
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp .
-showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
OutOfMemoryError
---end of stacktrace
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -cp .
-showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors, as applicable.
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected
(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.read(
DatagramChannelImpl.java:387)
at test.main(test.java:8)
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected
(
DatagramChannelImpl.java:567)
at
Re: Suggestion (was: Re: [jira] Closed: (HARMONY-932) [classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] , int, Integer.MAX_VALUE) throws NotYetConnectedException while RI throws IndexO
On 7/21/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
Seems, the same problem is existing not in NIO module only. In any case,
it
will be useful to use one method instead of many copies of code. That's
for
me, I just can't find the appropriate class for 'package' functions so fix
it inline.
Seems, the function like:
void assertArrayIndex(int arrayLength, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length
arrayLength){
throw new IndexOutOfBoundsException();
}
}
or may be even something like that
void assertArrayIndex(int arrayLength, int offset, int length){
if (offset 0)
throw new IndexOutOfBoundsException(Negative offset);
if (length 0) throw new
IndexOutOfBoundsException(Negative length);
if ((long)offset + (long)length arrayLength)
throw new IndexOutOfBoundsException(offset+length exceed
buffer
size);
}
Hi Vladimir, I have some comments on your revised method. :)
Using int as the first parameter will cause problem. Consider:
Invoking assertArray(array.length, 0, -1) will throw NullPointerException
instead of IndexOutOfBoundException. It's not compatible with RI.
Do you think so?
Thanks!
Thanks, Vladimir
On 7/21/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi Vladimir,
I noticed the same problem is existing in many places of NIO module.
How about writing a utility function for array index exception check?
like:
void assertArrayIndex(Object[] array, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length
array.length
){
throw new IndexOutOfBoundsException();
}
}
How do you think about it? Any suggestions?
Thanks!
Best regards,
On 7/21/06, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-932?page=all ]
Paulex Yang closed HARMONY-932.
---
Estimated Complexity: Novice
Verified by Vladimir.
[classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] ,
int,
Integer.MAX_VALUE) throws NotYetConnectedException while RI throws
IndexOutOfBoundsException
-
Key: HARMONY-932
URL:
http://issues.apache.org/jira/browse/HARMONY-932
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
Assigned To: Paulex Yang
Attachments: DatagramChannelImpl.patch
The Harmony methods java.nio.?hannel.DatagramChannel.read/write
(ByteBuffer[]
, int, Integer.MAX_VALUE) throws NotYetConnectedException while RI
throws
IndexOutOfBoundsException.
test.java ==
import java.nio.channels.*;
import java.nio.*;
public class test {
public static void main (String[] args) {
try {
DatagramChannel.open().read(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
try {
DatagramChannel.open().write(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
}
}
=
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -cp . -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05
)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.read(
DatagramChannelImpl.java
:366)
at test.main(test.java:8)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.write(
DatagramChannelImpl.java
:429)
at test.main(test.java:13)
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp .
-showversion test
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
OutOfMemoryError
---end of stacktrace
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -cp .
-showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors, as applicable.
java.nio.channels.NotYetConnectedException
at
org.apache.harmony.nio.internal.DatagramChannelImpl.checkOpenConnected
(
DatagramChannelImpl.java:567)
at org.apache.harmony.nio.internal.DatagramChannelImpl.read(
DatagramChannelImpl.java:387)
at test.main(test.java:8)
java.nio.channels.NotYetConnectedException
Re: [general] hdk and jre for review...
On windows, I was able to launch Eclipse 3.1.1 sucessfully, edit and run HWA. Did just one correction :) Index: harmony-hdk-r424020\jdk\jre\bin\eclipse.bat @@ -4,1 +4,1 - set BUILD_HOME=C:\dev\apache\harmony\enhanced\trunk\working_vm\build\win_ia32_msvc_release\deploy\jre + set BUILD_HOME=%~dp0\..\ On Suse 9 box (gcc 3.3.3), though, it complained: ./java.exec: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion (was: Re: [jira] Closed: (HARMONY-932) [classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[] , int, Integer.MAX_VALUE) throws NotYetConnectedException while RI throws IndexO
On 7/21/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Invoking assertArray(array.length, 0, -1) will throw NullPointerException
instead of IndexOutOfBoundException. It's not compatible with RI.
Do you think so?
No. We should check reference before using :) To corectly process a NPE we
should write:
method m(Object[] array, int offset, int length) {
if (array == null)
throw new NullPointerException();
assertArrayIndex(array.length, offset, length);
..
}
or write something like
void assertArrayIndex(Object[] array, int offset, int length){
if (array == null)
throw new NullPointerException();
if (offset 0)
throw new IndexOutOfBoundsException(Negative offset);
if (length 0)
throw new IndexOutOfBoundsException(Negative length);
if ((long)offset + (long)length array.length)
throw new IndexOutOfBoundsException(offset+length exceed buffer
size);
}
thanks, Vladimir
On 7/21/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 7/21/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
Seems, the same problem is existing not in NIO module only. In any case,
it
will be useful to use one method instead of many copies of code. That's
for
me, I just can't find the appropriate class for 'package' functions so
fix
it inline.
Seems, the function like:
void assertArrayIndex(int arrayLength, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length
arrayLength){
throw new IndexOutOfBoundsException();
}
}
or may be even something like that
void assertArrayIndex(int arrayLength, int offset, int length){
if (offset 0)
throw new IndexOutOfBoundsException(Negative offset);
if (length 0) throw new
IndexOutOfBoundsException(Negative length);
if ((long)offset + (long)length arrayLength)
throw new IndexOutOfBoundsException(offset+length exceed
buffer
size);
}
Hi Vladimir, I have some comments on your revised method. :)
Using int as the first parameter will cause problem. Consider:
Invoking assertArray(array.length, 0, -1) will throw NullPointerException
instead of IndexOutOfBoundException. It's not compatible with RI.
Do you think so?
Thanks!
Thanks, Vladimir
On 7/21/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi Vladimir,
I noticed the same problem is existing in many places of NIO module.
How about writing a utility function for array index exception check?
like:
void assertArrayIndex(Object[] array, int offset, int length){
if(offset 0 || length 0 || (long)offset + (long)length
array.length
){
throw new IndexOutOfBoundsException();
}
}
How do you think about it? Any suggestions?
Thanks!
Best regards,
On 7/21/06, Paulex Yang (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-932?page=all ]
Paulex Yang closed HARMONY-932.
---
Estimated Complexity: Novice
Verified by Vladimir.
[classlib][nio]java.nio.?hannel.DatagramChannel.read(ByteBuffer[]
,
int,
Integer.MAX_VALUE) throws NotYetConnectedException while RI throws
IndexOutOfBoundsException
-
Key: HARMONY-932
URL:
http://issues.apache.org/jira/browse/HARMONY-932
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
Assigned To: Paulex Yang
Attachments: DatagramChannelImpl.patch
The Harmony methods java.nio.?hannel.DatagramChannel.read/write
(ByteBuffer[]
, int, Integer.MAX_VALUE) throws NotYetConnectedException while RI
throws
IndexOutOfBoundsException.
test.java ==
import java.nio.channels.*;
import java.nio.*;
public class test {
public static void main (String[] args) {
try {
DatagramChannel.open().read(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
try {
DatagramChannel.open().write(new ByteBuffer[] {}, 2,
Integer.MAX_VALUE);
} catch (Exception e) {
e.printStackTrace();
}
}
}
=
Output:
C:\tmp\tmp17C:\jdk1.5.0_06\bin\java.exe -cp . -showversion test
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0_06-b05
)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
java.lang.IndexOutOfBoundsException
at sun.nio.ch.DatagramChannelImpl.read(
DatagramChannelImpl.java
:366)
at
