[classlib][String] Request for fixing bug in String(byte[] bytes, int offset, int length, String charsetName)
Hello All,
The constructor String(byte[] bytes, int offset, int length, String
charsetName) has the same bug as Harmony-487[1]. When the charsetName
is , RI throws UnsupportedEncodingException, but Harmony throws
IllegalCharsetNameException.
If there is no objection, I will raise a JIRA and provide a patch for
this issue. Thanks a lot.
The following test passes on RI, but fails on Harmony:
try {
String str = new String(new byte[] {0x41, 0x42}, 0, 2, );
fail(Should throw UnsupportedEncodingException);
} catch (UnsupportedEncodingException e) {
//expected
}
[1]http://issues.apache.org/jira/browse/HARMONY-487
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new files to SVN and subsequently trying to update
I wrote a perl script to deal with these things: 1. check svn status on some directory 2. execute svn add if necessary 3. execute svn diff to create diff file 4. create a shell script with svn add/remove instructions, which is useful for the committer to apply the patch 5. revert to original status It doesn't remove/rename the new files, but the extension should be straightforward. If anyone has interest, I'm glad to contribute, but believe that, I'm a newbie of perl... Oliver Deakin wrote: I use TortoiseSVN also - I just tested it out by creating a dummy modules\tools\src\main\java\org\apache\harmony\tools\keytool\KeyCertGenerator.java file and trying to update to pick up Mikhails latest changes (which add this file to the repository). Unfortunately TortoiseSVN gives me an error stating object of the same name already exists. If I delete the file and then try to update, I get another error stating object of the same name is already scheduled for addition, so it looks like I still have to revert before the update, even with TortoiseSVN. Regards, Oliver Alexei Zakharov wrote: I use graphical TortoiseSVN client and do not remember much pain with file addition. It seems TortoiseSVN does some part of the stupid job by itself. I believe there should be something like it on *NIX too. Regards, 2006/8/10, Oliver Deakin [EMAIL PROTECTED]: Alex Blewitt wrote: Yeah ... the problem is that unless you do an 'svn add', it doesn't show up when you have an 'svn patch' or similar (see other swearing, ranting etc. about missing files). So, I've got to add, patch, submit, wait, hack/revert, diff each new file I add ... Yeah, if you want the file to appear in the patch, then you've got to add it. Then once you do that you can't update, ugh! I guess you could not do the svn add and just attach the files to the JIRA along with the patch and describe where they should go, but this takes more effort on the part of the committer to put them in the right place and is open to mistakes when writing down the path locations of the files (which can be pretty long in Harmony!). The big problem (for me) is that it effectively means once I've added a new file, I really can't do any new work on it until it's been added, since otherwise any changes I make between filing the patch and having a clean 'svn up' (which I have just got to -- hooray!) are almost certain to be lost in the process. In turn, it means that there's much less of a benefit to me submitting code in smaller chunks, and I might as well just sit on it until I've developed a huge wodge of changes and send them in one go. If you are following the add, create patch, revert, delete, update, diff cycle, then at least you can transfer new changes to the svn versioned file during the diff stage, so you should be able to continue working on the newly added file (even if it is a hassle every time you have to update). I would be great if svn would recognise that the added file in the repo was the same as the one added on your disk and attempt to merge them. There must be someone out there who knows a better way to do this? Regards, Oliver Mind you, it's not like we're working against a deadline here, and I'm happy taking a few days off from thinking about it ... but I'll plan where my breaks are better in terms of functionalitiy in the future. (Any SVN developers on this list want to help figure out how to make this better?) Alex. On 10/08/06, Oliver Deakin [EMAIL PROTECTED] wrote: Just sent my other mail before seeing this one. Rather than manually editing the entries file you can, as I suggest in the other mail, still revert the original file name after you have moved it to a new file. So you could: - move the file to a new name AddedFile.java.bak - svn revert AddedFile.java (this should still work even tho the file is no longer there) - svn up - compare AddedFile.java and AddedFile.java.bak - swear etc. Hope this helps, Oliver Alex Blewitt wrote: OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like entry name=AddedFile.java kind=file schedule=add revision=0/ then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first
[classlib][luni] junit4.0 fails on harmony due to missing method(s)
Could someone of the fellow comitters kindly apply the HARMONY-1152 patch, it is needed to use junit4.0: java -cp .:junit-4.0.jar org.junit.runner.JUnitCore org.junit.tests.AllTests JUnit version 4.0 Exception in thread main java.lang.NoSuchMethodError: java/lang/String.format(Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String; at org.junit.runner.Description.createTestDescription(Description.java:39) at org.junit.internal.runners.TestClassMethodsRunner.methodDescription(TestClassMethodsRunner.java:83) at org.junit.internal.runners.TestClassMethodsRunner.getDescription(TestClassMethodsRunner.java:51) at org.junit.internal.runners.TestClassRunner.getDescription(TestClassRunner.java:57) at org.junit.internal.runners.CompositeRunner.getDescription(CompositeRunner.java:36) at org.junit.internal.runners.TestClassRunner.getDescription(TestClassRunner.java:57) at org.junit.internal.runners.CompositeRunner.getDescription(CompositeRunner.java:36) at org.junit.runner.JUnitCore.run(JUnitCore.java:120) at org.junit.runner.JUnitCore.run(JUnitCore.java:10) at org.junit.runner.JUnitCore.run(JUnitCore.java:91) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:75) at org.junit.runner.JUnitCore.main(JUnitCore.java:42) -- 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: RE: [classlib][suncompat] created
I think the @deprecated is a good idea, but I strongly believe that we should *not* have this as a default. There's an easy workaround for the subset of applications that need it (e.g. enable it in the .properties file) whilst still preventing new code from being able to reference it. A simple FAQ should be enough to help people do this. Mind you, I seem to be in the minority on this view on this list :-) Alex. On 11/08/06, Nathan Beyer [EMAIL PROTECTED] wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][suncompat] created Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. geir Alex Blewitt wrote: Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Alex Blewitt wrote: OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Re: Re: Re: Re: Re: [classlib][pack200] Status update
Done in 430723 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Only one problem I've found so far (possibly because it was in an earlier patch but not subsequent ones) -- the src/test/java/org/apache/harmony/archive/tests/AllTests.java doesn't have a suite.addTest(org.apache.harmony.archive.tests.internal.pack200.AllTests.suite()); in it. Can you add that, or do you want me to send a patch? (Mind you, with my record of submitting patches, I'm not sure that's such a good idea ;-) Alex. On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Finally it's in! :) 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Don't you just hate it when that happens? :-) On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've found this file in http://issues.apache.org/jira/browse/HARMONY-634 Tim decisded not to commit it as it was not used at the moment I'll check if it solves the problem Thanks, Mikhail 2006/8/10, Mikhail Loenko [EMAIL PROTECTED]: The test still fails. I have not found any file named JustResources* in SVN. The only pack file I've found is HelloWorld.pack Do you remember who has added a JustResources there? Was it a JIRA issue reported by you? Thanks, Mikhail 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Bizzare. I moved it, but it didn't get added. Or at least, I think so. I did discover why the file wasn't included though at my end ... it wasn't part of the change set, so wasn't included in the patch. I've re-generated the patch with it in this time and attached to Harmony-1019 ... is that any better? Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: I believe that the JustResources.pack file was moved to a different location, and so the test was updated to reflect that new location. I saw the same problem myself ... can you confirm that there is a file in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I think that's where the segment ended up. I didn't actually move the file ... someone else did IIRC. Alex. On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: One more problem caused by the patch: java.lang.NullPointerException at org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Thanks, Mikhail 2006/8/10, Mikhail Loenko [EMAIL PROTECTED]: PopulationCodecTest is missing, but there are other new files in the patch. You can see all of them if open the patch with a text editor and seek for (revision 0) substring Thanks, Mikhail 2006/8/9, Alex Blewitt [EMAIL PROTECTED]: Weird. I don't know what happened. I've attached PopulationCodec (a new file) separately to the bug report. There's also BHSDCodec, which is new in the patch, as well as PopulationCodecTest. Are they there too? Alex. On 08/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Alex Thanks for the patch! I have a problem with integration: this classes org.apache.harmony.archive.internal.pack200.CodecEncoding refers to the PopulationCodec class that seems to be missing I'm trying to apply 'patch' [1]. Am I doing anything wrong? Thanks, Mikhail [1] http://issues.apache.org/jira/secure/attachment/12338321/patch 2006/8/8, Alex Blewitt [EMAIL PROTECTED]: I've been getting further towards the Pack200 implementation with finishing off the codecs that are used to decode values from the file. Although most of the default codecs were in place, the pack200 spec allows for dynamic switching to arbitrary codecs should the compressor warrant it, including a population-based encoding for (in)frequent values. I've submitted Harmony 1019 with the patch; if someone could apply that, I'd be grateful. At present, the pack200 algorithm gets as far as the inner class definitions, but I've still got to decode the annotations and bytecode. I'm thinking that as a first-cut, I will ignore any pack files with annotations in and plough through the bytecode so that we can at least start using it for simple pack files.
RE: [general] platform support
Rana, SetUnhandledExceptionFilter [1] is documented function which is available since Windows 95. It is part of the Structured Exception Handling. Windows XP introduced the Vectored Exception Handling which is an extension of SEH according to MSDN. Using this function and therefore SEH (but not VEH) mechanism requires you to guard each call with __try/__except as Gregory and Oleg pointed out. I'm not proficient in this kind of rather low-level Windows API though, so I might be wrong. Regards, Alexey. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b ase/setunhandledexceptionfilter.asp -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Rana Dasgupta [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 9:51 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] platform support Hi Mikhail, As far as I know, SetUnhandledExceptionFilter was introduced as a backdoor method in in Win2K SP4 to get around the problem that the SEH handlers are limited to the frame and not process wide. It does handle problems like NPE and AV, but as you point out, it works by hijacking the first and last chance debugger handlers. So, unlike VEH which are fully functional when debugging, these SetUnhandled...filters are not visible when debugging. I also believe that they execute in the context of the current thread, which means that they are not so good to handle stack corruption, SOE etc. which we are currently using VEH. Since one does not expect them to be used on the newer Windows boxes, the .Net framework overwrites them ...which means that any process that loads a Microsoft dll that has any Microsoft managed code in it ( and many do ), is at a risk that the SetUnhandled.. may or may not work. I think that SetUnhandled..was a great(probably only ) solution on the Win2K boxes, but VEH was put in place to solve some of its limitations. The bottom line is that one needs to experiment with this on several Windows boxes before we know how good or bad it is. I myself don't have a lot of experience with it. Thanks, Rana On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: **Using SetUnhandledExceptionFilter API call we can handle hardware NPE for Win2k too. The only problem is debbuging of applications with exception filter installed. AFAIK debugger will catch all of these events. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new files to SVN and subsequently trying to update
Hi, I did not say that it solves all problems, but at least you do not need to do svn add each time you add a new file and want to create a patch. Regards, 2006/8/10, Oliver Deakin [EMAIL PROTECTED]: I use TortoiseSVN also - I just tested it out by creating a dummy modules\tools\src\main\java\org\apache\harmony\tools\keytool\KeyCertGenerator.java file and trying to update to pick up Mikhails latest changes (which add this file to the repository). Unfortunately TortoiseSVN gives me an error stating object of the same name already exists. If I delete the file and then try to update, I get another error stating object of the same name is already scheduled for addition, so it looks like I still have to revert before the update, even with TortoiseSVN. Regards, Oliver Alexei Zakharov wrote: I use graphical TortoiseSVN client and do not remember much pain with file addition. It seems TortoiseSVN does some part of the stupid job by itself. I believe there should be something like it on *NIX too. Regards, 2006/8/10, Oliver Deakin [EMAIL PROTECTED]: Alex Blewitt wrote: Yeah ... the problem is that unless you do an 'svn add', it doesn't show up when you have an 'svn patch' or similar (see other swearing, ranting etc. about missing files). So, I've got to add, patch, submit, wait, hack/revert, diff each new file I add ... Yeah, if you want the file to appear in the patch, then you've got to add it. Then once you do that you can't update, ugh! I guess you could not do the svn add and just attach the files to the JIRA along with the patch and describe where they should go, but this takes more effort on the part of the committer to put them in the right place and is open to mistakes when writing down the path locations of the files (which can be pretty long in Harmony!). The big problem (for me) is that it effectively means once I've added a new file, I really can't do any new work on it until it's been added, since otherwise any changes I make between filing the patch and having a clean 'svn up' (which I have just got to -- hooray!) are almost certain to be lost in the process. In turn, it means that there's much less of a benefit to me submitting code in smaller chunks, and I might as well just sit on it until I've developed a huge wodge of changes and send them in one go. If you are following the add, create patch, revert, delete, update, diff cycle, then at least you can transfer new changes to the svn versioned file during the diff stage, so you should be able to continue working on the newly added file (even if it is a hassle every time you have to update). I would be great if svn would recognise that the added file in the repo was the same as the one added on your disk and attempt to merge them. There must be someone out there who knows a better way to do this? Regards, Oliver Mind you, it's not like we're working against a deadline here, and I'm happy taking a few days off from thinking about it ... but I'll plan where my breaks are better in terms of functionalitiy in the future. (Any SVN developers on this list want to help figure out how to make this better?) Alex. On 10/08/06, Oliver Deakin [EMAIL PROTECTED] wrote: Just sent my other mail before seeing this one. Rather than manually editing the entries file you can, as I suggest in the other mail, still revert the original file name after you have moved it to a new file. So you could: - move the file to a new name AddedFile.java.bak - svn revert AddedFile.java (this should still work even tho the file is no longer there) - svn up - compare AddedFile.java and AddedFile.java.bak - swear etc. Hope this helps, Oliver Alex Blewitt wrote: OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like entry name=AddedFile.java kind=file schedule=add revision=0/ then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first (chmod +w entries or attrib -r entries) 2d) svn up AddedFile.java (which brings it in) 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the changes are 2f) Delete AddedFile.java.bak since it's no longer
Re: [DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
Jimmy, Jing Lv wrote:
Hi,
As discussed in the former thread, I find that a JNI of DRLVM
(GetByteArrayRegion) differs from RI in passing parameter
(byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM
throws an ArrayIndexOutOfBoundsException.
IMHO, it is better to improve here, make it follow RI, as JNI is
also a part of API, and users may use it. So if no objections, shall I
or someone raise a JIRA for this?
Go ahead and raise a JIRA Jimmy.
Regards,
Tim
I don't know if Martin is urgent in using Harmony in Winstone
servlet engine (Martin, can you read this?), so shall I work around in
java code before we have conclusion?
Any comments/suggestions from DRLVM guys? Thanks!
Jimmy, Jing Lv wrote:
Jimmy, Jing Lv wrote:
snip
I do some further study and test then, and find the problem was not
so easy.
Alex and I are correct that offset = buffer.length here is wrong,
but the next count = buffer.length - offset seems has proved its
correctness.
I have a test[1], try to write(new byte[count],count, 0) to a
SocketOutputStream, the test passes quietly. I do this test on WinXp
Sp2, the latest Harmony workspace, with J9 VM5.
I believe the ArrayIndexOutOfBoundsException is throw out when it try
to get byte array in the native (GetByteArrayRegion), which is a JNI
method. I guess there may be some difference between VMs.
Martin, are you using DRLVM? Can someone using DRLVM (or other VMs)
run the test below on DRLVM for me? Thanks!
[1]
public void test_socketOutputStream() throws Exception {
ServerSocket ss = new ServerSocket(0);
Socket sock = new Socket();
sock.connect(new InetSocketAddress
(InetAddress.getLocalHost(),ss.getLocalPort()));
ss.accept();
OutputStream os = sock.getOutputStream();
os.write(new byte[0], 0, 0); // passes here
os.write(new byte[512], 512, 0); // passes here
}
Hi,
At last I have test[1] JNI method(GetByteArrayRegion) of RI
(before dinner, very hungry... :) )
The result is that, RI return successfully if the given offset
equals length of the byte array, and the given count is zero.
Thus IMHO it is better to improve DRLVM to follow RI, as JNI
methods are also API methods, users may use it.
Shall we raise a JIRA for DRLVM? Any comments/suggestions from
DRLVM guys? Thanks!
Time for dinner! :D
[1]
test.java
--
class test
{
static{
System.loadLibrary(testjni);
}
private native void testjni(byte[] bs);
public void usejni(){
testjni(new byte[512]);
}
public static void main(String args[]){
new test().usejni();
}
}
---
test.h
---
/* DO NOT EDIT THIS FILE - it is machine generated */
#include jni.h
/* Header for class test */
#ifndef _Included_test
#define _Included_test
#ifdef __cplusplus
extern C {
#endif
/*
* Class: test
* Method:testjni
* Signature: ([B)V
*/
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv *, jobject, jbyteArray);
#ifdef __cplusplus
}
#endif
#endif
--
test.c
--
#include test.h
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv * env, jobject obj,jbyteArray array){
jbyte* buf = (jbyte*)malloc(sizeof(jbyte)*512);
(*env)-GetByteArrayRegion(env,array,512, 0, buf);
}
(magic number 512 can be any integer, including zero)
snip
--
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][instrument]Method to terminate VM.
Jimmy, Jing Lv wrote: Leo Li wrote: Hi, all During the implementaion of instrument, I encounter the choice about how to terminate the VM when some abnormal event occurs, for example, the expected jar file does not exist or the implementation class of Instrumentation cannot be found. The most simple and direct way is just to call exit(), and then the whole process will terminate. Hence OS will treat with all the release of resources. However, I propose to use FatalError of JNI instead, which notifies the VM to suicide, because it gives right to the implementation of VM to take charge of its own funeral affairs, which might include, for example, logging the cause of its crash. Any suggestion from VM guys? Thanks :) Hi, I agree that use VM FatalError is better than system exit(). If no objections, I will make code that way. Agreed, throw an error. 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: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
Just FYI if you haven't seen it, seems yet another win2k user was complaining on this. Radek Terber (JIRA) wrote: Cannot run 'java.exe' - missing entry point in KERNEL.dll - Key: HARMONY-1145 URL: http://issues.apache.org/jira/browse/HARMONY-1145 Project: Harmony Issue Type: Bug Components: VM Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04 (both HDK and JRE) Reporter: Radek Terber Attachments: errmsg.gif When try start JRE using 'java.exe', windows display message (is attached to this bug), which means: 'Entry point of procedure AddVectorExceptionHandler not found in dynamic link libryry KERNEL32.dll' -- 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][luni] junit4.0 fails on harmony due to missing method(s)
Done (r430732) Tim Alexey Varlamov wrote: Could someone of the fellow comitters kindly apply the HARMONY-1152 patch, it is needed to use junit4.0: java -cp .:junit-4.0.jar org.junit.runner.JUnitCore org.junit.tests.AllTests JUnit version 4.0 Exception in thread main java.lang.NoSuchMethodError: java/lang/String.format(Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String; at org.junit.runner.Description.createTestDescription(Description.java:39) at org.junit.internal.runners.TestClassMethodsRunner.methodDescription(TestClassMethodsRunner.java:83) at org.junit.internal.runners.TestClassMethodsRunner.getDescription(TestClassMethodsRunner.java:51) at org.junit.internal.runners.TestClassRunner.getDescription(TestClassRunner.java:57) at org.junit.internal.runners.CompositeRunner.getDescription(CompositeRunner.java:36) at org.junit.internal.runners.TestClassRunner.getDescription(TestClassRunner.java:57) at org.junit.internal.runners.CompositeRunner.getDescription(CompositeRunner.java:36) at org.junit.runner.JUnitCore.run(JUnitCore.java:120) at org.junit.runner.JUnitCore.run(JUnitCore.java:10) at org.junit.runner.JUnitCore.run(JUnitCore.java:91) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:75) at org.junit.runner.JUnitCore.main(JUnitCore.java:42) -- Alexey - 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: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
Before we get an agreement and solution on this issue, I suggest we add some words on it in FAQ/Readme/website or any well known place, it is much better to let our user know earlier than let them down. And because IBM VME can run on Win2k for now, how about we provide it as a workaround for those who are eager to try Harmony on win2k? Paulex Yang wrote: Just FYI if you haven't seen it, seems yet another win2k user was complaining on this. Radek Terber (JIRA) wrote: Cannot run 'java.exe' - missing entry point in KERNEL.dll - Key: HARMONY-1145 URL: http://issues.apache.org/jira/browse/HARMONY-1145 Project: Harmony Issue Type: Bug Components: VM Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04 (both HDK and JRE) Reporter: Radek Terber Attachments: errmsg.gif When try start JRE using 'java.exe', windows display message (is attached to this bug), which means: 'Entry point of procedure AddVectorExceptionHandler not found in dynamic link libryry KERNEL32.dll' -- 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]
Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
On 10 August 2006 at 14:51, Stepan Mishura [EMAIL PROTECTED] wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Hi Stepan,
IMO, most ser file should be put into a certain directory, so
the the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated
file is placed in 'bin' (i.e. module_root/bin/test).
folder. Am I right? So you have to move it by hands anyway to
module_root/src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules/name/build.xml are relative to modules/name, except those
on test invocations which are relative to modules/name/bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to include
../../build/tests when running the api tests, but when running the
api injected tests it appends ../../../../build/tests to the
bootclasspath (using -X vm argument).
I think ant should just run tests in modules/name.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
I took a look at the HARMONY-1041 tool. It is fine, I have only minor comments: - do you think we need to separate the Message and MsgUtil types? Given that they are generated from a template I'd be inclined to combine them into a single type now. We have no need to look in that file in general. If you do choose to combine them then I would expect the resulting header to be (c) 1998, 2006. - Minor typo Better make changes in the teamplate file. - template. Ilya Okomin wrote: I would suggest to split this task into a set of jira sub-issues, one module - one issue. This kind of division would give us an opportunity this work to be done in a parallel mode. Agreed. I suggest that we run the msgtool on the existing modules and commit the generated code and catalog files, then the incoming patches can assume they are there and use them to fix the externalization. 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] [ldap] support for multiple VMs?
Daniel Gandara wrote: Hi all, We are working on the javax.naming.ldap and we are facing the following issue when thinking about supporting multiple VMs. Following the SPEC there is a method createExtendedResponse in the StartTlsRequest class which states that the returning object must be an instance of a concrete subclass of StartTlsResponse and must have a public zero-argument constructor. The concrete subclass is determined by reading the configuration file located in META-INF/services/javax.naming.ldap.StartTlsResponse (see http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) The search for this configuration file is done by looking in the classpath, java.home and user.dir; also the Xbootclasspath should be inspected, and that seems to be a problematic situation, since there is not a standard property to look for its value. Different VM implementations have different property names for the boot class path value. In the old Harmony VM implementation was com.ibm.oti.system.class.path; in the new one is org.apache.harmony.boot.class. The property name in the Sun's VM is sun.boot.class.path. We are wondering which property name to use in the code. At first sight the Harmony new VM implementation property seems to be the better option, but maybe looking for the other properties will be interesting for compatibility purposes. We would be very interested in opinions. I'd ignore the com.ibm property and look through the path defined by org.apache.harmony.boot.class.path I don't know what property is set by the DRLVM / JCHEVM / etc., but it would be good if they set the same property (maybe in addition to their current property). If you want the code to run on the Sun implementation too then you should *also* search the sun.boot.class.path, and of course be tolerant of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal for you? It's not something that we would require for including the LDAP code in Harmony. 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: Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
Mark Hindess wrote:
On 10 August 2006 at 14:51, Stepan Mishura [EMAIL PROTECTED] wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Hi Stepan,
IMO, most ser file should be put into a certain directory, so
the the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated
file is placed in 'bin' (i.e. module_root/bin/test).
folder. Am I right? So you have to move it by hands anyway to
module_root/src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules/name/build.xml are relative to modules/name, except those
on test invocations which are relative to modules/name/bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to include
../../build/tests when running the api tests, but when running the
api injected tests it appends ../../../../build/tests to the
bootclasspath (using -X vm argument).
I think ant should just run tests in modules/name.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Great idea! :)
So Stepan will not object my method of createGolden, right? ;)
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: [classlib][suncompat] created
I agree with Alex, we should *not* have this by default. Having it enabled by default will not give a hint something's wrong with the code. I believe no one will ever look in the sources if everything works just fine, and therefore no one will see the deprecation. At least, the new code won't reference these classes. However we'll provide a workaround to keep legacy applications running on Harmony in cases where the code can't be updated properly. When suncompat.jar is removed from the default distribution, people will be frustrated as well. Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alex Blewitt [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: Re: RE: [classlib][suncompat] created I think the @deprecated is a good idea, but I strongly believe that we should *not* have this as a default. There's an easy workaround for the subset of applications that need it (e.g. enable it in the .properties file) whilst still preventing new code from being able to reference it. A simple FAQ should be enough to help people do this. Mind you, I seem to be in the minority on this view on this list :-) Alex. On 11/08/06, Nathan Beyer [EMAIL PROTECTED] wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][suncompat] created Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. geir Alex Blewitt wrote: Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Alex Blewitt wrote: OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. 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: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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: RE: [classlib][suncompat] created
Another solution is to create stubs which will throw exceptions with detailed message. Then users will get neccessary information but functionality won't be enabled by default. On 8/11/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: I agree with Alex, we should *not* have this by default. Having it enabled by default will not give a hint something's wrong with the code. I believe no one will ever look in the sources if everything works just fine, and therefore no one will see the deprecation. At least, the new code won't reference these classes. However we'll provide a workaround to keep legacy applications running on Harmony in cases where the code can't be updated properly. When suncompat.jar is removed from the default distribution, people will be frustrated as well. Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alex Blewitt [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: Re: RE: [classlib][suncompat] created I think the @deprecated is a good idea, but I strongly believe that we should *not* have this as a default. There's an easy workaround for the subset of applications that need it (e.g. enable it in the .properties file) whilst still preventing new code from being able to reference it. A simple FAQ should be enough to help people do this. Mind you, I seem to be in the minority on this view on this list :-) Alex. On 11/08/06, Nathan Beyer [EMAIL PROTECTED] wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][suncompat] created Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. geir Alex Blewitt wrote: Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Alex Blewitt wrote: OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. 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: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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: Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
On 8/11/06, Mark Hindess wrote:
On 10 August 2006 at 14:51, Stepan Mishura wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Hi Stepan,
IMO, most ser file should be put into a certain directory, so
the the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated
file is placed in 'bin' (i.e. module_root/bin/test).
folder. Am I right? So you have to move it by hands anyway to
module_root/src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules/name/build.xml are relative to modules/name, except those
on test invocations which are relative to modules/name/bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to
include
../../build/tests when running the api tests, but when running the
api injected tests it appends ../../../../build/tests to the
bootclasspath (using -X vm argument).
Yes, I agree that this is confusing and should be fixed.
Thanks,
Stepan.
I think ant should just run tests in modules/name.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Regards,
Mark.
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (HARMONY-1046) Remove jpegint.h from awt native sources
Sorry, Mark, I didn't mean to steal this closed one from you, I'm going to assign 1146 to myself... :-[ , more tea... Paulex Yang (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-1046?page=all ] Paulex Yang reassigned HARMONY-1046: Assignee: Paulex Yang (was: Mark Hindess) Remove jpegint.h from awt native sources Key: HARMONY-1046 URL: http://issues.apache.org/jira/browse/HARMONY-1046 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Petrenko Assigned To: Paulex Yang Priority: Minor Attachments: JIRA1046.diff AWT native jpeg encoder and decoder are using jpegint.h. But not all the jpeg library distributions has this header file. Evaluation shown that this file can be easily removed from the encoder and decoder. So we should do this. I'll prepare patch shortly. -- 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][suncompat] created
If we do not include suncompat.jar into classpath at compile time, rather than runtime, then the users will get the feedback at approprate moment of time. So, I would suggest + include suncompat.jar to runtime classpath by default - do *not* include suncompat.jar to compile-time classpath by default Geir Magnusson Jr wrote: Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. - 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] [ldap] support for multiple VMs?
A bit offttopic for this thread, but I'd like to discuss the following points for the boot.class.path property: 1) Whose responsibility is to set this property (launcher, VM or classlib)? Now we have at least 3 implementations: a) readClassPathFromPropertiesFile() in classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c b) readClassPathFromPropertiesFile() in classlib\modules\luni\src\main\native\luni\shared\luniglob.c c) load_full_api_files_path_names_list() in drlvm\vm\vmcore\src\init\properties.cpp BTW, the first 2 seems to be just copy-paste copies. I believe there should be just single agent doing this task, most natural candidate is shared VM launcher. 2) Current parsers of the bootclasspath.properties are fragile in relation to format of this file: the file must end with line delimiter and must have strict platform line delimiters, otherwise jvm just hangs. Should I file new JIRA or this is intentional? 2006/8/11, Tim Ellison [EMAIL PROTECTED]: Daniel Gandara wrote: Hi all, We are working on the javax.naming.ldap and we are facing the following issue when thinking about supporting multiple VMs. Following the SPEC there is a method createExtendedResponse in the StartTlsRequest class which states that the returning object must be an instance of a concrete subclass of StartTlsResponse and must have a public zero-argument constructor. The concrete subclass is determined by reading the configuration file located in META-INF/services/javax.naming.ldap.StartTlsResponse (see http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) The search for this configuration file is done by looking in the classpath, java.home and user.dir; also the Xbootclasspath should be inspected, and that seems to be a problematic situation, since there is not a standard property to look for its value. Different VM implementations have different property names for the boot class path value. In the old Harmony VM implementation was com.ibm.oti.system.class.path; in the new one is org.apache.harmony.boot.class. The property name in the Sun's VM is sun.boot.class.path. We are wondering which property name to use in the code. At first sight the Harmony new VM implementation property seems to be the better option, but maybe looking for the other properties will be interesting for compatibility purposes. We would be very interested in opinions. I'd ignore the com.ibm property and look through the path defined by org.apache.harmony.boot.class.path I don't know what property is set by the DRLVM / JCHEVM / etc., but it would be good if they set the same property (maybe in addition to their current property). If you want the code to run on the Sun implementation too then you should *also* search the sun.boot.class.path, and of course be tolerant of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal for you? It's not something that we would require for including the LDAP code in Harmony. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
Hello,
Mess with golden files seem to be a problem. Why not just pass path to
an alternative JVM as an argument to the tests? Maybe an environment
variable or a VM property. The test framework can serialize some data
in one vm, deserialize it in another and check that object was
deserialized correctly. Process communication or serialization to
temporary files can be used to exchange data between VMs. This
approach will:
- remove golden files
- allow test that data serialized in Harmony is deserialized in
another VM correctly
- allow compare Harmony serialization with any VM, not only the one
used when golden files were produced.
The test based on such framework will look something like:
public void writeTestData(ObjectOutputStream oos) {
oos.write(new Integer(2));
}
public void readTestData(ObjectInputStream ois) {
Integer i = (Integer) ois.readObject();
assertEquals(i.intValue(), 2);
}
On 8/11/06, Stepan Mishura [EMAIL PROTECTED] wrote:
On 8/11/06, Mark Hindess wrote:
On 10 August 2006 at 14:51, Stepan Mishura wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Hi Stepan,
IMO, most ser file should be put into a certain directory, so
the the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated
file is placed in 'bin' (i.e. module_root/bin/test).
folder. Am I right? So you have to move it by hands anyway to
module_root/src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules/name/build.xml are relative to modules/name, except those
on test invocations which are relative to modules/name/bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to
include
../../build/tests when running the api tests, but when running the
api injected tests it appends ../../../../build/tests to the
bootclasspath (using -X vm argument).
Yes, I agree that this is confusing and should be fixed.
Thanks,
Stepan.
I think ant should just run tests in modules/name.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Regards,
Mark.
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
Winstone servlet engine fixed to run on Harmony
The author of Winstone detected the problem that generated an exception when running on Harmony and fixed it the same day. My first impressions: Harmony JRE snapshot is fast. All database I/O code from my webapp did run fine, as well as all network I/O. I could not test PDF (IText) and Charts (JFreeChart) creation because certain Image classes are not implemented yet. I will as soon as they become available. My pending tasks: test on Linux (OpenSuSE 10.0) and test SSL support for server sockets. I will keep you informed. Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keytool is done, JarSigner is next.
I'm happy to write this - Keytool is done and operative now. :) It has the same functionality as the one from RI with some improvements. In addition to what RI can do the Harmony Keytool is able to * generate X.509 certificates v2, v3. * sign a certificate with another key from the keystore * generate and manage secret keys * convert a keystore to another format * check certificate revocation status * verify a certificate chain * use specific providers for various purposes. There is still a little problem with making an executable of the tool in the build. So you can follow the steps to make it on your own: 1. copy deploy\jdk\jre\bin\java.exe to deploy\jdk\jre\bin\keytool.exe 2. copy deploy\jdk\lib\tools.jar into deploy\jdk\jre\bin\ 3. run keytool.exe I want to thank Mikhail for applying my patches. I'm going to start work on JarSigner tool. Does anyone have objections to me doing this? -- Thanks, Anton - 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] compatibility packages
Dalibor Topic wrote: On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks to the JVM JSR not being ahead thinking enough to specify an API for low-level operations. It may or may not work depedending on how a VM interprets the non-existent spec for that class, so it is practically useless, unless it is running on the VM it was written on, i.e. Sun's. It may or may not work by chance, rather than by virtue. I think you are being too harsh here, but that notwithstanding, one of the things we can do as open implementations is petition the EG to actually define these in the spec once we show that there's a good reason to do so, namely the independent implementations. The independant implementations are not using sun.misc.Unsafe. Why would anyone want to use an undocumented implementation-specific class from another implementation in their own? That makes no sense. There is no point in petitioning the EC to specify sun.misc.Unsafe since no one in their right mind uses it, except Sun, in the interna of their implementation. That's like asking the EC to specify org.kaffe.util.Ptr, or something equivalently pointless from DLRVM. It makes sense if you wish to use Doug's concurrency package as-is, as it has dependencies on sun.misc.Unsafe, which I think is a Good Thing. After we do that, I think we then go back to the EG and point out that in order for the world to reuse this code, we need to have sun.misc.Unsafe defined (of course, it would be given another namespace...). What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, with a sane API that does not require computing field offsets manually, like sun.misc.Unsafe seems to do. ;) That would a good thing to ask for two - the two would make a nice request. The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather simple bug in Doug Lea's java.util.concurrent implementation: using Sun-specific classes directly, rather than delegating to some java.util.concurrent.VMCompareAndSwap interface layer. That means anyone adopting the code needs to repeat the mistakes of Sun's implementation (which has, coincidentally, had a very straightforward remote execution exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. Yay. :/ Other than Doug's code, sun.misc.Unsafe does not matter at all, unless you want remote-execution-exploit-for-remote-execution-exploit compatibility. I believe that's too much to ask for. ;) I think we've been clear all along why we'd implement this - we want to use Doug's code. [SNIP] Sure, but again, not everyone will be as wise as Martin - they'll just bail on us. They may even realize that there's a problem with their code, but there may be nothing they can do about it. People bailing on us is not a problem, as people *stuck with Sun-specific code* will (and should, IMHO) only use Sun's VM anyway. People blindly trusting us because we pretend to run some Sun-specific code according to some unspecified interface is a problem, both for them, as their code will obviously behave differently from what it expects, in subtle ways, if they are very unlucky, and for us, as we have to chase unreproducible behaviour as Sun changes their internal interfaces around. See the sad story of Ant's chasing around of sun.tools.javac.Main tail over and over again. Oh, come on. You talk like the rest of the spec is rock solid and perfectly defined. We're spelunking the RI through black-box testing all the time in our drive to get full behavioral compatibility. Adding a few utility classes that people are unfortunately using - knowingly or unknowingly - is simply good customer service, IMO. The 'works 100% like Sun's VM out-of-the-box for Sun-specific code' niche is already taken by Sun. There is no point in trying to compete with them on that, or for the audience that wants and expects that. Been there, done that, etc. ;) I think we'll have to continue to disagree on this one. I do want Harmony to work 100% like Sun to start because we want users to be able to effortlessly transition to Harmony. Software is nothing without users. 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][instrument]Method to terminate VM.
How far along is this code? Any chance you want to toss up a snapshot of it so people can look and comment and ... maybe even help? geir Jimmy, Jing Lv wrote: Leo Li wrote: Hi, all During the implementaion of instrument, I encounter the choice about how to terminate the VM when some abnormal event occurs, for example, the expected jar file does not exist or the implementation class of Instrumentation cannot be found. The most simple and direct way is just to call exit(), and then the whole process will terminate. Hence OS will treat with all the release of resources. However, I propose to use FatalError of JNI instead, which notifies the VM to suicide, because it gives right to the implementation of VM to take charge of its own funeral affairs, which might include, for example, logging the cause of its crash. Any suggestion from VM guys? Thanks :) Hi, I agree that use VM FatalError is better than system exit(). If no objections, I will make code that way. - 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][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
I think we should just fix it in DRLVM, although performance-wise,
wouldn't also fixing in Java make sense too?
As Tim said, raise a JIRA.
geir
Jimmy, Jing Lv wrote:
Hi,
As discussed in the former thread, I find that a JNI of DRLVM
(GetByteArrayRegion) differs from RI in passing parameter
(byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM
throws an ArrayIndexOutOfBoundsException.
IMHO, it is better to improve here, make it follow RI, as JNI is
also a part of API, and users may use it. So if no objections, shall I
or someone raise a JIRA for this?
I don't know if Martin is urgent in using Harmony in Winstone
servlet engine (Martin, can you read this?), so shall I work around in
java code before we have conclusion?
Any comments/suggestions from DRLVM guys? Thanks!
Jimmy, Jing Lv wrote:
Jimmy, Jing Lv wrote:
snip
I do some further study and test then, and find the problem was not
so easy.
Alex and I are correct that offset = buffer.length here is wrong,
but the next count = buffer.length - offset seems has proved its
correctness.
I have a test[1], try to write(new byte[count],count, 0) to a
SocketOutputStream, the test passes quietly. I do this test on WinXp
Sp2, the latest Harmony workspace, with J9 VM5.
I believe the ArrayIndexOutOfBoundsException is throw out when it try
to get byte array in the native (GetByteArrayRegion), which is a JNI
method. I guess there may be some difference between VMs.
Martin, are you using DRLVM? Can someone using DRLVM (or other VMs)
run the test below on DRLVM for me? Thanks!
[1]
public void test_socketOutputStream() throws Exception {
ServerSocket ss = new ServerSocket(0);
Socket sock = new Socket();
sock.connect(new InetSocketAddress
(InetAddress.getLocalHost(),ss.getLocalPort()));
ss.accept();
OutputStream os = sock.getOutputStream();
os.write(new byte[0], 0, 0); // passes here
os.write(new byte[512], 512, 0); // passes here
}
Hi,
At last I have test[1] JNI method(GetByteArrayRegion) of RI
(before dinner, very hungry... :) )
The result is that, RI return successfully if the given offset
equals length of the byte array, and the given count is zero.
Thus IMHO it is better to improve DRLVM to follow RI, as JNI
methods are also API methods, users may use it.
Shall we raise a JIRA for DRLVM? Any comments/suggestions from
DRLVM guys? Thanks!
Time for dinner! :D
[1]
test.java
--
class test
{
static{
System.loadLibrary(testjni);
}
private native void testjni(byte[] bs);
public void usejni(){
testjni(new byte[512]);
}
public static void main(String args[]){
new test().usejni();
}
}
---
test.h
---
/* DO NOT EDIT THIS FILE - it is machine generated */
#include jni.h
/* Header for class test */
#ifndef _Included_test
#define _Included_test
#ifdef __cplusplus
extern C {
#endif
/*
* Class: test
* Method:testjni
* Signature: ([B)V
*/
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv *, jobject, jbyteArray);
#ifdef __cplusplus
}
#endif
#endif
--
test.c
--
#include test.h
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv * env, jobject obj,jbyteArray array){
jbyte* buf = (jbyte*)malloc(sizeof(jbyte)*512);
(*env)-GetByteArrayRegion(env,array,512, 0, buf);
}
(magic number 512 can be any integer, including zero)
snip
-
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][suncompat] created
Nathan Beyer wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. I've had some private musings of also getting those classes to log to some kind of your_code_is_broken.log but that's just early morning crazy talk. geir -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][suncompat] created Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. geir Alex Blewitt wrote: Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Alex Blewitt wrote: OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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][suncompat] created
Salikh Zakirov wrote: If we do not include suncompat.jar into classpath at compile time, rather than runtime, then the users will get the feedback at approprate moment of time. So, I would suggest + include suncompat.jar to runtime classpath by default - do *not* include suncompat.jar to compile-time classpath by default That's a very nice solution. None of the arguments have swayed me about not having it at runtime because while I agree that it's bad practice, our biggest interest *at this time* is to get users, because users are going to be an enormous help in finding bugs, prioritizing what we are working on, etc. And removing every speedbump in the road to using harmony is going to help that. We will be in a great position to help people stop this misbehavior, as *when they are interested*, they can simply remove suncompat easily and quickly due to our great modularity... I think we can use this problem to our advantage... geir Geir Magnusson Jr wrote: Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. - 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: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
Nice. Have a patch? :)
geir
Vladimir Ivanov wrote:
Seems, that drlvm rejects valid code when 'end_pc' value for exception
handler is equal to code array length.
At least, when I update value for 'end_pc' in my simple class it was
rejected by drlvm and accepted by RI.
Thanks, Vladimir
More details:
2 class attached: test.class.ref - generated by javac,
test.class - updated (line 108 for file belove was updated: 8 - 10)
- test.code
/**
* Generated ccode file
* @author VMTT (Virtual Machine Testing Tools)
* @version 1.0
* @lastmod: Fri Aug 11 11:20:30 NOVST 2006
*/
magic = xCAFEBABE
minor_version = 0
major_version = 48
constant_pool_count = 18
constant_pool {
/* #1 */ Method = #5 #14
/* #2 */ Class = #15
/* #3 */ Method = #2 #14
/* #4 */ Class = #16
/* #5 */ Class = #17
/* #6 */ UTF8 = init
/* #7 */ UTF8 = ()V
/* #8 */ UTF8 = Code
/* #9 */ UTF8 = LineNumberTable
/* #10 */ UTF8 = main
/* #11 */ UTF8 = ([Ljava/lang/String;)V
/* #12 */ UTF8 = SourceFile
/* #13 */ UTF8 = test.java
/* #14 */ NameAndType = #6 #7
/* #15 */ UTF8 = java/lang/Exception
/* #16 */ UTF8 = test
/* #17 */ UTF8 = java/lang/Object
}
access_flags = PUBLIC SUPER // x21
this_class = #4 // test
super_class = #5 // java/lang/Object
interfaces_count = 0
interfaces {
}
fields_count = 0
methods_count = 2
methods {
method {
access_flag = PUBLIC // x01
name_index = #6 // init
descriptor_index = #7 // ()V
attributes_count = 1
attributes {
attribute Code {
attribute_name_index = #8 // Code
attribute_length = 29
max_stack = 1
max_locals = 1
code_length = 5
code asm {
0: aload_0
1: invokespecial #1 // java/lang/Object init ()V
4: return
}
exception_table_length = 0
attributes_count = 1
attributes {
attribute LineNumberTable {
attribute_name_index = #9 // LineNumberTable
attribute_length = 6
line_number_table_length = 1
line_number_table {
// start_pc line_number
0 1
}
}
}
}
}
}
method {
access_flag = PUBLIC STATIC // x09
name_index = #10 // main
descriptor_index = #11 // ([Ljava/lang/String;)V
attributes_count = 1
attributes {
attribute Code {
attribute_name_index = #8 // Code
attribute_length = 50
max_stack = 2
max_locals = 2
code_length = 10
code asm {
0: new #2 // java/lang/Exception
3: dup
4: invokespecial #3 // java/lang/Exception init ()V
7: athrow
8: astore_1
9: return
}
exception_table_length = 1
exception_table {
// start_pc end_pc handler_pc catch_type
0 10 8 2
}
attributes_count = 1
attributes {
attribute LineNumberTable {
attribute_name_index = #9 // LineNumberTable
attribute_length = 14
line_number_table_length = 3
line_number_table {
// start_pc line_number
0 4
8 5
9 7
}
}
}
}
}
}
}
attributes_count = 1
attributes {
attribute SourceFile {
attribute_name_index = #12 // SourceFile
attribute_length = 2
sourcefile_index = #13 // test.java
}
}
---
Output:
C:\tmp\vm_tooljava -showversion test
java version 1.4.2_10
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)
C:\tmp\vm_toolC:\jdk1.5.0_06\bin\java -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)
C:\tmp\vm_toolC:\harmony\drlvm1.5\build\win_ia32_msvc_debug\deploy\jre\bin\java
-Dvm.assert_dialog=false -cp . -showversion test
java version 1.5.0
pre-alpha : not complete or compatible
svn = r430643, (Aug 11 2006), Windows/ia32/msvc 1310, debug build
http://incubator.apache.org/harmony
vf_debug: VerifyError: (class: test, method: main([Ljava/lang/String;)V)
Handler pc is out of range
java.lang.VerifyError: (class: test, method: main([Ljava/lang/String;)V)
Handler pc is out of range
at java.lang.VMClassRegistry.defineClass()
at java.lang.ClassLoader.defineClass()
at java.security.SecureClassLoader.defineClass(
SecureClassLoader.java:68)
at java.net.URLClassLoader.findClassImpl(URLClassLoader.java:1130)
at
Re: [classlib][String] Request for fixing bug in String(byte[] bytes, int offset, int length, String charsetName)
Never worry if there will be an objection to you raising a JIRA and
providing a patch.Just Do It!
:)
geir
Richard Liang wrote:
Hello All,
The constructor String(byte[] bytes, int offset, int length, String
charsetName) has the same bug as Harmony-487[1]. When the charsetName
is , RI throws UnsupportedEncodingException, but Harmony throws
IllegalCharsetNameException.
If there is no objection, I will raise a JIRA and provide a patch for
this issue. Thanks a lot.
The following test passes on RI, but fails on Harmony:
try {
String str = new String(new byte[] {0x41, 0x42}, 0, 2, );
fail(Should throw UnsupportedEncodingException);
} catch (UnsupportedEncodingException e) {
//expected
}
[1]http://issues.apache.org/jira/browse/HARMONY-487
-
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] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
I'll add something on the site today, and put notes in the JRE. I'll also add language to point win2k users to the IBM JRE, but we won't publish a snapshot using it - we not only don't have the rights, I think it's safe to say that we don't want to. I'll remove DRLVM from the HDK to make it an easier drop in though, that should help. geir Paulex Yang wrote: Before we get an agreement and solution on this issue, I suggest we add some words on it in FAQ/Readme/website or any well known place, it is much better to let our user know earlier than let them down. And because IBM VME can run on Win2k for now, how about we provide it as a workaround for those who are eager to try Harmony on win2k? Paulex Yang wrote: Just FYI if you haven't seen it, seems yet another win2k user was complaining on this. Radek Terber (JIRA) wrote: Cannot run 'java.exe' - missing entry point in KERNEL.dll - Key: HARMONY-1145 URL: http://issues.apache.org/jira/browse/HARMONY-1145 Project: Harmony Issue Type: Bug Components: VM Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04 (both HDK and JRE) Reporter: Radek Terber Attachments: errmsg.gif When try start JRE using 'java.exe', windows display message (is attached to this bug), which means: 'Entry point of procedure AddVectorExceptionHandler not found in dynamic link libryry KERNEL32.dll' - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Winstone servlet engine fixed to run on Harmony
Martin Cordova wrote: The author of Winstone detected the problem that generated an exception when running on Harmony and fixed it the same day. My first impressions: Harmony JRE snapshot is fast. All database I/O code from my webapp did run fine, as well as all network I/O. I could not test PDF (IText) and Charts (JFreeChart) creation because certain Image classes are not implemented yet. I will as soon as they become available. That's really great to hear! My pending tasks: test on Linux (OpenSuSE 10.0) and test SSL support for server sockets. I will keep you informed. That's for doing this :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools] Re: Keytool is done, JarSigner is next.
1) YAY! 2) No objections for jarsigner, but rather thanks and encouragement! 3) You may have been doing the following and I simply missed it, but I'd suggest that you keep a stream of patches coming on things like this so that people can see and get involved and also discuss more of your experience doing this on the list as it happens. 4) Can you add [tools] to your subject lines? :) geir Anton Rusanov wrote: I'm happy to write this - Keytool is done and operative now. :) It has the same functionality as the one from RI with some improvements. In addition to what RI can do the Harmony Keytool is able to * generate X.509 certificates v2, v3. * sign a certificate with another key from the keystore * generate and manage secret keys * convert a keystore to another format * check certificate revocation status * verify a certificate chain * use specific providers for various purposes. There is still a little problem with making an executable of the tool in the build. So you can follow the steps to make it on your own: 1. copy deploy\jdk\jre\bin\java.exe to deploy\jdk\jre\bin\keytool.exe 2. copy deploy\jdk\lib\tools.jar into deploy\jdk\jre\bin\ 3. run keytool.exe I want to thank Mikhail for applying my patches. I'm going to start work on JarSigner tool. Does anyone have objections to me doing this? - 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][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
2006/8/11, Jimmy, Jing Lv [EMAIL PROTECTED]: Hi, As discussed in the former thread, I find that a JNI of DRLVM (GetByteArrayRegion) differs from RI in passing parameter (byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM throws an ArrayIndexOutOfBoundsException. IMHO, it is better to improve here, make it follow RI, as JNI is also a part of API, and users may use it. So if no objections, shall I or someone raise a JIRA for this? I don't know if Martin is urgent in using Harmony in Winstone servlet engine (Martin, can you read this?), so shall I work around in java code before we have conclusion? Any comments/suggestions from DRLVM guys? Thanks! I didn't really understand the condition when vm throws AIOBE. Do you pass start parameter count for the array of count length? But in this case the start points to the element right after the array end. And spec [1] explicitly states that this function should throw AIOBE in this case. Is there something I don't understand? [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#wp6212 -- Gregory Shimansky, Intel Middleware Products Division
Re: [general] *.boot.class.path propoerty setting
Geir Magnusson Jr wrote: I was going to talk about the exact thing when I had a chance, so glad you beat me to it. I'm just changing the subject line so it's clearer. Inline. Alexey Varlamov wrote: A bit offttopic for this thread, but I'd like to discuss the following points for the boot.class.path property: 1) Whose responsibility is to set this property (launcher, VM or classlib)? Now we have at least 3 implementations: a) readClassPathFromPropertiesFile() in classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c b) readClassPathFromPropertiesFile() in classlib\modules\luni\src\main\native\luni\shared\luniglob.c c) load_full_api_files_path_names_list() in drlvm\vm\vmcore\src\init\properties.cpp BTW, the first 2 seems to be just copy-paste copies. I believe there should be just single agent doing this task, most natural candidate is shared VM launcher. I also thought the launcher was the right place, but not so sure, as you wouldn't want to handcuff the VM implementations as to what kinds of features they can add here. Maybe VM launcher sets it originally, but the VM is free to override? Not in the launcher, it has to be set for any application that calls JNI_CreateJavaVM. 2) Current parsers of the bootclasspath.properties are fragile in relation to format of this file: the file must end with line delimiter and must have strict platform line delimiters, otherwise jvm just hangs. Should I file new JIRA or this is intentional? Please file a JIRA. Hanging can never be intentional. :) Agreed, create JIRAs for these problems. 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: [general] compatibility packages
Dalibor Topic wrote: On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: Dalibor Topic wrote: On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. Hardly. Many replacements for Base64 exists, for example GNU Classpath recommends using Apache Commons Codec for projects compatible with the Apache license. Amateur developers use non-standard classes because they are too lazy to think for themselves, and accordingly copy broken code around projects. Alas, a language designed to appeal to the masses naturally attracts a lot of people who'd have trouble producing portable code in any programming language. :) I was being charitable. For sure many such usages can be easily avoided, but in other cases no so easily; like CharToByteConverter would require duplicating a wad of data, and I don't know of any third-party impl. of Unsafe. Is there something that CharToByteConverter does that CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen code using CharToByteConverter in years. If you want to duplicate the char conversion data then sure, but taking a multi-MB hit isn't palatable to many apps when sun.io is sitting there smiling at them. I saw a few uses when testing apps, but maybe I was unlucky. For example, Xalan was using it until it was pointed it out last year (http://issues.apache.org/jira/browse/XALANJ-2087). Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks to the JVM JSR not being ahead thinking enough to specify an API for low-level operations. It may or may not work depedending on how a VM interprets the non-existent spec for that class, so it is practically useless, unless it is running on the VM it was written on, i.e. Sun's. It may or may not work by chance, rather than by virtue. That holds in general for any code using implementation-specific interfaces. Exactly. We should appeal to app developers to change implementation dependent code (even provide a recipe book of recommended solutions), but be pragmatic about the need to run the current version. In many cases it may be beyond the apps immediate sphere of influence (i.e. dependent libraries). If everyone responded as quickly and effectively as Martin we would have no worries. We've been doing that for years. See the GNU Classpath migration page in the Wiki that describes how to fix such broken code in many cases. Ack -- I see it here (just so others can find it too). http://developer.classpath.org/mediation/ClasspathMigration Being 'pragmatic' solves nothing, it just encourages people to continue behaving in dumb ways, because their code still may run, somehow, even if there is no way for Harmony to ensure that it will behave as they expect from whatever buggy Sun JDK they are using to run it usually in the corner cases, because there is no spec, and there are no tests. It's pragmatic because as I said, sometimes it is beyond the immediate control of the application, and sometimes you won't get a second chance to demonstrate your wares. 'Harmony - runs fewer apps than the leading brand' is hardly a compelling tag line. I believe that everyone wants to reduce dependencies on the non-API types. It is a millstone for IBM and Sun and BEA etc if they cannot modify their implementations without customers coming down on them. But at this point we cannot call the shots from Harmony. Awarding incompetence doesn't solve the problem. That being said, kudos to Martin for fixing the bug in his code. Had we had a Base64 class, that bug wouldn't have showed up, and his code would have failed elsewhere, or behaved differently on another VM. With the fix, his code is portable, behaves in the same way on any VM, and may even be faster than a vm-specific 'just for compatibility' implementation. There is no downside to simply fixing the buggy code. I agree, of course. On a side note, I seem to recall reading on Sun's javac engineer's blog that javac won't allow access to sun internal classes sooner or later, so idiot-proofing class libraries may not be very useful, anyway, as people will have to rewrite such code, or preferrably, throw it away. It will be interesting to see what havoc is unleashed by attempts to reduce the visibility of sun internal packages by the compiler and at runtime. I assume it will just cause unmaintained libraries to be substituted by maintained ones, as people trade up to higher quality implementations of functionality they need. Code that uses sun.* classes is a bad smell, to invoke Fowler. If it doesn't get fixed, just get rid of it, and use something else that doesn't
Re: Winstone servlet engine fixed to run on Harmony
ASAP :) Martin Cordova wrote: Geir, is there a planned release date for the Image/Graphics2D stuff? I thought that the Intel contribution covered this very well. Regards, Martin On 8/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Martin Cordova wrote: The author of Winstone detected the problem that generated an exception when running on Harmony and fixed it the same day. My first impressions: Harmony JRE snapshot is fast. All database I/O code from my webapp did run fine, as well as all network I/O. I could not test PDF (IText) and Charts (JFreeChart) creation because certain Image classes are not implemented yet. I will as soon as they become available. That's really great to hear! My pending tasks: test on Linux (OpenSuSE 10.0) and test SSL support for server sockets. I will keep you informed. That's for doing this :) 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: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
can you please add that patch to the JIRA entry?
Anton Luht wrote:
Hello,
Yes, the problem with verifier is partly solved but problems in verifier
remain.
method vf_resolve_class( name, true, ctex ) from ver_utils.cpp
sometimes returns null when vf_resolve_class( name, false, ctex )
returns non-null for same class name. This method is for looking up
classes, if I understand correctly, 'true' means load class if not
loaded and 'false' - just take from cache anything that is there,
don't try to load. The situation when class is in cache and 'deep'
load can't find it shouldn't happen.
Temp workaround for this bug before deep investigation can be:
Index: ver_utils.cpp
===
--- ver_utils.cpp (revision 430763)
+++ ver_utils.cpp (working copy)
@@ -1391,6 +1391,9 @@
// get stack reference class
class_handler source = vf_resolve_class( constraint-source, true,
ctex );
+if(source == NULL) {
+ source = vf_resolve_class( constraint-source, false, ctex );
+}
if( !source ) {
VERIFY_DEBUG( verifying class class_get_name( ctex-m_class )
(method method_get_name( constraint-method )
after that the activemq start fails with message:
ERROR: java.lang.RuntimeException: Failed to execute start task. Reason:
java.la
ng.ArrayStoreException
To be continued.
On 8/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
I think I've fixed this a few days ago and attached the patch to JIRA.
See
my emails in this thread. Does it fix the problem with verifier for you?
The problem with verifier is only the first one with activemq. After I
fixed
the exception problem the app still didn't start up.
-
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] platform support
Any _primary_ platform that will be supported by Harmony will probably need to be put thru a pretty full test protocol on that platform independent of whether it uses the same binary or a different binary. I doubt that the Harmony community will want to target all possible OS combinations initially. I think that we should have a serious discussion on this list about the OS combinations for which we have volunteers on board for Harmony 1.0. I don't believe that Harmony should achieve ubiquity by using least common denominator interfaces. For x86 32bit-mode systems, I do think we'll probably need to limit ourselves to one or two binaries. See http://java.sun.com/j2se/1.5.0/system-configurations.html and http://edocs.bea.com/jrockit/jrdocs/suppPlat/supp_50.html a list of what combinations Sun and BEA support today with their Java5 solutions. I am unconvinced that a combined binary will make testing any easier. I believe that the makefile (oops, I mean ant) structure will be easier with a combined binary but the startup code and some platform specific optimization code will be more complex as it will need a pretty sophisticated platform determination and a somewhat manual library loading process. At the same time, I believe a combined binary that includes multipath checks will simplify distribution. I also believe that something similar will be necessary for Linuxes though perhaps not as sophisticated. Lets say that we decide to go for complete, optimal, windows support. We would have special case code that chooses appropriate library interfaces at startup for somewhere between 7 and 18 different versions of x86 windows, not accounting for service packs: * x86 Vista home, pro, tablet * x86 Vista/Longhorn server, webserver * x86 Vista/longhorn enterprise * x86 XP home, pro, tablet, media * x86 XP/2003 server, webserver, Enterprise, Datacenter * x86 W2K * x86 W2K Server, W2K Advanced Server, Datacenter This of course doesn't account for the either EM64T or Itanium family processor based systems. Maybe someone needs to take each OS platform and list what special interfaces are useful for each one. I'm particularly partial to some of the interfaces available only on the server versions such as the large page APIs: http://windowssdk.msdn.microsoft.com/en-us/library/ms694004.aspx. http://windowssdk.msdn.microsoft.com/en-us/library/ms724833.aspx talks about how to distinguish the different versions and service packs from each other. This is probably pretty useful information to report back to JIRA in the case of a VM crash if we have a single binary release model. Of course if one wants to be able to run on windowsMe or Windows98, one can't rely on these interfaces... But then since these aren't actively supported by Microsoft anymore, its unclear how relevant those platforms are. Thanks, Chris Elford Intel Middleware Products Division -Original Message- From: Rana Dasgupta [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 10:51 AM To: harmony-dev@incubator.apache.org Subject: Re: [general] platform support Hi Mikhail, As far as I know, SetUnhandledExceptionFilter was introduced as a backdoor method in in Win2K SP4 to get around the problem that the SEH handlers are limited to the frame and not process wide. It does handle problems like NPE and AV, but as you point out, it works by hijacking the first and last chance debugger handlers. So, unlike VEH which are fully functional when debugging, these SetUnhandled...filters are not visible when debugging. I also believe that they execute in the context of the current thread, which means that they are not so good to handle stack corruption, SOE etc. which we are currently using VEH. Since one does not expect them to be used on the newer Windows boxes, the .Net framework overwrites them ...which means that any process that loads a Microsoft dll that has any Microsoft managed code in it ( and many do ), is at a risk that the SetUnhandled.. may or may not work. I think that SetUnhandled..was a great(probably only ) solution on the Win2K boxes, but VEH was put in place to solve some of its limitations. The bottom line is that one needs to experiment with this on several Windows boxes before we know how good or bad it is. I myself don't have a lot of experience with it. Thanks, Rana On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: **Using SetUnhandledExceptionFilter API call we can handle hardware NPE for Win2k too. The only problem is debbuging of applications with exception filter installed. AFAIK debugger will catch all of these events. - 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] HARMONY-956 - problem w/ DRLVM classloader
Geir, can you please add that patch to the JIRA entry? It's not a patch, but a bug workaround or better to say - dirty hack. I'd better try to solve the core problem and provide the proper patch in few days. -- 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: Re: Re: Re: Re: Re: Re: [classlib][pack200] Status update
Cool, thanks. On 11/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Done in 430723 Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Helper inlining in JIT
MIkhail, I have some questions, or just arguments :-) First, though it is nice to talk of an open helper inlining framework to call VM/GC helpers, isn't the set of helpers used in JVM's more or less well known and standardized? In other words, is a framework absolutely necessary, can't the jit just generate code inline for the known fastpath of the helper algorithm? For example if we replaced the DRLVM gc with gc_new , how many new helpers do you think we would introduce? Also, please see below for some inline comments... On 8/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Even this simple helper reveals a lot of features to support: 1) Access to TLS is required. It could be fs:[14h] on Windows or helper call on Linux (depends on kernel (?) ). Even if we have an access to TLS we need to know the offsets of our slots: 'current' and 'ceiling' in example. So we need to have a way to pass these values to JIT. May be a 'private static final' variables in the helper's class with special runtime annotations could be used to pass the values to JIT? So basically, every new VM would need to implement the helper in an almost identical way or at least using identical final variables...I wonder how much flexibility that leaves .. 2) Calls support is needed. Both for slow helper version and to access TLS. This means also that calling convention support is needed. Runtime level annotations for helper calls could be used here. E.g. create a magic method 'slow_alloc' and teach JIT to call real helper instead of it. Get the calling convention info from annotation (?) Is it not possible for the fastpath helper to just return a failure so that the jit generated conventional helper callpath can kick in. In other words, does the slow helper have to be called from the fast helper? 3) Do we really want to expose native regs to Java: EAX, ECX... I vote do not to use them when writing helpers in Java and to allow to JIT to optimize unboxed operations (allocate registers by itself) This again goes back to my original question...if the JIT knew the standard fastpath, it could generate code optimally for it anyway with the best use of registers? These are just arguments before we set off developing a framework. I would like to know if helpers vary a lot across VM implementations, seems to me they need to do the same old things. Even if a framework is needed, it seems that we will land up inventing a language with unboxed primitives, virtual register access and special calling conventions for it to work optimally. And then we want every VM to use this language to code fastpath helpers and also to code the slower helpers in the conventional way. Maybe we should ask VM developers to vote on how open this is Thanks, Rana
