Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
BWT, HARMONY-1809 should be marked as non-bug difference from RI. I don't think that it's non-bug diff since it fixes an API issue. On 11/8/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 11/8/06, Ivanov, Alexey A wrote: Stepan, I must be missing something obvious... What kind of regression test do you expect? My logic is quite straightforward: the best way to fix a decision is to create a regression test. For example, if another volunteer find out that Harmony implementation of GapContent differ from RI's and propose a patch to fix it will any test remind him (or committer) about the decision? In our case we decided not to follow RI and do nothing for invalid parameters. So a regression test should verify that Harmony silently ignores bad parameters. BWT, HARMONY-1809 should be marked as non-bug difference from RI. Thanks, Stepan. What was done is the signature of the GapContent.replace had been changed so that it didn't contain 'throws BadLocationException' clause. What is a regression test to demonstrate? That BadLocationException is not thrown any more? Or do you insist on setting gapStart to -2 after call replace(-2, 2, null, 0), so that any subsequent operation on GapContent generates ArrayIndexOutOfBounds? Regards, Alexey. P.S. The discussion thread: http://thread.gmane.org/gmane.comp.java.harmony.devel/17837/focus=17837 The related JIRA issues: https://issues.apache.org/jira/browse/HARMONY-1809 https://issues.apache.org/jira/browse/HARMONY-1975 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Stepan Mishura [mailto: [EMAIL PROTECTED] ] Sent: Wednesday, November 08, 2006 9:12 AM To: harmony-dev Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java Hi, Any chance to see regression test (that I asked for in HARMONY-1975)? :-) Thanks, Stepan. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 7:50 PM To: [EMAIL PROTECTED] Subject: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java /com m on/javax/swing/text/GapContent.java Author: apetrenko Date: Tue Nov 7 05:50:07 2006 New Revision: 472115 URL: http://svn.apache.org/viewvc?view=revrev=472115 Log: Patch for HARMONY-1809 [classlib][swing]javax.swing.text.GapContent.replace(int, int, java.lang.Object, int) throws unspescified BadLocationException Modified: incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm o n/javax/swing/text/GapContent.java SNIP -- Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
+1. Silently doing nothing if invalid parameters are passed seems to me a right behavior in this case. Will someone apply changes to GapContent from the harmony-1975.patch or we need to make a separate patch for this? On 11/2/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/11/2, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, I've started fixing HARMONY-1809. To remove throws clause from the declaration of replace method, as it was proposed by Oleg in HARMONY-1975, I placed removeItems() and insertItems() calls into try-catch block. This would work OK for any valid arguments. I was going to handle invalid arguments by making adjustments so that the following removeItems() and insertItems() will not throw the exception. After I wrote several tests, I faced strange behaviour of RI with regards to invalid arguments to replace. (The Javadoc say nothing about which valid ranges for replace() parameters as well as any exceptions.) RI accepts invalid arguments but the result differs from what I'd expect. For example, if the content has text in it, I'd expect that content.replace(-2, 4, null, 0) would give xt as the result. I mean the invalid start position is adjusted to 0, and the length of remove is adjusted to be 2 accordingly. But this is not the case. As the result of this call, all characters are removed leaving in the content. Moreover the content object becomes unusable after that: content.insertString(0, 1) throws ArrayIndexOutOfBoundsException. Similarly if number of characters to be removed is greater than the length of the content (content.replace(2, 4, null, 0) with text in it), the object will throw ArrayIndexOutOfBoundsException when doing insertString. Considering the fact that GapContent is pretty low-level class in text representation model and that it is protected, I think that Harmony implementation can silently ignore BadLocationException possible thrown from insertItems() and removeItems(). Taking into account erroneous behaviour of RI's replace, we can do that until an application is broken. +1 for this solution. SY, Alexey As another option, we can throw an Error from catch block to make application which depends on implementation of replace() fast-fail. Any objections, comments, opinions? Thanks, Alexey. P.S. The related JIRA issues: https://issues.apache.org/jira/browse/HARMONY-1809 https://issues.apache.org/jira/browse/HARMONY-1975 GapContent Javadoc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division
Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
Yes, but the GapContent changes were not applied. On 11/2/06, Alexey Petrenko [EMAIL PROTECTED] wrote: HARMONY-1975is already applied and closed ;) 2006/11/2, Alexey Petrenko [EMAIL PROTECTED]: I'll take care of 1975. SY, Alexey 2006/11/2, Oleg Khaschansky [EMAIL PROTECTED]: +1. Silently doing nothing if invalid parameters are passed seems to me a right behavior in this case. Will someone apply changes to GapContent from the harmony-1975.patch or we need to make a separate patch for this? On 11/2/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/11/2, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, I've started fixing HARMONY-1809. To remove throws clause from the declaration of replace method, as it was proposed by Oleg in HARMONY-1975, I placed removeItems() and insertItems() calls into try-catch block. This would work OK for any valid arguments. I was going to handle invalid arguments by making adjustments so that the following removeItems() and insertItems() will not throw the exception. After I wrote several tests, I faced strange behaviour of RI with regards to invalid arguments to replace. (The Javadoc say nothing about which valid ranges for replace() parameters as well as any exceptions.) RI accepts invalid arguments but the result differs from what I'd expect. For example, if the content has text in it, I'd expect that content.replace(-2, 4, null, 0) would give xt as the result. I mean the invalid start position is adjusted to 0, and the length of remove is adjusted to be 2 accordingly. But this is not the case. As the result of this call, all characters are removed leaving in the content. Moreover the content object becomes unusable after that: content.insertString(0, 1) throws ArrayIndexOutOfBoundsException. Similarly if number of characters to be removed is greater than the length of the content (content.replace(2, 4, null, 0) with text in it), the object will throw ArrayIndexOutOfBoundsException when doing insertString. Considering the fact that GapContent is pretty low-level class in text representation model and that it is protected, I think that Harmony implementation can silently ignore BadLocationException possible thrown from insertItems() and removeItems(). Taking into account erroneous behaviour of RI's replace, we can do that until an application is broken. +1 for this solution. SY, Alexey As another option, we can throw an Error from catch block to make application which depends on implementation of replace() fast-fail. Any objections, comments, opinions? Thanks, Alexey. P.S. The related JIRA issues: https://issues.apache.org/jira/browse/HARMONY-1809 https://issues.apache.org/jira/browse/HARMONY-1975 GapContent Javadoc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division
Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
Could you, please, look at the unit test in #1809 also? On 11/2/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Yes, but the GapContent changes were not applied. On 11/2/06, Alexey Petrenko [EMAIL PROTECTED] wrote: HARMONY-1975is already applied and closed ;) 2006/11/2, Alexey Petrenko [EMAIL PROTECTED]: I'll take care of 1975. SY, Alexey 2006/11/2, Oleg Khaschansky [EMAIL PROTECTED]: +1. Silently doing nothing if invalid parameters are passed seems to me a right behavior in this case. Will someone apply changes to GapContent from the harmony-1975.patch or we need to make a separate patch for this? On 11/2/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/11/2, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, I've started fixing HARMONY-1809. To remove throws clause from the declaration of replace method, as it was proposed by Oleg in HARMONY-1975, I placed removeItems() and insertItems() calls into try-catch block. This would work OK for any valid arguments. I was going to handle invalid arguments by making adjustments so that the following removeItems() and insertItems() will not throw the exception. After I wrote several tests, I faced strange behaviour of RI with regards to invalid arguments to replace. (The Javadoc say nothing about which valid ranges for replace() parameters as well as any exceptions.) RI accepts invalid arguments but the result differs from what I'd expect. For example, if the content has text in it, I'd expect that content.replace(-2, 4, null, 0) would give xt as the result. I mean the invalid start position is adjusted to 0, and the length of remove is adjusted to be 2 accordingly. But this is not the case. As the result of this call, all characters are removed leaving in the content. Moreover the content object becomes unusable after that: content.insertString(0, 1) throws ArrayIndexOutOfBoundsException. Similarly if number of characters to be removed is greater than the length of the content (content.replace(2, 4, null, 0) with text in it), the object will throw ArrayIndexOutOfBoundsException when doing insertString. Considering the fact that GapContent is pretty low-level class in text representation model and that it is protected, I think that Harmony implementation can silently ignore BadLocationException possible thrown from insertItems() and removeItems(). Taking into account erroneous behaviour of RI's replace, we can do that until an application is broken. +1 for this solution. SY, Alexey As another option, we can throw an Error from catch block to make application which depends on implementation of replace() fast-fail. Any objections, comments, opinions? Thanks, Alexey. P.S. The related JIRA issues: https://issues.apache.org/jira/browse/HARMONY-1809 https://issues.apache.org/jira/browse/HARMONY-1975 GapContent Javadoc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
Yes, I missed this. I think it is possible to use FreeType library for the font rendering both on linux and on windows. At present we are using xft on linux, but I think it is possible to refactor this to the pure freetype code. It may take less efforts than implementing font rasterizer from the scratch. Another issue is that we must have fonts themselves for this. Can we distribute system fonts (e.g. from linux) with harmony? It is a legal issue, I am not an expert in this area at all. On 10/26/06, Sergey Soldatov [EMAIL PROTECTED] wrote: There is a number of issues with headless support. And the serious one is font support. Our implementation uses system fonts, so in headless environment it could not initialize any font. RI uses own font rasterizer, so it doesn't have such problems. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: I am just checking a dependency. Don't think so. Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Could it be treated as a reverse engineering? I don't know :) On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: I don't know how it works, but what I can do is try to use headless without XOrg shared libs installed, and then take note of the missing .so modules the IBM JVM complains about). Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: If you mean libxlib, how it could be used without X server? Maybe some other library (e.g. font library like xft) simply preloads it during its initialization or tries to connect to the server (XOpenDisplay) to get some data, fails and uses defaults? Anyway, I think, testing on a headless environment will help us to determine the requirements. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: (e.g. for linux we need to exclude all xlib calls, right?). How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Regards, Martin Cordova On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ( [EMAIL PROTECTED]) -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com -- Sergey Soldatov
[classlib][imageio] Implementation of the missing imageio API.
A significant part of the imageio API is still missing according to the JAPI tool [1]. If noone will object I'll start implementing these methods/classes. Any concerns or help are welcome :) I created a parent JIRA for this task [2]. The first thing I am going to do are ImageWriter and ImageWriteParam missing methods (it seems to be a pretty simple task). [1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html [2] https://issues.apache.org/jira/browse/HARMONY-1982 thanks, Oleg
Re: [classlib][awt] Revision #465514 broke image decoders.
Since the ImageConsumer accepts Hashtable?,? my thought is that the the GifDecoder should declare the field based on what it actually uses. If the other decoders only use String keys and String values, then I would suggest we change the field declaration to match. Yes, it sounds reasonable. On 10/25/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Nathan, could you, please tell why you changed the field properties in these classes to HashtableObject,Object in two of them and to HashtableString,String in one of them (GifDecoder)? Look at the declaration in the ImageConsumer class: void setProperties(Hashtable?,? props) It'd be better to have Hashtable?,? as a type in all 3 classes and HashtableObject,Object as an initial value for this field. A field type of Hashtable?,? would be painful, as you can't perform any sets when a type variable is ?. You'd have to cast it to HashtableObject,Object before performing any sets. Since the ImageConsumer accepts Hashtable?,? my thought is that the the GifDecoder should declare the field based on what it actually uses. If the other decoders only use String keys and String values, then I would suggest we change the field declaration to match. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? Unfortunately, these classes are not covered with the unit tests. I was running a simple test application that did something like this: Toolkit.getDefaultToolkit().getImage(image.jpg); and if failed with a NPE. I removed the final modifiers At the first glance it seems like the problem doesn't appear any more. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? Only final fields. No other issues. But 3-4 in 3 classes - it is alot for me :) On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: I removed the final modifiers; this only affected PngDecoder, GifDecoder and JpegDecoder. I missed the comments in the fields of JpegDecoder, that was my mistake. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? -Nathan On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? I'll remove the final modifiers. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hi, Rev. 465514 introduced a lot of invalid modifications to the GifDecoder, PngDecoder and JpegDecoder. There were a number of fields modified or initialized from the native code only, but they were redeclared as final, so the decoders doesn't work properly any more. This revision has the following comment: Cleanup code * Add if/else braces * Add missing annotations * Add type variables * Use foreach loops * etc I'd suggest to roll back this revision and redo the cleanup in the more accurate way. Thanks, Oleg
Re: [snapshot] Questions about next snapshot...
3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin
Re: [snapshot] Questions about next snapshot...
As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? Also.. Martin... want to help? :) geir Oleg Khaschansky wrote: 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin
Re: [snapshot] Questions about next snapshot...
Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? If so, we are just a step away for supporting headless? No. It is not so. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? If so, we are just a step away for supporting headless? Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless On 10/25/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: As Tim asked earlier in the thread... is there a clear definition of what this means? A spec maybe? Also.. Martin... want to help? :) geir Oleg Khaschansky wrote: 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. Definitely, headless support will be implemented in the future and there are no obstacles which prevent us from doing this. But I don't know when exactly it will be done, this requires some efforts and we still have other things in the todo list. On 10/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Martin Cordova wrote: 1.- Have a planned date? None yet, but doing this week would be good. Any other opinions? 2.- Will include latest aproved contributions (ImageIO) Only if they have been integrated into the SVN codebase 3.- Will be possible to create graphics in awt-headless mode? I would like to test servlets generating charts (using JFreeCharts) in a Linux box without a graphics environment. I dunno :) geir Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
If you mean libxlib, how it could be used without X server? Maybe some other library (e.g. font library like xft) simply preloads it during its initialization or tries to connect to the server (XOpenDisplay) to get some data, fails and uses defaults? Anyway, I think, testing on a headless environment will help us to determine the requirements. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: (e.g. for linux we need to exclude all xlib calls, right?). How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Regards, Martin Cordova On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: [classlib][awt] headless support (was: Re: [snapshot] Questions about next snapshot...)
Could it be treated as a reverse engineering? I don't know :) On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: I don't know how it works, but what I can do is try to use headless without XOrg shared libs installed, and then take note of the missing .so modules the IBM JVM complains about). Regards, Martin On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: If you mean libxlib, how it could be used without X server? Maybe some other library (e.g. font library like xft) simply preloads it during its initialization or tries to connect to the server (XOpenDisplay) to get some data, fails and uses defaults? Anyway, I think, testing on a headless environment will help us to determine the requirements. On 10/25/06, Martin Cordova [EMAIL PROTECTED] wrote: (e.g. for linux we need to exclude all xlib calls, right?). How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Regards, Martin Cordova On 10/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. I don't think that spec for this exists. Another document on this is [1]. It describes what can and what cannot be done in headless mode. But we also have the list of methods which throw HeadlessException (from the API spec). Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? This is only a part of a task. We may also need to guard native initialization code which depends on system configuration with isHeadless checks (just skip it in headless mode). And, probably, provide an alternative simplified implementation for some awt code which could be called in headless mode to prevent from falling into hardware-dependent native code (e.g. for linux we need to exclude all xlib calls, right?). [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ On 10/25/06, Tim Ellison [EMAIL PROTECTED] wrote: Martin Cordova wrote: Oleg, I just read it, does this mean that all methods that don't need to throw the special Headless exception, are ready to work in headless mode? Right, that is my question too. I've seen the general description at the URL Oleg sent, it's hardly a spec tho'. Presumably it is easier for us to find all the methods that are declared to throw a HeadlessException, and put in the isHeadless() test right now, so we can have a compliant headless implementation before the GUI is completed? If so, we are just a step away for supporting headless? well we still have to get all the imageIO, print, font and other code working that is required in headless mode. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com
Re: [classlib][awt] headless support
Theoretically, they should be loaded on demand, i.e. when dlopen is called. If they dlopen them at initialization step then - yes. But loading library and then not using it is not very smart behavior, IMO. On 10/25/06, Gregory Shimansky [EMAIL PROTECTED] wrote: Martin Cordova wrote: (e.g. for linux we need to exclude all xlib calls, right?). How implemented IBM their headless stuff? In their case it's a requirement to have XOrg shared libraries installed to have headless working. In order distros it was XFree libs. No need for an X server, just the libs. Could it be that native code is simply linked to these libraries so native awt code libraries just don't load if you don't have X libraries in the system? -- Gregory Shimansky, Intel Middleware Products Division
[classlib][awt] Revision #465514 broke image decoders.
Hi, Rev. 465514 introduced a lot of invalid modifications to the GifDecoder, PngDecoder and JpegDecoder. There were a number of fields modified or initialized from the native code only, but they were redeclared as final, so the decoders doesn't work properly any more. This revision has the following comment: Cleanup code * Add if/else braces * Add missing annotations * Add type variables * Use foreach loops * etc I'd suggest to roll back this revision and redo the cleanup in the more accurate way. Thanks, Oleg
Re: [classlib][awt] Revision #465514 broke image decoders.
Where are the tests for these decoders? How did you determine that they no longer worked? Unfortunately, these classes are not covered with the unit tests. I was running a simple test application that did something like this: Toolkit.getDefaultToolkit().getImage(image.jpg); and if failed with a NPE. I removed the final modifiers At the first glance it seems like the problem doesn't appear any more. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? Only final fields. No other issues. But 3-4 in 3 classes - it is alot for me :) On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: I removed the final modifiers; this only affected PngDecoder, GifDecoder and JpegDecoder. I missed the comments in the fields of JpegDecoder, that was my mistake. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? -Nathan On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? I'll remove the final modifiers. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hi, Rev. 465514 introduced a lot of invalid modifications to the GifDecoder, PngDecoder and JpegDecoder. There were a number of fields modified or initialized from the native code only, but they were redeclared as final, so the decoders doesn't work properly any more. This revision has the following comment: Cleanup code * Add if/else braces * Add missing annotations * Add type variables * Use foreach loops * etc I'd suggest to roll back this revision and redo the cleanup in the more accurate way. Thanks, Oleg
Re: [classlib][awt] Revision #465514 broke image decoders.
Nathan, could you, please tell why you changed the field properties in these classes to HashtableObject,Object in two of them and to HashtableString,String in one of them (GifDecoder)? Look at the declaration in the ImageConsumer class: void setProperties(Hashtable?,? props) It'd be better to have Hashtable?,? as a type in all 3 classes and HashtableObject,Object as an initial value for this field. On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? Unfortunately, these classes are not covered with the unit tests. I was running a simple test application that did something like this: Toolkit.getDefaultToolkit().getImage(image.jpg); and if failed with a NPE. I removed the final modifiers At the first glance it seems like the problem doesn't appear any more. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? Only final fields. No other issues. But 3-4 in 3 classes - it is alot for me :) On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: I removed the final modifiers; this only affected PngDecoder, GifDecoder and JpegDecoder. I missed the comments in the fields of JpegDecoder, that was my mistake. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? -Nathan On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? I'll remove the final modifiers. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hi, Rev. 465514 introduced a lot of invalid modifications to the GifDecoder, PngDecoder and JpegDecoder. There were a number of fields modified or initialized from the native code only, but they were redeclared as final, so the decoders doesn't work properly any more. This revision has the following comment: Cleanup code * Add if/else braces * Add missing annotations * Add type variables * Use foreach loops * etc I'd suggest to roll back this revision and redo the cleanup in the more accurate way. Thanks, Oleg
Re: [classlib][awt] Revision #465514 broke image decoders.
It'd be better to have Hashtable?,? as a type in all 3 classes and HashtableObject,Object as an initial value for this field. I mean that it is not an error but it seems to me semantically more meaningful On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Nathan, could you, please tell why you changed the field properties in these classes to HashtableObject,Object in two of them and to HashtableString,String in one of them (GifDecoder)? Look at the declaration in the ImageConsumer class: void setProperties(Hashtable?,? props) It'd be better to have Hashtable?,? as a type in all 3 classes and HashtableObject,Object as an initial value for this field. On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? Unfortunately, these classes are not covered with the unit tests. I was running a simple test application that did something like this: Toolkit.getDefaultToolkit().getImage(image.jpg); and if failed with a NPE. I removed the final modifiers At the first glance it seems like the problem doesn't appear any more. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? Only final fields. No other issues. But 3-4 in 3 classes - it is alot for me :) On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: I removed the final modifiers; this only affected PngDecoder, GifDecoder and JpegDecoder. I missed the comments in the fields of JpegDecoder, that was my mistake. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? -Nathan On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? I'll remove the final modifiers. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hi, Rev. 465514 introduced a lot of invalid modifications to the GifDecoder, PngDecoder and JpegDecoder. There were a number of fields modified or initialized from the native code only, but they were redeclared as final, so the decoders doesn't work properly any more. This revision has the following comment: Cleanup code * Add if/else braces * Add missing annotations * Add type variables * Use foreach loops * etc I'd suggest to roll back this revision and redo the cleanup in the more accurate way. Thanks, Oleg
Re: [classlib][awt] Revision #465514 broke image decoders.
Unit tests for the decoders are up there in [1] [1] https://issues.apache.org/jira/browse/HARMONY-1954 On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: That's the start of a unit test, are you going to finish it? ;-) Well, I'll look into this. We need to put a couple of images for this kind of test somewhere... But not a lot compared to the number of cleanup changes Nathan has been busy making! Right, I am sorry. This cleanup is a great work. I suggested to roll back because I thought that there could be other places with similar issues that could have been missed. AWT has a lot of native code, so refactorings should be done with this in mind. The test coverage for AWT is quite poor, in comparison with the undelying functionality, it's quite easy to introduce a new bug in it. On 10/24/06, Mark Hindess [EMAIL PROTECTED] wrote: On 24 October 2006 at 18:25, Oleg Khaschansky [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? Unfortunately, these classes are not covered with the unit tests. I was running a simple test application that did something like this: Toolkit.getDefaultToolkit().getImage(image.jpg); and if failed with a NPE. That's the start of a unit test, are you going to finish it? ;-) I removed the final modifiers At the first glance it seems like the problem doesn't appear any more. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? Only final fields. No other issues. But 3-4 in 3 classes - it is alot for me :) But not a lot compared to the number of cleanup changes Nathan has been busy making! Regards, Mark. On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: I removed the final modifiers; this only affected PngDecoder, GifDecoder and JpegDecoder. I missed the comments in the fields of JpegDecoder, that was my mistake. There were only 3-4 other fields that were finalized. Your email mentioned a lot of invalid modifications; what are the other issues, specifically? -Nathan On 10/24/06, Nathan Beyer [EMAIL PROTECTED] wrote: Where are the tests for these decoders? How did you determine that they no longer worked? I'll remove the final modifiers. -Nathan On 10/24/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hi, Rev. 465514 introduced a lot of invalid modifications to the GifDecoder, PngDecoder and JpegDecoder. There were a number of fields modified or initialized from the native code only, but they were redeclared as final, so the decoders doesn't work properly any more. This revision has the following comment: Cleanup code * Add if/else braces * Add missing annotations * Add type variables * Use foreach loops * etc I'd suggest to roll back this revision and redo the cleanup in the more accurate way. Thanks, Oleg
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! Great news! Sorry for being a bit outdated - I was on vacations last week. On 10/18/06, Nathan Beyer [EMAIL PROTECTED] wrote: Congratulations to all the new committers. -N On 10/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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][swing] Generification of the swing API.
The next patch which generifies the rest of swing is ready. A couple of swing unit tests were updated. http://issues.apache.org/jira/browse/HARMONY-1803 On 10/6/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 10/6/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: I am happy to inform that I created a jira #1758 [1] for this task and attached a first patch. Good news, Oleg! Thaks for doing this. Regards, Ilya. Also, I'd like to attract attention to several patches for the awt/swing modules: swing #1536 #1533 #1509 #1475 awt #1647 #1652 #1659 [1] http://issues.apache.org/jira/browse/HARMONY-1758 On 10/5/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: If no one objects I'll generify javax.swing to improve API indicators. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ilya Okomin Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][concurrent] Implementation of the CopyOnWriteArrayList class.
Could you, please, send the compiler output for these errors? On 10/13/06, Stepan Mishura [EMAIL PROTECTED] wrote: BTW, I stumbled over this class when I tried to build Classlib with Harmony snapshot - it doesn't compile. I did the following: 1) set JAVA_HOME=C:\Apache\Harmony\snapshot\harmony-hdk-r450941\jdk\jre 2) ant -Dhy.javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter The build fails with compile errors. And if I revert Tim's commit back everything goes fine: $ svn up -r462578 modules/concurrent/src/main/java/java/util/concurrent/CopyOnWriteArrayList.java U modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java Updated to revision 462578. Did anyone try this? Thanks, Stepan. On 10/10/06, Oleg Khaschansky wrote: I uploaded a patch which implements CopyOnWriteArrayList class. Committers, please, take a look at [1]. I also ensured that CopyOnWriteArrayListTest passes with this implementation. [1] http://issues.apache.org/jira/browse/HARMONY-1805 -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [app] jEdit on Harmony
#1867 from your list looks very much like #1699 (see [1]). [1] http://issues.apache.org/jira/browse/HARMONY-1699 On 10/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I'm going to spend some time to run jEdit [1] on Harmony. I've tried it with IBM VME and DRL VM on Windows. 1. IBM VME: jEdit installer works OK except of licences showing (missed html text). jEdit itself starts OK, all menus and dialogs are working. But after pressing Enter button on text editing area it throws NPE [2] and hangs. I've found a fix for this issue but could not minimize testcase yet. After the fix jEdit works OK. At least I could not find the situation where it fails... yet... :) The only remaining problem is that some fonts looks ugly on editing area while all off them looks OK in font chooser. This issue need future investigation. 2. DRLVM: Here is much more problems :( First of all you need to apply latest DRLVM patches [3], [4], [5] and [6]. After that it starts, opens a main window. But VM crashes after pressing any button on text editing area. I'll create a JIRA issue... BTW. Can someone of the committers take a look at issues [3], [4], [5] and [6]? It looks like must have patches for all the GUI applications. Thanks in advance. SY, Alexey [1] http://jedit.org [2] http://issues.apache.org/jira/browse/HARMONY-1867 [3] http://issues.apache.org/jira/browse/HARMONY-1592 [4] http://issues.apache.org/jira/browse/HARMONY-1816 [5] http://issues.apache.org/jira/browse/HARMONY-1823 [6] http://issues.apache.org/jira/browse/HARMONY-1741 -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [app] jEdit on Harmony
I suggest to mark 1699 as duplicate of 1867 since 1867 has a patch already :) Agree. On 10/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Great! Thanks! It's really a duplicate. I suggest to mark 1699 as duplicate of 1867 since 1867 has a patch already :) And your testcase from 1699 can be used as minimized testcase for 1867. SY, Alexey 2006/10/13, Oleg Khaschansky [EMAIL PROTECTED]: #1867 from your list looks very much like #1699 (see [1]). [1] http://issues.apache.org/jira/browse/HARMONY-1699 On 10/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I'm going to spend some time to run jEdit [1] on Harmony. I've tried it with IBM VME and DRL VM on Windows. 1. IBM VME: jEdit installer works OK except of licences showing (missed html text). jEdit itself starts OK, all menus and dialogs are working. But after pressing Enter button on text editing area it throws NPE [2] and hangs. I've found a fix for this issue but could not minimize testcase yet. After the fix jEdit works OK. At least I could not find the situation where it fails... yet... :) The only remaining problem is that some fonts looks ugly on editing area while all off them looks OK in font chooser. This issue need future investigation. 2. DRLVM: Here is much more problems :( First of all you need to apply latest DRLVM patches [3], [4], [5] and [6]. After that it starts, opens a main window. But VM crashes after pressing any button on text editing area. I'll create a JIRA issue... BTW. Can someone of the committers take a look at issues [3], [4], [5] and [6]? It looks like must have patches for all the GUI applications. Thanks in advance. SY, Alexey [1] http://jedit.org [2] http://issues.apache.org/jira/browse/HARMONY-1867 [3] http://issues.apache.org/jira/browse/HARMONY-1592 [4] http://issues.apache.org/jira/browse/HARMONY-1816 [5] http://issues.apache.org/jira/browse/HARMONY-1823 [6] http://issues.apache.org/jira/browse/HARMONY-1741 -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ICU4C gurus? (was: [jira] Commented: (HARMONY-100) text/BidiWrapper issue?)
What exactly your code is? It, probably, may rearrange the levels if
you didn't explicitely set them for all the characters including
trailing whitespace. If this is the case it may add some additional
levels and relocate the array. Could you check if the size of the
array changed?
On 10/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Is any ICU4C gurus here?
I'm setting an embedding levels pointer with ubidi_setPara method. And
it seems that ubidi_getLevels returns not the same pointer.
Is this correct feeling or am I doing something wrong?
SY, Alexey
2006/10/11, Alexey Petrenko (JIRA) [EMAIL PROTECTED]:
[
http://issues.apache.org/jira/browse/HARMONY-100?page=comments#action_12441378 ]
Alexey Petrenko commented on HARMONY-100:
-
I agree with Tim's suggestion and will create a patch.
text/BidiWrapper issue?
---
Key: HARMONY-100
URL: http://issues.apache.org/jira/browse/HARMONY-100
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Gorr
Let's consider the following test:
import java.text.Bidi;
public class Test {
public static void main(String[] args) throws Exception {
Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0,
new byte[] { (byte) -7, (byte) -2, (byte) -3
},
0, 3, Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Expected 7, real + +
bd.getLevelAt(0));
}
}
In my opinion the JNI implementation of Bidi (text/BidiWrapper.c file,
ubidi_1setPara() function) contains a potential bug, namely:
1. If the embeddingLevels argument is not NULL then _embeddingLevels
variable is initialized with the JNI GetByteArrayElements() function;
2. ICU function (ubidi_setPara) initializes ICU inner structure and puts
the _embeddingLevels into it;
3. If _embeddingLevels pointer is not NULL then the JNI
ReleaseByteArrayElements() function (with 0 as fourth parameter) is called.
This function releases the memory (according to JNI specification) the
_embeddingLevels pointer refers to;
4. After that ICU inner structure isn't initialized properly. Call of ICU
ubidi_getLevels() function can return incorrect values (see java test above).
It seems the JNI_COMMIT parameter instead of 0 should be passed to the
ReleaseByteArrayElements() to avoid this problem.
I'd like to underline the test mentioned above works w/o any issues for
Harmony-14 contribution (although it shouldn't sometimes IMHO).
Therefore if there are any doubts in my argumentation this issue can be
closed as invalid.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ICU4C gurus? (was: [jira] Commented: (HARMONY-100) text/BidiWrapper issue?)
I think, the answer is yes, and you see exactly this situation.
On 10/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
In fact the most interesting question: can ubidi_getLevels return
another pointer or not? If there is such possibility then we need to
store original pointer somewhere.
2006/10/12, Oleg Khaschansky [EMAIL PROTECTED]:
What exactly your code is? It, probably, may rearrange the levels if
you didn't explicitely set them for all the characters including
trailing whitespace. If this is the case it may add some additional
levels and relocate the array. Could you check if the size of the
array changed?
On 10/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Is any ICU4C gurus here?
I'm setting an embedding levels pointer with ubidi_setPara method. And
it seems that ubidi_getLevels returns not the same pointer.
Is this correct feeling or am I doing something wrong?
SY, Alexey
2006/10/11, Alexey Petrenko (JIRA) [EMAIL PROTECTED]:
[
http://issues.apache.org/jira/browse/HARMONY-100?page=comments#action_12441378 ]
Alexey Petrenko commented on HARMONY-100:
-
I agree with Tim's suggestion and will create a patch.
text/BidiWrapper issue?
---
Key: HARMONY-100
URL: http://issues.apache.org/jira/browse/HARMONY-100
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vladimir Gorr
Let's consider the following test:
import java.text.Bidi;
public class Test {
public static void main(String[] args) throws Exception {
Bidi bd = new Bidi(new char[] { 's', 's', 's' }, 0,
new byte[] { (byte) -7, (byte) -2, (byte)
-3 },
0, 3,
Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Expected 7, real + +
bd.getLevelAt(0));
}
}
In my opinion the JNI implementation of Bidi (text/BidiWrapper.c file,
ubidi_1setPara() function) contains a potential bug, namely:
1. If the embeddingLevels argument is not NULL then _embeddingLevels
variable is initialized with the JNI GetByteArrayElements() function;
2. ICU function (ubidi_setPara) initializes ICU inner structure and
puts the _embeddingLevels into it;
3. If _embeddingLevels pointer is not NULL then the JNI
ReleaseByteArrayElements() function (with 0 as fourth parameter) is called.
This function releases the memory (according to JNI specification)
the _embeddingLevels pointer refers to;
4. After that ICU inner structure isn't initialized properly. Call of
ICU ubidi_getLevels() function can return incorrect values (see java test above).
It seems the JNI_COMMIT parameter instead of 0 should be passed to
the ReleaseByteArrayElements() to avoid this problem.
I'd like to underline the test mentioned above works w/o any issues for
Harmony-14 contribution (although it shouldn't sometimes IMHO).
Therefore if there are any doubts in my argumentation this issue can be
closed as invalid.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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] Problem attaching patch
I've just attached patch to JIRA You are a committer, that doesn't count :-) On 10/12/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've just attached patch to JIRA 2006/10/12, Tim Ellison [EMAIL PROTECTED]: Ivanov, Alexey A wrote: Then it looks more like JIRA configuration problem since many issues can't be attached files to. Does anyone know how to fix it? Committers? No, I don't. We share JIRA with other projects, so we need infra help. 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] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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][build] Failed to build classlib on r454714
You probably mean Windows version of lcms. There's the same code for linux and for windows in the lcmm native library, which glues lcms library with awt. As far as I recall, with 1.15 it will compile but fail on the first invocation at runtime (when the color conversion will occur). It wasn't tested with the older versions of lcms also. That's why 1.14 is the best choice. I though I need to install a newer lcms - now I'm happy to live with that. Yes, it compiles, may work and may not. There are no unit tests for the color conversion. No statements on required version for Linux. Right, the readme was modified before the contribution and it seems like this requirement was removed. Nothing changed in the code AFAIK, so 1.14 is still the best choice. I believe that it may compile with other versions (and, probably, that's why the 1.14 requirement was removed) but will it fail at runtime or not is unclear for the older ones. On 10/11/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: Thanks, Alexey! I though I need to install a newer lcms - now I'm happy to live with that. -Pavel On 10/11/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Just to assure that the fix Mark did is good - lcms1.0.12 works fine for me, all unit tests pass on J9. 2006/10/10, Mark Hindess [EMAIL PROTECTED]: On 10 October 2006 at 12:23, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Muahaha... didn't you just say this was something that never changed, was geological in stability, etc, etc? :) :-) Well, yeah, and I was worried until I saw that: a) the change to introduce this variable happened over two years ago, and b) my lucky guess was enough to fix it -Mark. Mark Hindess wrote: On 10 October 2006 at 16:22, Oleg Khaschansky [EMAIL PROTECTED] om wrote: It looks like you don't have lcms.h and, probably, other lcms stuff in Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\. I think the problem is more likely that they do have lcms but that they don't have the same version as everyone else. At a guess, I'd say that the version they are using doesn't have the cache that the cmsFLAGS_NOTCACHE flag is intended to switch off and that: #ifndef cmsFLAGS_NOTCACHE #define cmsFLAGS_NOTCACHE (0) #endif after the #include for lcms.h would solve the problem. But this is a complete guess. -Mark. Recently awt/swing build was enabled by default and it requires this dependency as well as png and jpeg. Read the instructions in Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt. Or check the recent posts about this. E.g. the following recent thread: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: I'm seeing the same problem. Thanks, Pavel On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Got the following compilation error (SLES 9 gcc 3.3.3): build-native: [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include -I/export/users2/avarlamo/l inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic -Icommon -I../shared//i nclude -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends / libs/build/lc ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTran s form': [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' undeclared (first use in th is function) [exec] ../shared/cmmxforms.c:150: error: (Each undeclared identifier is reported only on ce [exec] ../shared/cmmxforms.c:150: error: for each function it appear s in.) [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of `cmsSample3DGrid' from incom patible pointer type [exec] make: *** [../shared//cmmxforms.o] Error 1 BUILD FAILED - 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
[classlib][concurrent] Implementation of the CopyOnWriteArrayList class.
I uploaded a patch which implements CopyOnWriteArrayList class. Committers, please, take a look at [1]. I also ensured that CopyOnWriteArrayListTest passes with this implementation. [1] http://issues.apache.org/jira/browse/HARMONY-1805 - 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][build] Failed to build classlib on r454714
It looks like you don't have lcms.h and, probably, other lcms stuff in Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\. Recently awt/swing build was enabled by default and it requires this dependency as well as png and jpeg. Read the instructions in Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt. Or check the recent posts about this. E.g. the following recent thread: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: I'm seeing the same problem. Thanks, Pavel On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Got the following compilation error (SLES 9 gcc 3.3.3): build-native: [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include -I/export/users2/avarlamo/l inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic -Icommon -I../shared//i nclude -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depends/libs/build/lc ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTransform': [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' undeclared (first use in th is function) [exec] ../shared/cmmxforms.c:150: error: (Each undeclared identifier is reported only on ce [exec] ../shared/cmmxforms.c:150: error: for each function it appears in.) [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of `cmsSample3DGrid' from incom patible pointer type [exec] make: *** [../shared//cmmxforms.o] Error 1 BUILD FAILED - 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][build] Failed to build classlib on r454714
Hmm, when I was writing the initial version of that Harmony\enhanced\classlib\trunk\depends\libs\build\readme.txt, it was stated there that the only suitable version is lcms 1.14. But it changed alot since then. On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: The fix works for me, thanks! Patching cmmapi.h helped to build classlib. I also use liblcms 1.0.12. We should either state the minimal supported version of lib in the docs or patch the sources (what I think is better in this case). -Pavel On 10/10/06, Mark Hindess [EMAIL PROTECTED] wrote: On 10 October 2006 at 19:36, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: I have a symlink trunk/working_classlib/depends/libs/build/lcms/liblcms.ia32 - /usr/lib/liblcms.a and a good symlink to lcms.h in the same directory. png and jpeg dirs also contain valid symlinks. Do you think I still need to compile the libraries? I suspect you have an old version of lcms - that is, one that dates from before 2004(!) when the cmsFLAGS_NOTCACHE flags was added. Can you check what version you have installed? Regards, Mark. Thanks, Pavel On 10/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: It looks like you don't have lcms.h and, probably, other lcms stuff in Harmony\enhanced\classlib\trunk\depends\libs\build\lcms\. Recently awt/swing build was enabled by default and it requires this dependency as well as png and jpeg. Read the instructions in Harmony\enhanced\classlib\trunk\depends\libs\build\README.txt. Or check the recent posts about this. E.g. the following recent thread: [classlib][build]Lacks liblcms.a libpng.a and etc on Linux and recommend to add them to fetch-depends target On 10/10/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: I'm seeing the same problem. Thanks, Pavel On 10/10/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Got the following compilation error (SLES 9 gcc 3.3.3): build-native: [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT -DHYX86 -I/e xport/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/include -I/export/users2/avarlamo/l inux.ia32/svn-repo/classlib/deploy/jdk/include -I. -I../shared/ -fpic -Icommon -I../shared//i nclude -I/export/users2/avarlamo/linux.ia32/svn-repo/classlib/deploy/../depend s/libs/build/lc ms -c -o ../shared//cmmxforms.o ../shared//cmmxforms.c [exec] ../shared/cmmxforms.c: In function `cmmCreateMultiprofileTra nsform': [exec] ../shared/cmmxforms.c:150: error: `cmsFLAGS_NOTCACHE' undeclared (first use in th is function) [exec] ../shared/cmmxforms.c:150: error: (Each undeclared identifier is reported only on ce [exec] ../shared/cmmxforms.c:150: error: for each function it appea rs in.) [exec] ../shared/cmmxforms.c:181: warning: passing arg 2 of `cmsSample3DGrid' from incom patible pointer type [exec] make: *** [../shared//cmmxforms.o] Error 1 BUILD FAILED - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-1763) [classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
Alexei,
Thank you for paying your attention to this. The patch is already
applied, sorry. Anyway, the suggested code is not significantly
different, IMO. Actually, I tend to make minimal modifications to the
original code when possible.
On 10/6/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Oleg,
Can we write the same logic a little bit nicer?
Something like:
public boolean equals(Object object) {
-boolean result = (object != null object instanceof
PropertyDescriptor);
-if (result) {
+boolean result = false;
+
+if (object != null object instanceof PropertyDescriptor) {
PropertyDescriptor pd = (PropertyDescriptor) object;
Anyway +1 for the patch in general, thank you for finding this!
Regards,
2006/10/6, Oleg Khaschansky [EMAIL PROTECTED]:
According to the good issue resolution guideline I am forwarding
this to the dev. list.
-- Forwarded message --
From: Oleg Khaschansky (JIRA) [EMAIL PROTECTED]
Date: Oct 6, 2006 8:58 PM
Subject: [jira] Updated: (HARMONY-1763) [classlib][beans] method
java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
To: [EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/HARMONY-1763?page=all ]
Oleg Khaschansky updated HARMONY-1763:
--
Attachment: harmony-1763.patch
Patch for this issue rev. 453254.
[classlib][beans] method java.beans.PropertyDescriptor.equals(Object)
throws ClassCastException
---
Key: HARMONY-1763
URL: http://issues.apache.org/jira/browse/HARMONY-1763
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Oleg Khaschansky
Priority: Minor
Attachments: harmony-1763-test.patch, harmony-1763.patch
The test below throws ClassCastException on Harmony but passes on RI.
I will provide a patch for this issue and a unit test.
import java.beans.*;
import java.lang.reflect.*;
public class Test {
public static void main(String[] args) {
PropertyDescriptor toRet = null;
try {
toRet = new PropertyDescriptor(p, Bean.class );
toRet.setBound( true );
} catch (IntrospectionException e) {
e.printStackTrace();
}
Method m = null;
try {
m = HelpClass.class.getDeclaredMethod(f_static,
(Class[])null);
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
toRet.equals(m);
System.out.println(PASSED);
}
}
class Bean {
public void setP(int i) {}
public int getP() {return 0;}
}
class HelpClass {
public HelpClass () {}
public static void f_static () {}
}
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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][test] Failure in swing test
I will take a look at this. On 10/8/06, Tim Ellison [EMAIL PROTECTED] wrote: I see a failure on IA32 Win XP tests at r454168 (after applying the TransferHandler patch). The walkback is: junit.framework.AssertionFailedError: expected:0 but was:7 at javax.swing.SpinnerDateModelTest.testSpinnerDateModel(SpinnerDateModelTest.java:59) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115) at javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:120) at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133) at java.lang.Thread.run(Thread.java:872) I'll take a look later unless somebody picks it up. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][test] Failure in swing test
Tim, I can't see this failure at r454268. Anyone else see it? Maybe rebuild will help? I also looked into SpinnerDateModelTest source and it doesn't seems to me that it could be related to the TransferHandler. -- Oleg On 10/9/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: I will take a look at this. On 10/8/06, Tim Ellison [EMAIL PROTECTED] wrote: I see a failure on IA32 Win XP tests at r454168 (after applying the TransferHandler patch). The walkback is: junit.framework.AssertionFailedError: expected:0 but was:7 at javax.swing.SpinnerDateModelTest.testSpinnerDateModel(SpinnerDateModelTest.java:59) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115) at javax.swing.BasicSwingTestCase.runBareImpl(BasicSwingTestCase.java:120) at javax.swing.BasicSwingTestCase$1.run(BasicSwingTestCase.java:133) at java.lang.Thread.run(Thread.java:872) I'll take a look later unless somebody picks it up. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
Ok. I am testing another patch for the TransferHandler which won't affect beans.
On 10/6/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Hi Oleg,
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case.
Well, the specification states here:
==
public PropertyDescriptor(String propertyName,
Class? beanClass,
String readMethodName,
String writeMethodName)
throws IntrospectionException
...
Parameters:
...
readMethodName - The name of the method used for reading the
property value. May be null if the property is write-only.
writeMethodName - The name of the method used for writing the
property value. May be null if the property is read-only.
Throws:
IntrospectionException - if an exception occurs during introspection.
==
So we have the description of the valid parameter case, null parameter
case and the exception that can be thrown. IMHO the natural conclusion
from that is that the exception will be thrown in case of invalid
parameter. Moreover, if the implementation does not validate method
names it will never throw IntrospectionException. But it is described
by the spec.
BTW, PropertyDescriptor(String, Method, Method) validates both methods
and throws IntrospectionException if something is wrong.
This will also prevent us from breaking applications
that uses this RI behavior.
Actually I don't belive they exist in our world. :) May be we can
leave the current functionality for now and get back to this if
encounter one of such apps?
Regards,
2006/10/5, Oleg Khaschansky [EMAIL PROTECTED]:
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about comments
especially because I expected a feedback from beans authors. Thank
you.
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case. This will also prevent us from breaking applications
that uses this RI behavior.
What is your opinion?
On 10/5/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Oleg,
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both
issues?
I've already written my thoughts about this issue in [1]. In short: I
don't think we should follow the RI behavior since it is inconsistent.
Why it accepts invalid read method and throws exception on invalid
write method? No logic.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
PROTECTED]
Thanks,
2006/10/4, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the
following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName,
c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any
Re: [classlib] enabling AWT/Swing by default
Tim, I attached a patch which doesn't have side effects to HARMONY-1723 :) -- Oleg On 10/6/06, Tim Ellison [EMAIL PROTECTED] wrote: Oleg Khaschansky wrote: So what happens to the patch on HARMONY-1723. My opinion is that it is OK. Consider the following: 1. Applications bounded to the RI behavior (e.g. obtaining the descriptors for read-only properties without construction of getter name) won't fail. 2. Construction of the default getter/setter names could be incapsulated in the PropertyDescriptor. For now there's no possibility of getting a descriptor for one read-only/write-only property without constructing its getter/setter name outside of the PropertyDescriptor. 3. Don't think that it is bad if PropertyDescriptor would lookup for reasonable defaults if provided names are invalid. I'd like to hear another opinion. If somebody will disagree I'll make another fix for the TransferHandler, whithout touching beans. Me too -- I was following your logic above and agreed, but I got the impression that Alexey disagreed with that approach, so was holding off. I have the patch applied in my workspace but will wait before committing it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][swing] Generification of the swing API.
I am happy to inform that I created a jira #1758 [1] for this task and attached a first patch. Also, I'd like to attract attention to several patches for the awt/swing modules: swing #1536 #1533 #1509 #1475 awt #1647 #1652 #1659 [1] http://issues.apache.org/jira/browse/HARMONY-1758 On 10/5/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: If no one objects I'll generify javax.swing to improve API indicators. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (HARMONY-1763) [classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
According to the good issue resolution guideline I am forwarding
this to the dev. list.
-- Forwarded message --
From: Oleg Khaschansky (JIRA) [EMAIL PROTECTED]
Date: Oct 6, 2006 8:58 PM
Subject: [jira] Updated: (HARMONY-1763) [classlib][beans] method
java.beans.PropertyDescriptor.equals(Object) throws ClassCastException
To: [EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/HARMONY-1763?page=all ]
Oleg Khaschansky updated HARMONY-1763:
--
Attachment: harmony-1763.patch
Patch for this issue rev. 453254.
[classlib][beans] method java.beans.PropertyDescriptor.equals(Object) throws
ClassCastException
---
Key: HARMONY-1763
URL: http://issues.apache.org/jira/browse/HARMONY-1763
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Oleg Khaschansky
Priority: Minor
Attachments: harmony-1763-test.patch, harmony-1763.patch
The test below throws ClassCastException on Harmony but passes on RI.
I will provide a patch for this issue and a unit test.
import java.beans.*;
import java.lang.reflect.*;
public class Test {
public static void main(String[] args) {
PropertyDescriptor toRet = null;
try {
toRet = new PropertyDescriptor(p, Bean.class );
toRet.setBound( true );
} catch (IntrospectionException e) {
e.printStackTrace();
}
Method m = null;
try {
m = HelpClass.class.getDeclaredMethod(f_static,
(Class[])null);
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
toRet.equals(m);
System.out.println(PASSED);
}
}
class Bean {
public void setP(int i) {}
public int getP() {return 0;}
}
class HelpClass {
public HelpClass () {}
public static void f_static () {}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default
Sure. Now I am running the tests on the patch to ensure that modifications in beans are safe. Will submit when the tests will pass. On 10/5/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: Yes, please. When you submit a patch people will have a chance to review and comment Agreed - and please submit it via JIRA. Feel free to point to it on the list. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
Patch for the TransferHandlerTest failure is here:
http://issues.apache.org/jira/browse/HARMONY-1723
On 10/5/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/5, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
Yes, please. When you submit a patch people will have a chance
to review and comment
Thanks,
Mikhail
Thanks,
Oleg
On 10/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report
any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
I've run the tests on my XP machine, 1 failed
javax.swing.TransferHandlerTest#testCreateTransferable
java.lang.NullPointerException at
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
Thanks,
Mikhail
Regards,
Mark.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
(props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about comments
especially because I expected a feedback from beans authors. Thank
you.
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case. This will also prevent us from breaking applications
that uses this RI behavior.
What is your opinion?
On 10/5/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Oleg,
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
I've already written my thoughts about this issue in [1]. In short: I
don't think we should follow the RI behavior since it is inconsistent.
Why it accepts invalid read method and throws exception on invalid
write method? No logic.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
PROTECTED]
Thanks,
2006/10/4, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
Thanks,
Oleg
On 10/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report
any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
I've run the tests on my XP machine, 1 failed
javax.swing.TransferHandlerTest#testCreateTransferable
java.lang.NullPointerException at
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony
[classlib][swing] Generification of the swing API.
If no one objects I'll generify javax.swing to improve API indicators. - 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] enabling AWT/Swing by default
So what happens to the patch on HARMONY-1723.
My opinion is that it is OK. Consider the following:
1. Applications bounded to the RI behavior (e.g. obtaining the
descriptors for read-only properties without construction of getter
name) won't fail.
2. Construction of the default getter/setter names could be
incapsulated in the PropertyDescriptor. For now there's no possibility
of getting a descriptor for one read-only/write-only property without
constructing its getter/setter name outside of the PropertyDescriptor.
3. Don't think that it is bad if PropertyDescriptor would lookup for
reasonable defaults if provided names are invalid.
I'd like to hear another opinion. If somebody will disagree I'll make
another fix for the TransferHandler, whithout touching beans.
On 10/5/06, Tim Ellison [EMAIL PROTECTED] wrote:
So what happens to the patch on HARMONY-1723. Do you (Oleg Alexey)
think we should not fix it that way now?
Regards,
Tim
Oleg Khaschansky wrote:
Alexey,
Agree. I haven't noticed that RI doesn't accept invalid write method.
Then its behavior looks illogical. Actually, I asked about comments
especially because I expected a feedback from beans authors. Thank
you.
On the other hand, why don't we allow Harmony to accept invalid names
and provide a default replacements for them if there is a set/get/is
method for the specified property? It seems to me more user-friendly
then throw IntrospectionException in this situation. It looks like the
specification doesn't require PropertyDescriptor to throw an exception
in this case. This will also prevent us from breaking applications
that uses this RI behavior.
What is your opinion?
On 10/5/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Oleg,
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both
issues?
I've already written my thoughts about this issue in [1]. In short: I
don't think we should follow the RI behavior since it is inconsistent.
Why it accepts invalid read method and throws exception on invalid
write method? No logic.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL
PROTECTED]
Thanks,
2006/10/4, Oleg Khaschansky [EMAIL PROTECTED]:
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent
c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the
following:
private PropertyDescriptor getPropertyDescriptor(final JComponent
c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName,
c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both
issues?
Thanks,
Oleg
On 10/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED]
wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to
change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be
automated for
windows and at least fairly trivial (installing a few
packages on
Linux[0]). I think it is time we removed the with.awt.swing
flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and
report any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish
within
the hour now. We really should see if we can avoid
Re: [classlib] enabling AWT/Swing by default (was: Re: svn commit: r452826 - in /incubator/harmony/enhanced/classlib/trunk: depends/libs/build/ depends/libs/windows.x86/ make/depends.properties make/d
I found the reason of this failure. It is an IntrospectionException
while executing a following method from the TransferHandler class:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
return result;
}
It tries to get the PropertyDescriptor for the class JButton and
property name insets, but fails because there's no setInsets method.
So, flavors array stays uninitialized and getTransferDataFlavors
method returns null which is a cause of a NPE.
The quick fix for this issue could be changing this method to the following:
private PropertyDescriptor getPropertyDescriptor(final JComponent c) {
PropertyDescriptor result = null;
try {
return result = new PropertyDescriptor(propertyName, c.getClass());
} catch (IntrospectionException e) {
}
try {
return result = new PropertyDescriptor(propertyName,
c.getClass(), 1, null);
} catch (IntrospectionException e) {
}
return result;
}
+ we need to fix in beans the fact that the following code:
new PropertyDescriptor(propertyName, c.getClass(), 1, null);
will throw IntrospectionException on Harmony, but will return the
valid property descriptor with the getter method on RI.
Any thoughts on this? Or should I proceed with a patch for the both issues?
Thanks,
Oleg
On 10/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/10/4, Mark Hindess [EMAIL PROTECTED]:
On 4 October 2006 at 15:41, Tim Ellison [EMAIL PROTECTED] wrote:
Excuse the change in subject line...
No problem. I was just cursing myself for having forgotten to change
it.
Mark Hindess wrote:
With this change, the awt dependencies should now be automated for
windows and at least fairly trivial (installing a few packages on
Linux[0]). I think it is time we removed the with.awt.swing flag.
Anyone object?
To the contrary, ditch it.
Please test the current setup with -Dwith.awt.swing=true and report any
problems.
Problem 1: My machine is too slow running all these tests.
Mine too. And I have wondered if the hourly builds will finish within
the hour now. We really should see if we can avoid the need to fork
for every test.
I've run the tests on my XP machine, 1 failed
javax.swing.TransferHandlerTest#testCreateTransferable
java.lang.NullPointerException at
javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
Thanks,
Mikhail
Regards,
Mark.
Regards,
Tim
[0] Details of the required packages for distributions other than
Debian/Ubuntu would be welcome.
On 4 October 2006 at 10:24, [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Oct 4 03:24:29 2006
New Revision: 452826
URL: http://svn.apache.org/viewvc?view=revrev=452826
Log:
Update check/fetch depends targets to handle the awt dependencies.
Modified:
incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
(props
ch
anged)
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows.x86/
(pr
ops changed)
incubator/harmony/enhanced/classlib/trunk/make/depends.properties
incubator/harmony/enhanced/classlib/trunk/make/depends.xml
Propchange: incubator/harmony/enhanced/classlib/trunk/depends/libs/build/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1,3 +1,4 @@
jpeg
lcms
png
+winxp_2006-09-28.txt
Propchange:
incubator/harmony/enhanced/classlib/trunk/depends/libs/windows
.x8
6/
--
---
-
--- svn:ignore (original)
+++ svn:ignore Wed Oct 4 03:24:29 2006
@@ -1 +1,2 @@
msvcr71.dll
+swing_awt_deps_winxp_2006-09-28.tgz
Modified:
incubator/harmony/enhanced/classlib/trunk/make/depends.propertie
s
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trun
k/m
ake/depends.properties?view=diffrev=452826r1=452825r2=452826
==
===
=
---
Re: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 On 10/3/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance - 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: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1, but it seems to me that its build is not aligned with the classlib build structure. Please, correct me if I am wrong. Have somebody tried to build it already? On 9/28/06, Alexey Varlamov [EMAIL PROTECTED] wrote: +1 2006/9/28, Paulex Yang [EMAIL PROTECTED]: +1 Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
+1 for the website. I agree with Mark that the changes to this document shoud be discussed first. On 9/28/06, Mark Hindess [EMAIL PROTECTED] wrote: I agree with Tim. This should be a stable document not one that needs frequent updates (which would only mean contributors would be expected to check it more often). Changes should be discussed/agreed first, thus using JIRA/svn would seem reasonable for this document. -Mark. On 28 September 2006 at 10:46, Tim Ellison [EMAIL PROTECTED] wrote: I'm not trying to be contrary - honest g - but I would suggest the website. It is a reference document that doesn't need a collaboration area on the wiki. The document has undergone review and should be stable now. My 2c. Tim Morozova, Nadezhda wrote: +1 for Wiki. This is a more edit-friendly solution. I can also add a link to your Wiki page from the website - for people to know where to look for guidelines ;) Best regards, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 11:21 AM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Guys, Since there is no additional comments on this guideline... Let's put it somewhere. We got two options: Harmony site and wiki. I prefer wiki because it will be easy to edit it and I can put it there myself :) Thoughts? SY, Alexey 2006/9/26, Alexey Petrenko [EMAIL PROTECTED]: I've combined all the comments again. And here is the last version. I hope... :) === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue and send a message to dev list. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/tru nk. Or to the module root directory. 2.5. Test and fix patches should be in different files. 2.6. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.8. If it is an application-oriented issue, check the application. 2.9. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue === cut === -- 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:
Re: [classlib][awt] Non bug??? RI AffineTransform.transform(...) throws ArrayIndexOutOfBoundsException while Harmony doesn't
+1 for the non-bug diff.
My opinion is that this boundary case is not going to affect any
application, especially because Harmony doesn't throw an exception
while RI does. Also, when the number of points is positive Harmony
still throws an exception if offset is out of bounds.
On 9/28/06, Denis Kishenko [EMAIL PROTECTED] wrote:
According to our Compatibility Guidelines
...There are a few occasions where both the specification is quiet on
a given issue, and the RI exhibits behaviour that we would consider
illogical. In such cases we discuss the issue on the Harmony
developers' mailing list, and code the class libraries to do what the
development community conclude is the logical thing...
So we have 1 vote for non-bug and 1 vote for bug.
2006/9/28, Richard Liang [EMAIL PROTECTED]:
On 9/27/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Hi all
RI implementation of AffineTransform of transform(float[], int,
float[], int, int) and transform(double[], int, double[], int, int)
methods throws ArrayIndexOutOfBoundsException if offset is out of
bounds and number of points to transform is zero. Harmony doesn't
throw any exception. Spec doesn't say about any exceptions.
RI use System.arraycopy(...) (see track trace) which throws this
exception. But Harmony doesn't use System.arraycopy(...) so we have
difference in behavior.
I see two possibilities
1. Stay as non-bug. If number of points is zero then logically we have
to do nothing w/o exceptions.
2. Follow RI. In this case we have to add checks like this
if (srcOff src.length || dstOff dst.length) {
throw new ArrayIndexOutOfBoundsException(...);
}
it looks a bit strange from my point of view.
I vote for non-bug.
Comments?
Hello Denis,
According to our Compatibility Guidelines[1], I suggest we follow RI
for this issue though you may feel uncomfortable about the additional
code ;-)
[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
Best regards,
Richard
2006/9/27, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][awt] RI AffineTransform.transform(...) throws
ArrayIndexOutOfBoundsException while Harmony doesn't
-
Key: HARMONY-1606
URL: http://issues.apache.org/jira/browse/HARMONY-1606
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI implementation of AffineTransform of transform(float[], int, float[],
int, int) and transform(double[], int, double[], int, int) methods throws
ArrayIndexOutOfBoundsException if offsets are out of buffer bounds and number of points
to transform is zero. Harmony doesn't throw any exception. Spec doesn't say about any
exceptions.
As you see from stack trace RI call System.arraycopy(...) which throws
exception because of offset is really out of bounds. But Harmony implementation doesn't
use System.arraycopy(...) so we have difference in behavior.
=== Test.java ===
import java.awt.geom.AffineTransform;
public class Test {
static public void main(String[] args) {
AffineTransform t = new AffineTransform();
try {
t.transform(new float[] {}, 1, new float[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
try {
t.transform(new double[] {}, 1, new double[] {}, 2, 0);
} catch (Exception e) {
e.printStackTrace();
}
}
}
= RI ===
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2308)
at Test.main(Test.java:10)
java.lang.ArrayIndexOutOfBoundsException
at
java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source)
at java.awt.geom.AffineTransform.transform(AffineTransform.java:2421)
at Test.main(Test.java:15)
Harmony ===
nothing
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Denis M. Kishenko
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]
--
Richard Liang
China Development Lab, IBM
Re: [classlib][awt] Fonts with negative size.
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(, new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks quite
strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds =
java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875
,h=-5.7495117]
Actually, I dont see any sence in negative height and width metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen, you
can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to choose only
positive sized fonts. Also I've looked on the GDI LOGFONT structure
description in MSDN and I've seen there again that we deal with absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 On 9/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote: +1 Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. - 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][awt] Fonts with negative size.
It seems like returning negative metrics is somewhat logical. If the
font is rotated by -Pi then all offsets becomes negative, but their
absolute values are equal to the positive ones.
I'll try to give an example. E.g. if descent was, say, 10 and one
needed to offset 10 pt from the origin (baseline) to the bottom of the
black box then if -pi rotation is applied to the font, one need to
offset -10 pt from the baseline since black box is upside down.
Yes, RI failed to be consistent with this on heavyweight components as
it was noted in the evaluation. But is this bug still there in the RI?
And if RI is inconsistent with the drawing of negative-sized fonts it
is still consistent with the negative metrics, right?
IMHO, the ideal behavior in all situations would be the following:
If the font has negative size we assume that it has all the same
metrics as the positive font, but the metrics which has a direction
(like ascent, descent, etc.) are with the different sign. The font is
drawn as it was rotated by -pi angle.
Personaly my opinion is that this is a bug, not non-bug diff.
I'd suggest to choose between these options:
1. Fix metrics and rendering, close this issue.
2. Fix metrics, open a new jira for the rendering of the negative-sized fonts.
3. Fix nothing, open a new jira or add an evaluation to this one
both for the rendering and for the metrics. This means that we want to
have them together.
For the rendering part, why not just add a transform if the size of
the font is negative?
On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
It was evaluated as not a bug. But it is clear from its evaluation
that negative-sized fonts are treated as positive sized but rotated
around their origin, say with implicit transform. I'd suggest to
follow this behavior.
I agree, that the behavior of the negative-sized fonts on RI is looks like
the behavior of positive ones with -Pi rotation. However, if we look at the
font metrics, bounds - we can see negative values for height, width
values...I'm not sure they have any sence without additional documentation
that we can't find in the spec.
Moreover bug evaluation says that RI handles negative-sized fonts for
components in different ways depending on the platform. And it's behavior
unlike the drawing on the frame surface. What is to add - metrics for all
these various cases are the same, it means that RI has erroneous behavior in
some way.
I would suggest not to follow the RI and mark it as non-bug difference as
the RI hasn't any clear documentation on this problem and it's
behavior erroneous and depends on the platform or component type.
Thanks,
Ilya.
On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size
can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(,
new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks
quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543
,w=-5.46875
,h=- 5.7495117]
Actually, I dont see any sence in negative height and width
metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen,
you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to
choose only
positive sized fonts. Also I've looked on the GDI LOGFONT
structure
description in MSDN and I've seen there again that we deal with
absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because
Re: [classlib][awt] Fonts with negative size.
+1 I also think that it is better to follow 6.0 spec in this situation and to suggest that all the words said about TextAttribute are applicable to the Font itself. Actually, using default font size is definitely more reasonable behavior then playing with those negative values and the only concern was compatibility. But if 6.0 spec goes this way then, I think, we must do the same. Still there's a question what would be the metrics for the explicitely transformed font? On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote: Guys, I found something in the Java 6.0 documentation. If you look at the TextAttribute spec there is a note for the SIZE field, attribute key for the font size: Attribute key for the font size. Values are instances of *Number*. The default value is 12pt. This corresponds to the size parameter to the Font constructor. Very large or small sizes will impact rendering performance, and the rendering system might not render text at these sizes. *Negative sizes are illegal and result in the default size*. For this reason I suggest to use default size (12pt) if font has negative size parameter. Any thoughts? I believe negative-sized fonts support was erroneous in Java 5.0 and in the earlier versions of Java. Regards, Ilya. On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: It seems like returning negative metrics is somewhat logical. If the font is rotated by -Pi then all offsets becomes negative, but their absolute values are equal to the positive ones. I'll try to give an example. E.g. if descent was, say, 10 and one needed to offset 10 pt from the origin (baseline) to the bottom of the black box then if -pi rotation is applied to the font, one need to offset -10 pt from the baseline since black box is upside down. Yes, RI failed to be consistent with this on heavyweight components as it was noted in the evaluation. But is this bug still there in the RI? And if RI is inconsistent with the drawing of negative-sized fonts it is still consistent with the negative metrics, right? IMHO, the ideal behavior in all situations would be the following: If the font has negative size we assume that it has all the same metrics as the positive font, but the metrics which has a direction (like ascent, descent, etc.) are with the different sign. The font is drawn as it was rotated by -pi angle. Personaly my opinion is that this is a bug, not non-bug diff. I'd suggest to choose between these options: 1. Fix metrics and rendering, close this issue. 2. Fix metrics, open a new jira for the rendering of the negative-sized fonts. 3. Fix nothing, open a new jira or add an evaluation to this one both for the rendering and for the metrics. This means that we want to have them together. For the rendering part, why not just add a transform if the size of the font is negative? On 9/25/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 9/25/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: It was evaluated as not a bug. But it is clear from its evaluation that negative-sized fonts are treated as positive sized but rotated around their origin, say with implicit transform. I'd suggest to follow this behavior. I agree, that the behavior of the negative-sized fonts on RI is looks like the behavior of positive ones with -Pi rotation. However, if we look at the font metrics, bounds - we can see negative values for height, width values...I'm not sure they have any sence without additional documentation that we can't find in the spec. Moreover bug evaluation says that RI handles negative-sized fonts for components in different ways depending on the platform. And it's behavior unlike the drawing on the frame surface. What is to add - metrics for all these various cases are the same, it means that RI has erroneous behavior in some way. I would suggest not to follow the RI and mark it as non-bug difference as the RI hasn't any clear documentation on this problem and it's behavior erroneous and depends on the platform or component type. Thanks, Ilya. On 9/23/06, Richard Liang [EMAIL PROTECTED] wrote: On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Google said this is the bug of RI in progress [1]. However there is no distinct resolution yet... It's reported again Java 1.1.8 more than 3 years agao. I don't think RI will fix this bug. Richard. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825 2006/9/23, Richard Liang [EMAIL PROTECTED]: On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote: Hi, all! I was playing with fonts and found that Font with negative size can be created on RI. Unfortunately spec keep silence about fonts with negative sizes. On Harmony if font size is negative then it is set to zero. test.java--- import java.awt.*; import
Re: [classlib][swing/awt] caffinemark shows that our graphics are sloooowwwww....
Current implementation of composite operations (alpha blending) on linux is just a general unacceleratred code, these operations are performed on per-pixel basis and, definitely, they are rather slow. But the main reason is that pixel data should be retrieved from the screen to perform the blending. This screen-client memory data transfer is painfully slow on X. Probably, it is the most significant performance gap of the current linux implementation. Maybe, it is possible to improve it in the most general cases by implementing a codepath which uses xrender extension, which will allow to eliminate screen-memory copying, since xrender supports transparency. Probably, it is also possible to accelerate blit operations by adding the code which uses mitshm extension. Basic rendering w/o transparency theoretically should be much faster then the transparent case. These problems are related to linux implementation only. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Definitely. I will do it today and add a page to our how are we doing? page so we can track over time. (That and any other benchmark we're allowed to use and publish). I think that what we have is mighty impressive. (It's just the graphics numbers that are bad...) geir On Sep 22, 2006, at 4:47 AM, Paulex Yang wrote: Geir Magnusson Jr. wrote: I've been playing a bit with caffinemark, and our numbers for everything except graphics are amazing. Convenient to post some results vs RI? I believe many ones(includes myself of course) would be very interest to see the numbers:) However, our graphics numbers are *terrible*. I was testing on Ubuntu. We need to fix this. Does anyone with familiarity with our swing/awt impl that could point us in the right direction? geir - 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] -- 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] - 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][swing/awt] caffinemark shows that our graphics are sloooowwwww....
They definitely use mitshm, see Local X Server Performance Improvements chapter in [1]. Also they do use xrender, see [2]. Maybe they also do use something else, like EXA, I don't know... [1] http://java.sun.com/products/java-media/2D/perf_graphics.html [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6307603 On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 9:29 AM, Oleg Khaschansky wrote: Current implementation of composite operations (alpha blending) on linux is just a general unacceleratred code, these operations are performed on per-pixel basis and, definitely, they are rather slow. But the main reason is that pixel data should be retrieved from the screen to perform the blending. This screen-client memory data transfer is painfully slow on X. Probably, it is the most significant performance gap of the current linux implementation. Maybe, it is possible to improve it in the most general cases by implementing a codepath which uses xrender extension, which will allow to eliminate screen-memory copying, since xrender supports transparency. I wonder then how sun goes so fast - the thing is that compared to sun, it's slow. Probably, it is also possible to accelerate blit operations by adding the code which uses mitshm extension. Basic rendering w/o transparency theoretically should be much faster then the transparent case. These problems are related to linux implementation only. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Definitely. I will do it today and add a page to our how are we doing? page so we can track over time. (That and any other benchmark we're allowed to use and publish). I think that what we have is mighty impressive. (It's just the graphics numbers that are bad...) geir On Sep 22, 2006, at 4:47 AM, Paulex Yang wrote: Geir Magnusson Jr. wrote: I've been playing a bit with caffinemark, and our numbers for everything except graphics are amazing. Convenient to post some results vs RI? I believe many ones(includes myself of course) would be very interest to see the numbers:) However, our graphics numbers are *terrible*. I was testing on Ubuntu. We need to fix this. Does anyone with familiarity with our swing/awt impl that could point us in the right direction? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - 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]
Re: [Non-bug difference]? JIRA-1126
I'd like to quote RFC 2396 here: The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI. However, a subset of URI do share a common syntax for representing hierarchical relationships within the namespace. This generic URI syntax consists of a sequence of four main components: scheme://authoritypath?query each of which, except scheme, may be absent from a particular URI. ... We use the term path to refer to both the abs_path and opaque_part constructs, since they are mutually exclusive for any given URI and can be parsed as a single component. So file://C:/1.txt appears to be a valid URI of the following kind: scheme://path, where path is an opaque_part. This means that #1126 is, actually, a bug. Am I correct? On 9/21/06, Spark Shen [EMAIL PROTECTED] wrote: [snip] Vladimir Ivanov http://issues.apache.org/jira/secure/ViewProfile.jspa?name=vladimir unit test. Seems, that patch will be system dependent (special handling for Win should be added) [snip] And I agree with Vladimir Ivanov here, on Win-platform, special handling for file system is needed. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk As Mark noted, the directory where the module's build.xml is located is also acceptable. https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/modules/module_name Generally, making the patch from this directory is much faster then from the classlib/trunk :) On 9/20/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I've combined all the ideas. And here is the result. === cut === Preface This guideline covers a wide range of issues but not all of them. If you cannot do one of the steps, then write a comment to the issue. Use your common sense! Issue reporter: 1. Explicitly state the expected behavior and the actual behavior of Harmony code. Use links to specs, rfcs, etc. 2. Try to create as small a test case as possible. A patch to test will be highly appreciated. 3. Provide max. information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much diagnostic information about the failure as possible (stack trace, failure output, expected output etc). 4. Remember to use issue links if applicable. 5. Check the issue resolution when it is committed. Add a comment. Resolution provider :) : Depending on the type of issue, do the following: 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on the dev list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. Notify the community that you started investigation by adding a comment to the issue. If you cannot produce a patch, add another comment with the results of your investigation. 2.2. If reporter did not provide a patch to test: 2.2.1. Try to create a patch to test. 2.2.2. If you cannot produce a patch, write a comment about it. 2.3. Create a patch to fix the issue 2.3.1. Any concerns? Discuss on the dev list. Add a link to discussion as a comment. 2.4. All the pacthes (test and fix) should be relative to the directory where the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk 2.5. If the patch requires to add, remove or move some files in the repository, add the appropriate script. 2.6. Check that all unit tests pass. 2.7. If it is an application-oriented issue, check the application. 2.8. Remember to use issue links if applicable. Committer: Depending on the issue type, do: 1. Issue is a non-bug difference, not a bug or invalid: Close the issue. 2. Issue is a bug: 2.1. If a patch to test is available, apply it. 2.2. Check that the test fails. 2.3. Apply the fix for the issue. 2.4. Check that test succeeds now. 2.5. Make sure that all unit tests pass. 2.6. For application-oriented issues, check the application. 2.7. If there are problems on previous steps, post a comment to JIRA and let resolution provider to resolve. 2.8. Make sure that the issue reporter is happy with the resolution. 2.9. Add revision info into JIRA issue - 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][awt] problem w/ AWT on linux? (CaffineMark) Was (Re: [drlvm] When running caffinemark, DRLVM now crashes..)
Do you have libxmu? Probably, fails either
void* lib = dlopen(libxmu.so, RTLD_LAZY);
or the corresponding
dlsym(lib, XmuLookupStandardColormap);
Could you, please, check if these dlopen/dlsym return non zero on your system?
On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Ok, so I was really tired last night when I reported this. I've done a
little more homeork, and I get the same crash with J9. The stack trace
is :
Generated system dump: {default OS core name}
Thread: main (priority 5) (LOCATION OF ERROR)
NATIVE
org/apache/harmony/awt/nativebridge/linux/X11.XmuLookupStandardColormap(JIJIJII)I
0080
org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.obtainRGBColorMap()J
0015
org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.init(Lorg/apache/harmony/awt/gl/linux/XGraphicsDevice
;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
00aa org/apache/harmony/awt/gl/linux/XGraphicsDevice.createConfigs()V
0008
org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/apache/harmony/awt/gl/linux/XGraphicsConfigu
ration;
0001
org/apache/harmony/awt/gl/linux/XGraphicsDevice.getDefaultConfiguration()Ljava/awt/GraphicsConfiguration;
000f
java/awt/Window.getGraphicsConfiguration(Ljava/awt/GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
0081
java/awt/Window.init(Ljava/awt/Window;Ljava/awt/GraphicsConfiguration;)V
0003
java/awt/Frame.init(Ljava/lang/String;Ljava/awt/GraphicsConfiguration;)V
0003 java/awt/Frame.init(Ljava/lang/String;)V
0003 CaffeineMarkFrame.init(Ljava/applet/Applet;Z)V
0006 CaffeineMarkApp.main([Ljava/lang/String;)V
Anyone have any idea?
geir
Geir Magnusson Jr wrote:
On Ubuntu 6, I was trying to run CaffineMark to see where we are w/ the
lastest set of patches and the big java 5 and other fix patch. release
build, r447024
top of the stack trace is
Java_org_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap
Can anyone repeat this error?
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1456) [classlib][awt]java.awt.Font.hasUniformLineMetrics() return true on Harmony while RI returns false
+1. BTW, I can't imagine the application that could be affected by
this difference.
On 9/19/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, community!
I found for java.awt.Font.hasUniformLineMetrics() RI returns false for all
fonts (physical/logical) while Harmony returns true for physical and false
for logical.
Spec says: Checks whether or not this Font has uniform line metrics. A
logical Font might be a composite font, which means that it is composed of
different physical fonts to cover different code ranges. Each of these fonts
might have different LineMetrics. If the logical Font is a single font then
the metrics would be uniform. . Thus I find reasonable to return true for
physical fonts, as they are single.I assume that it is a non-bug difference
from RI.
Any thoughts on this issue?
Regards,
Ilya.
On 9/13/06, Ilya Okomin (JIRA) [EMAIL PROTECTED] wrote:
[classlib][awt]java.awt.Font.hasUniformLineMetrics() return true on
Harmony while RI returns false
--
Key: HARMONY-1456
URL: http://issues.apache.org/jira/browse/HARMONY-1456
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Environment: Windows XP
Reporter: Ilya Okomin
Priority: Trivial
According to the specification method must Font.hasUniformLineMetricsreturn
true if this Font has uniform
line metrics; false otherwise.
RI returns false for physical font Arial while Harmony returns true.
test.java
import java.awt.*;
import junit.framework.TestCase;
public class test extends TestCase {
public void testRun() {
final String name = Arial;
Font f=new Font(name, Font.BOLD, 12);
// Check if created font is physical, it's family name
// is not logical and equals to the name parameter.
assertEquals(f.getFamily(), name);
assertTrue(f.hasUniformLineMetrics());
}
}
===
Output:
RI: java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at test.testRun(Test9688.java:17)
at jrockit.reflect.VirtualNativeMethodInvoker.invoke(
Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at java.lang.reflect.Method.invoke(Ljava.lang.Object;[
Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
RemoteTestRunner.java:344)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
RemoteTestRunner.java:196)
Harmony: java version 1.5.0
pre-alpha : not complete or compatible
svn = r431938, (Aug 16 2006), Windows/ia32/msvc 1310, release build
http://incubator.apache.org/harmony
// test passed!
I would suppose that it is RI bug, since spec says: If the logical Font
is a single font then the metrics would be uniform. In this case we have
Arial font that is a single physical font on Windows platform and
according to spec it has to have uniform metrics.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
--
Ilya Okomin
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: [jira] Created: (HARMONY-1456) [classlib][awt]java.awt.Font.hasUniformLineMetrics() return true on Harmony while RI returns false
I wanted to say that if RI always returns false then there's very
small probability that any application developed for RI's classlib
uses this.
On 9/19/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 9/19/06, Oleg Khaschansky [EMAIL PROTECTED] wrote:
+1. BTW, I can't imagine the application that could be affected by
this difference.
It may have sence if the application uses certain metrics for logical fonts
according to the hasUniformLineMetrics() returned value. E.g. baseline
offsets or lines thicknesses may be different for the physical fonts, that
are composing logical font. Probably some applications would use font
metrics if the hasUniformLineMetrics() returned true and use redefined
values for such metrics if returned value is false, depending on the
situation. (It is only a guess;)
Thanks,
Ilya.
On 9/19/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, community!
I found for java.awt.Font.hasUniformLineMetrics() RI returns false for
all
fonts (physical/logical) while Harmony returns true for physical and
false
for logical.
Spec says: Checks whether or not this Font has uniform line metrics. A
logical Font might be a composite font, which means that it is composed
of
different physical fonts to cover different code ranges. Each of these
fonts
might have different LineMetrics. If the logical Font is a single font
then
the metrics would be uniform. . Thus I find reasonable to return true
for
physical fonts, as they are single.I assume that it is a non-bug
difference
from RI.
Any thoughts on this issue?
Regards,
Ilya.
On 9/13/06, Ilya Okomin (JIRA) [EMAIL PROTECTED] wrote:
[classlib][awt]java.awt.Font.hasUniformLineMetrics() return true on
Harmony while RI returns false
--
Key: HARMONY-1456
URL: http://issues.apache.org/jira/browse/HARMONY-1456
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Environment: Windows XP
Reporter: Ilya Okomin
Priority: Trivial
According to the specification method must
Font.hasUniformLineMetricsreturn true if this Font has uniform
line metrics; false otherwise.
RI returns false for physical font Arial while Harmony returns true.
test.java
import java.awt.*;
import junit.framework.TestCase;
public class test extends TestCase {
public void testRun() {
final String name = Arial;
Font f=new Font(name, Font.BOLD, 12);
// Check if created font is physical, it's family name
// is not logical and equals to the name parameter.
assertEquals(f.getFamily(), name);
assertTrue(f.hasUniformLineMetrics());
}
}
===
Output:
RI: java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC: System optimized over throughput (initial strategy
singleparpar))
junit.framework.AssertionFailedError
at junit.framework.Assert.fail (Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at test.testRun(Test9688.java:17)
at jrockit.reflect.VirtualNativeMethodInvoker.invoke(
Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown
Source)
at java.lang.reflect.Method.invoke (Ljava.lang.Object;[
Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java :127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run (TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run (TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run (
RemoteTestRunner.java:344)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
RemoteTestRunner.java:196)
Harmony: java version 1.5.0
pre-alpha : not complete or compatible
svn = r431938, (Aug 16 2006), Windows/ia32/msvc 1310, release build
http://incubator.apache.org/harmony
// test passed!
I would suppose that it is RI bug, since spec says: If the logical
Font
is a single font then the metrics would be uniform. In this case
Re: [classlib][awt] problem w/ AWT on linux? (CaffineMark) Was (Re: [drlvm] When running caffinemark, DRLVM now crashes..)
Probably you need to add it to your LD_LIBRARY_PATH...
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Good catch.
dlopen() returns null, but the package manager claims xmu is
installed, so clearly it's lying, or something is misconfigured.
Thanks for the hint.
geir
On Sep 19, 2006, at 6:30 AM, Oleg Khaschansky wrote:
Do you have libxmu? Probably, fails either
void* lib = dlopen(libxmu.so, RTLD_LAZY);
or the corresponding
dlsym(lib, XmuLookupStandardColormap);
Could you, please, check if these dlopen/dlsym return non zero on
your system?
On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Ok, so I was really tired last night when I reported this. I've
done a
little more homeork, and I get the same crash with J9. The stack
trace
is :
Generated system dump: {default OS core name}
Thread: main (priority 5) (LOCATION OF ERROR)
NATIVE
org/apache/harmony/awt/nativebridge/linux/
X11.XmuLookupStandardColormap(JIJIJII)I
0080
org/apache/harmony/awt/gl/linux/
XGraphicsConfiguration.obtainRGBColorMap()J
0015
org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.init(Lorg/
apache/harmony/awt/gl/linux/XGraphicsDevice
;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
00aa org/apache/harmony/awt/gl/linux/
XGraphicsDevice.createConfigs()V
0008
org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/
apache/harmony/awt/gl/linux/XGraphicsConfigu
ration;
0001
org/apache/harmony/awt/gl/linux/
XGraphicsDevice.getDefaultConfiguration()Ljava/awt/
GraphicsConfiguration;
000f
java/awt/Window.getGraphicsConfiguration(Ljava/awt/
GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
0081
java/awt/Window.init(Ljava/awt/Window;Ljava/awt/
GraphicsConfiguration;)V
0003
java/awt/Frame.init(Ljava/lang/String;Ljava/awt/
GraphicsConfiguration;)V
0003 java/awt/Frame.init(Ljava/lang/String;)V
0003 CaffeineMarkFrame.init(Ljava/applet/Applet;Z)V
0006 CaffeineMarkApp.main([Ljava/lang/String;)V
Anyone have any idea?
geir
Geir Magnusson Jr wrote:
On Ubuntu 6, I was trying to run CaffineMark to see where we are
w/ the
lastest set of patches and the big java 5 and other fix patch.
release
build, r447024
top of the stack trace is
Java_org_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap
Can anyone repeat this error?
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
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]
Re: [classlib][awt] problem w/ AWT on linux? (CaffineMark) Was (Re: [drlvm] When running caffinemark, DRLVM now crashes..)
So you need to build with -Dwith.awt.swing=true then...
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Nah :)
So the problem was that I have
/usr/lib/libXmu.so.6
I added a link
/usr/lib/libXmu.so
and now it wants libgl.so, which I don't have...
On Sep 19, 2006, at 9:23 AM, Oleg Khaschansky wrote:
Probably you need to add it to your LD_LIBRARY_PATH...
On 9/19/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Good catch.
dlopen() returns null, but the package manager claims xmu is
installed, so clearly it's lying, or something is misconfigured.
Thanks for the hint.
geir
On Sep 19, 2006, at 6:30 AM, Oleg Khaschansky wrote:
Do you have libxmu? Probably, fails either
void* lib = dlopen(libxmu.so, RTLD_LAZY);
or the corresponding
dlsym(lib, XmuLookupStandardColormap);
Could you, please, check if these dlopen/dlsym return non zero on
your system?
On 9/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Ok, so I was really tired last night when I reported this. I've
done a
little more homeork, and I get the same crash with J9. The stack
trace
is :
Generated system dump: {default OS core name}
Thread: main (priority 5) (LOCATION OF ERROR)
NATIVE
org/apache/harmony/awt/nativebridge/linux/
X11.XmuLookupStandardColormap(JIJIJII)I
0080
org/apache/harmony/awt/gl/linux/
XGraphicsConfiguration.obtainRGBColorMap()J
0015
org/apache/harmony/awt/gl/linux/XGraphicsConfiguration.init
(Lorg/
apache/harmony/awt/gl/linux/XGraphicsDevice
;Lorg/apache/harmony/awt/nativebridge/linux/X11$XVisualInfo;)V
00aa org/apache/harmony/awt/gl/linux/
XGraphicsDevice.createConfigs()V
0008
org/apache/harmony/awt/gl/linux/XGraphicsDevice.getConfigs()[Lorg/
apache/harmony/awt/gl/linux/XGraphicsConfigu
ration;
0001
org/apache/harmony/awt/gl/linux/
XGraphicsDevice.getDefaultConfiguration()Ljava/awt/
GraphicsConfiguration;
000f
java/awt/Window.getGraphicsConfiguration(Ljava/awt/
GraphicsConfiguration;)Ljava/awt/GraphicsConfiguration;
0081
java/awt/Window.init(Ljava/awt/Window;Ljava/awt/
GraphicsConfiguration;)V
0003
java/awt/Frame.init(Ljava/lang/String;Ljava/awt/
GraphicsConfiguration;)V
0003 java/awt/Frame.init(Ljava/lang/String;)V
0003 CaffeineMarkFrame.init(Ljava/applet/Applet;Z)V
0006 CaffeineMarkApp.main([Ljava/lang/String;)V
Anyone have any idea?
geir
Geir Magnusson Jr wrote:
On Ubuntu 6, I was trying to run CaffineMark to see where we are
w/ the
lastest set of patches and the big java 5 and other fix patch.
release
build, r447024
top of the stack trace is
Java_org_harmony_awt_nativebridge_linux_X11_XmuLookupStandardColormap
Can anyone repeat this error?
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
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]
Re: [jira] Commented: (HARMONY-286) Add build-java and build-native targets to main build.xml
ant -f make/build-java.xml -Dbuild.module=awt build No, it doesn't work, at least for me. On 9/15/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/9/15, Alexey Varlamov [EMAIL PROTECTED]: 2006/9/15, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/15, Alexey Varlamov [EMAIL PROTECTED]: 2006/9/15, Alexey Petrenko [EMAIL PROTECTED]: Guys, I suggest to close this issue as won't fix because current build allows to build only specified module. And it is enough. So there is the issue, due to this is not enough for some other developers. E.g., me also thinks that it would be nice to have. Nice to have possibility to build ALL the java or ALL the natives? Usually a single module is worked on, but it can affect other modules as well. I do not think it matters to this issue. So you want a possibility to build only java or native part of specific module? If so you can do it in the following way: ant -f make/build-java.xml -Dbuild.module=awt build -- Regards, Alexey Thoughts? Objections? SY, Alexey 2006/9/15, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-286?page=comments#action_12434930 ] Alexey Petrenko commented on HARMONY-286: - Current build allows to build only specified module. So I think that this bug should be closed as won't fix Add build-java and build-native targets to main build.xml - Key: HARMONY-286 URL: http://issues.apache.org/jira/browse/HARMONY-286 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Oliver Deakin Priority: Minor Attachments: build.targets.diff At the moment there are no targets in make/build.xml to clean and build only the native code or only the java code in classlib. I think it would be useful to have these as separate targets for convenience, so that when you are only working on Java code you need not recompile the native code entirely everytime, and vice versa. I will attach a patch with the necessary changes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Commented: (HARMONY-286) Add build-java and build-native targets to main build.xml
No, it doesn't work, at least for me. Sorry, actually it does. I was trying to run it from the wrong dir. On 9/15/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: ant -f make/build-java.xml -Dbuild.module=awt build No, it doesn't work, at least for me. On 9/15/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/9/15, Alexey Varlamov [EMAIL PROTECTED]: 2006/9/15, Alexey Petrenko [EMAIL PROTECTED]: 2006/9/15, Alexey Varlamov [EMAIL PROTECTED]: 2006/9/15, Alexey Petrenko [EMAIL PROTECTED]: Guys, I suggest to close this issue as won't fix because current build allows to build only specified module. And it is enough. So there is the issue, due to this is not enough for some other developers. E.g., me also thinks that it would be nice to have. Nice to have possibility to build ALL the java or ALL the natives? Usually a single module is worked on, but it can affect other modules as well. I do not think it matters to this issue. So you want a possibility to build only java or native part of specific module? If so you can do it in the following way: ant -f make/build-java.xml -Dbuild.module=awt build -- Regards, Alexey Thoughts? Objections? SY, Alexey 2006/9/15, Alexey Petrenko (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-286?page=comments#action_12434930 ] Alexey Petrenko commented on HARMONY-286: - Current build allows to build only specified module. So I think that this bug should be closed as won't fix Add build-java and build-native targets to main build.xml - Key: HARMONY-286 URL: http://issues.apache.org/jira/browse/HARMONY-286 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Oliver Deakin Priority: Minor Attachments: build.targets.diff At the moment there are no targets in make/build.xml to clean and build only the native code or only the java code in classlib. I think it would be useful to have these as separate targets for convenience, so that when you are only working on Java code you need not recompile the native code entirely everytime, and vice versa. I will attach a patch with the necessary changes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and Graphics.fill3DRect
Thank you! On 9/14/06, Nathan Beyer [EMAIL PROTECTED] wrote: Done. -Original Message- From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 10:36 AM To: harmony-dev@incubator.apache.org Subject: [jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and Graphics.fill3DRect Committers, Could someone be so kind and change the component for this issue to the classlib, please? Unfortunately, I forgot to set it when created the issue and unable to change. And, probably, apply the patch also :) thanks, -- Oleg - 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]
[classlib][awt]
Hi all, JAPI tool shows a number of inconsistencies in the java.awt and java.awt.* packages [1]. I am going to provide a patch(es) for this packages except java.awt.print if noone objects. This will include implementing of unimplemented methods, generification and marking some fields/methods as deprecated. [1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#err_minor_java_awt Regards, -- Oleg - 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][awt]
Mark, thank you for the good news! I'll do the generification and missing stuff then. I plan to make one patch for all the generification and, probably, several other patches for the missing methods/fields. On 9/14/06, Mark Hindess [EMAIL PROTECTED] wrote: Oleg, I've checked in the changes I had outstanding as r443340. Patches for the other issues would be very welcome. Regards, -Mark. On 14 September 2006 at 13:37, Mark Hindess [EMAIL PROTECTED] wrote: On 14 September 2006 at 14:57, Oleg Khaschansky [EMAIL PROTECTED] om wrote: Hi all, JAPI tool shows a number of inconsistencies in the java.awt and java.awt.* packages [1]. I am going to provide a patch(es) for this packages except java.awt.print if noone objects. This will include implementing of unimplemented methods, generification and marking some fields/methods as deprecated. Don't worry about the deprecated methods and fields. I have a workspace with these fixed ready to checkin. I will check it in shortly so you can assume that they will be done. -Mark. [1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#err_mino r_ java_awt Regards, -- Oleg - 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][awt]
Created a patch for the generification. [1] Mark, BTW, while looking into JAPI results I saw a couple of messages about deprecation: method java.awt.image.renderable.RenderContext.concetenateTransform(java.awt.geom.AffineTransform): deprecated in 1.5, but not deprecated in Harmony method java.awt.image.renderable.RenderContext.preConcetenateTransform(java.awt.geom.AffineTransform): deprecated in 1.5, but not deprecated in Harmony I am going to make another patch for all missing fields and can add fix for this issue with deprecation into it also. [1] http://issues.apache.org/jira/browse/HARMONY-1463 On 9/14/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Mark, thank you for the good news! I'll do the generification and missing stuff then. I plan to make one patch for all the generification and, probably, several other patches for the missing methods/fields. On 9/14/06, Mark Hindess [EMAIL PROTECTED] wrote: Oleg, I've checked in the changes I had outstanding as r443340. Patches for the other issues would be very welcome. Regards, -Mark. On 14 September 2006 at 13:37, Mark Hindess [EMAIL PROTECTED] wrote: On 14 September 2006 at 14:57, Oleg Khaschansky [EMAIL PROTECTED] om wrote: Hi all, JAPI tool shows a number of inconsistencies in the java.awt and java.awt.* packages [1]. I am going to provide a patch(es) for this packages except java.awt.print if noone objects. This will include implementing of unimplemented methods, generification and marking some fields/methods as deprecated. Don't worry about the deprecated methods and fields. I have a workspace with these fixed ready to checkin. I will check it in shortly so you can assume that they will be done. -Mark. [1] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#err_mino r_ java_awt Regards, -- Oleg - 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][internationalization]Are log messages and tools usage text to be internationalized?
Hi, Are there any non-exception messages in the other modules which are already internationalized? I think, if there are any, they should be modified to follow the new convention. -- Oleg On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi, Jimmy, Jing Lv wrote: 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. Ilya Okomin wrote: The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient Nice idea guys, +1 from me Regards, 2006/9/11, Ilya Okomin [EMAIL PROTECTED]: Thanks all for useful comments! The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient. If there are no objections I would use default key names module.id for exception messages, and module.prefix.id for certain messages where prefix is log or console (or any other key word depending on the purpose). Regards, Ilya. On 9/11/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- 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] -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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][internationalization]Are log messages and tools usage text to be internationalized?
It is unclear what do you mean by the lazy way. If it means that every new message will follow the new convention, then we will never be consistent. If you mean that this task have low priority, then I agree, but, probably, somebody have to open a JIRA issue for this. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I believe it could be done in lazy way... But it defenetly should be done. SY, Alexey 2006/9/13, Oleg Khaschansky [EMAIL PROTECTED]: Hi, Are there any non-exception messages in the other modules which are already internationalized? I think, if there are any, they should be modified to follow the new convention. -- Oleg On 9/12/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Hi, Jimmy, Jing Lv wrote: 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. Ilya Okomin wrote: The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient Nice idea guys, +1 from me Regards, 2006/9/11, Ilya Okomin [EMAIL PROTECTED]: Thanks all for useful comments! The way to use prefixes in the keys names to separate messages of one type from another looks to me pretty convenient. If there are no objections I would use default key names module.id for exception messages, and module.prefix.id for certain messages where prefix is log or console (or any other key word depending on the purpose). Regards, Ilya. On 9/11/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- 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] -- -- Ilya Okomin Intel Middleware Products Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]what is non-bug difference issue?
+1. My understanding is that when the non-bug difference is discussed it should be opened, but when there's an agreement on it it should be closed. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: I vote for closing non-bug issues. 2006/9/13, Andrew Zhang [EMAIL PROTECTED]: On 9/13/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 9/13/06, Tony Wu wrote: When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? Yes, I think you are right. Thanks for catching this. IIRC we created this JIRA category just to document difference with RI but not to fix it. IMO you should add comments to such JIRAs asking why a difference was fixed. I suggest that if the bug was fixed for some reason, we should change the component too, i.e, classlib instead of non-bug difference from RI. Another question is for those real non-bug difference from RI JIRAs, what should be the final status, opened or closed? I suggest the latter so that all of JIRAs could be closed eventually. Comments? Thanks! Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]volunteer to supply patches for old JIRAs
Put comment to the jira issue when you start work on it. You may also change the wiki page if you like, but, please, add a comment right into the jira. And another comment if you can't provide a patch for some reason. It was discussed already. On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: Yes, This wiki page is just a place to record who are working on a given old JIRA issue for avoiding duplicate work. maybe the ASSIGNEE causes misunderstanding. I have replaced it to VOLUNTEER :) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: My suggestion is to use the wiki page to augment rather than replace what the JIRA can do. For example, I'd suggest that people who are working on a given JIRA note that *in the JIRA*. geir Tony Wu wrote: I have opened a new page at harmony wiki, http://wiki.apache.org/harmony/OLDJIRAS You can get the guideline, the process and a list of old jira issues there. In the list there is a column called ASSIGNEE, you can sign your name there if you are working on that issue. And you may check from this list to ensure there is no one also decide to working on the same issue before you start. If you notice there is something wrong or I missed, feel free to update that page, your effort will bring convenience to whole harmony community: ) On 9/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: You might also consider creating a page on the wiki where you outline this process, and record who is signing up for what... geir Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
And the resolution provider should not forget to add a comment when he is starting development of the patch to prevent collisions. If the resolution provider is a committer he simply assigns the bug. On 9/13/06, Andrew Zhang [EMAIL PROTECTED] wrote: On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? Sounds excellent! SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
and resolution provider should verify the application. Or, probably, the reporter may do it also. On 9/13/06, Tony Wu [EMAIL PROTECTED] wrote: and resolution provider should verify the application. On 9/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, I think that we need to create something like Good issue resolution guideline and post it on Harmony site or wiki. It will help community to prepare good fixes and will help committers to spend less time on applying other's patches. As a start we can take Nathan's post with additions from Paulex. I'll add few points from me... Issue reporter: 1. Reporter should try to create as small test case as possible. Patch to test will be highly appreciated. 2. Do not forget to use issue links if applicable. Resolution provider :) : 1. Issue is probably a non-bug difference, not a bug or invalid: 1.1. Discuss on dev-list. 1.2. Add a link to the discussion thread as a comment to issue. 2. Issue is a bug: 2.1. If reporter did not provide patch to test: 2.1.1. If it is possible to create a patch to test then create it. 2.1.2. If it is not possible then note it in the comment. 2.2. Create a patch to fix the issue 2.2.1. Any concerns? Discuss on dev list. Add a link to discussion as a comment. 3. Do not forget to use issue links if applicable. Committer 1. Issue is probably a non-bug difference, not a bug or invalid: close the issue. 2. Issue is a bug: 2.1. Apply the patch to test if it exists. 2.2. Check that test fails. 2.3. Apply the fix for the issue 2.4. Check that test does not fail any more 2.5. If there is a problem on previous steps post a comment to JIRA and let resolution provider to resolve. Thoughts? Comments? Additions? SY, Alexey 2006/9/13, Paulex Yang [EMAIL PROTECTED]: Nathan Beyer wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan +1 from me, this is an excellent guide. Only one more thing: * If the JIRA/patch is debatable for any reasons (non-bug difference, break others, any other concerns...), don't hesitate to forward it to dev-list for discussion. And further, if possible, I suggest to look at related JIRAs in one run, for example, there may be several issues/patches related to ObjectOutputStream, if you fixed/updated one, another patch may be outdated, a better way is to link them and consider them together. -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Wu 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]
[jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and Graphics.fill3DRect
Committers,
Could someone be so kind and change the component for this issue to
the classlib, please? Unfortunately, I forgot to set it when created
the issue and unable to change.
And, probably, apply the patch also :)
thanks,
--
Oleg
-- Forwarded message --
From: Oleg Khaschansky (JIRA) [EMAIL PROTECTED]
Date: Sep 13, 2006 3:10 PM
Subject: [jira] Updated: (HARMONY-1453) [classlib][awt] Incorrect
behavior of methods Graphics.draw3DRect and Graphics.fill3DRect
To: [EMAIL PROTECTED]
[ http://issues.apache.org/jira/browse/HARMONY-1453?page=all ]
Oleg Khaschansky updated HARMONY-1453:
--
Attachment: harmony-1453.patch
Patch with reimplemented draw3DRect and fill3DRect methods. All listed
issues fixed. AWT tests passed on win32 with this patch.
[classlib][awt] Incorrect behavior of methods Graphics.draw3DRect and
Graphics.fill3DRect
-
Key: HARMONY-1453
URL: http://issues.apache.org/jira/browse/HARMONY-1453
Project: Harmony
Issue Type: Bug
Reporter: Oleg Khaschansky
Priority: Minor
Attachments: harmony-1453.patch
1. Methods Graphics.draw3DRect(int x, int y, int width, int height, boolean
raised) and Graphics.fill3DRect(int x, int y, int width, int height, boolean
raised) use their width parameter instead of height to draw the lines. This
result in a quads instead of rectangles.
2. Calling these methods will reset paint attribute of the graphics context.
Harmony implementation of these methods calls setColor method, which updates
the paint attribute. This behavior is illogical and differs from RI.
3. Rendering of lines and filled rectangles in these methods uses paint and stroke
defined in the Graphics2D. This behavior contradicts the spec for the Graphics2D class:
The draw3DRect and fill3DRect methods were implemented in terms of the drawLine and
fillRect methods in the Graphics class which would predicate their behavior upon the
current Stroke and Paint objects in a Graphics2D context. This class overrides those
implementations with versions that use the current Color exclusively, overriding the
current Paint and which uses fillRect to describe the exact same behavior as the
preexisting methods regardless of the setting of the current Stroke.
4. If the rectangle is not raised then fill3Drect fills it with the incorrect
color (behavior differs from RI).
5. There are per-pixel differences between RI and harmony implementations.
I will attach a patch for this issue soon.
The following test reveals all this incorrect behavior:
== test.java ===
import java.awt.*;
import java.awt.geom.AffineTransform;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
public class test {
public static void main(String[] args) {
Frame f = new Frame(test);
f.add( new Canvas(){
public void paint(Graphics g) {
Graphics2D g2 = (Graphics2D) g;
g2.setColor(Color.lightGray);
g2.setStroke(new BasicStroke(5));
g2.setPaint(new GradientPaint(0,0,Color.red,100,100,Color.blue,
true));
g2.fill3DRect(20, 20, g.getClipBounds().width-40,
g.getClipBounds().height-40, true);
g2.draw3DRect(10, 10, g.getClipBounds().width-20,
g.getClipBounds().height-20, true);
g2.fillRect(40, 40, g.getClipBounds().width-80,
g.getClipBounds().height-80);
int y1 = (g.getClipBounds().height / 30);
int x1 = (g.getClipBounds().width / 20);
g2.setTransform(AffineTransform.getScaleInstance(10, 10));
g2.setColor(Color.gray);
g2.draw3DRect(x1, y1, 3, 3, false);
g2.fill3DRect(x1, y1*2, 4, 4, false);
}
});
f.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent we) {
we.getWindow().dispose();
}
});
f.setSize(200, 300);
f.show();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[general] Marking JIRA issues before creation of patches.
Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - 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] jira issues tracking
+1 On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Salikh Zakirov wrote: Hi, I have just tried to use JIRA to see how many unapplied patches are there for DRLVM, but couldn't search just for the issues with patch provided. Does anyone know of a good way to find just the issues with patches submitted? If there is no good way, probably subtasks feature of JIRA could be used, e.g., create subtask for each patch submitted. Subtasks are then easily searchable. I have also seen that other projects in JIRA use Patch available status, but I do not know how non-committer could change the issue state, so this does not look like a solution. We could turn this on for non-committers - I see no danger... does anyone? +1 to open Patch Available to non-committers. ;-) Just notice that Geronimo has opened two additional JIRA status: Patch Available and Patch Reviewed. 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] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
+1 On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] HARMONY-790 is not reproducible
I'd add http://issues.apache.org/jira/browse/HARMONY-650 to the list of unassigned issues with patches. It has a patch for the test also. Could somebody take a look, please? On 8/30/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 8/30/06, Mark Hindess wrote: On 30 August 2006 at 11:14, Denis Kishenko [EMAIL PROTECTED] wrote: Mark and Geir thanks a lot. I understand you need time but most of them have pretty simple patches. Just because they are simple doesn't mean we can apply them without thinking or without taking the time to run sufficient tests. For instance, one of the JIRA you list contains a (simple!) bad fix that breaks an existing valid test. ;-( As I pointed out before even simple fixes are unlikely to be committed without patches for regression tests. Writing a concise test is often harder than writing the fix. +1 -Stepan. -Mark. 2006/8/30, Geir Magnusson Jr. [EMAIL PROTECTED]: Also, remember that people have to review the patch and decide that it's reasonable, not just blindly add them. That said, I'll start looking as well. geir Mark Hindess wrote: On 28 August 2006 at 16:14, Denis Kishenko [EMAIL PROTECTED] wrote: 2006/8/25, Mark Hindess [EMAIL PROTECTED]: Thanks for helping by looking at these. If you spot others and send messages and/or add comments in JIRA I'll take a look at them. Mark There are a lot of unassigned issues with patches in JIRA. For example most of issues listed bellow were created more then two weeks ago. http://issues.apache.org/jira/browse/HARMONY-1070 http://issues.apache.org/jira/browse/HARMONY-1118 http://issues.apache.org/jira/browse/HARMONY-1190 http://issues.apache.org/jira/browse/HARMONY-1131 http://issues.apache.org/jira/browse/HARMONY-1231 http://issues.apache.org/jira/browse/HARMONY-1168 http://issues.apache.org/jira/browse/HARMONY-1153 http://issues.apache.org/jira/browse/HARMONY-1107 http://issues.apache.org/jira/browse/HARMONY- http://issues.apache.org/jira/browse/HARMONY-1175 http://issues.apache.org/jira/browse/HARMONY-1244 Some of these are fixes without regression test patches. That might be one reason why they are overlooked. Also it helps to indicate if the bug is a blocker for running applications. Also there are several assigned but not resolved issues which have patch es to o. http://issues.apache.org/jira/browse/HARMONY-1031 http://issues.apache.org/jira/browse/HARMONY-1139 http://issues.apache.org/jira/browse/HARMONY-1148 http://issues.apache.org/jira/browse/HARMONY-1081 http://issues.apache.org/jira/browse/HARMONY-1184 http://issues.apache.org/jira/browse/HARMONY-1169 I'll let the respective assignees comment on these. Could you please look at these issues? I'll try to look at those which have regression tests (at least). -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Denis M. Kishenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Serialization problem with EnumSet
It looks like EnumSet.SerializationProxy is the class that is serialized instead of EnumSet, since it overrides readResolve method and contains the information, essential for re-creation of EnumSet. Probably, the scheme looks like this: 1) EnumSet overrides writeReplace which returns appropriate EnumSet.SerializationProxy object, which is serialized. 2) When EnumSet.SerializationProxy is deserialized, readResolve method is called to replace deserialized instance of EnumSet.SerializationProxy with appropriate EnumSet object. This method constructs EnumSet object with one of its factory methods (noneOf suits for this, probably) and initializes it properly. See API specification for Serializable interface for the description of readResolve/writeReplace. I am not an expert in serialization, so I am not sure if we need to copy this behavior to be compatible with RI or it is possible just to use SerialVersionUID and serialized form of EnumSet.SerializationProxy for our EnumSet. On 8/14/06, Spark Shen [EMAIL PROTECTED] wrote: Hi All: After reading the serialized form of EnumSet, I found an inner class java.util.EnumSet.SerializationProxy. This class does not have any extra explaination. Does any one has any suggestion on how to deal with it? Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Exceptions found while running servlet...
Hmm, probably, you should try to set JAVA_HOME=c:\harmony\ On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: I am using the JRE snapshot (I did not build anything, just unpacked a ZIP): pre-alpha : not complete or compatible svn = r428649, (Aug 4 2006), Windows/ia32/msvc 1310, release build This is what I downloaded: * http://people.apache.org/dist/incubator/harmony/snapshots/latest-jre-windows.zip Yes I do have this class: org.apache.harmony.awt.gl.ImageSurface Should I set additional environment variable when starting my process? I am using: set path=c:\harmony\bin;%path% java -jar winstone-0.8.2-cvs.jar --config=./winstone.conf And seems to work fine for most cases, Harmony has only complained about that specific class. Should I include the /lib/boot to the %path%? Regards, Martin On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... Do you use harmony snapshot? I tried to run simple test which creates BufferedImage with aug 04 snapshot and got an UnsatisfiedLinkError instead of it. But absence of the gl.dll in that snapshot is a known issue and likely to be fixed in the next snapshot. Maybe you could try to look into your HARMONY_HOME/lib/boot/awt.jar and check if it includes org.apache.harmony.awt.gl.ImageSurface class? The snapshot has it and there shouldn't be any problems with loading this class. If you built harmony from sources, please consider refreshing awt module and rebuilding with -Dwith.awt.swing=true On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: Is it OK to send this type of feedback to the list? please let me know if not, and what subject conventions should I use (is there a link about this?). I am not a Harmony developer, just a new user, I can only provide feedback from my tests. I am running a small webapp, using Winstone servlet engine and IBM JDK 1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4), and found these exceptions: 1.- I see this error while using servlet includes and also at the end of some pages: java.lang.ArrayIndexOutOfBoundsException: 0..0 at org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java) at org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194) at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647) at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152) at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at java.io.PrintWriter.doWrite(PrintWriter.java:640) at java.io.PrintWriter.write(PrintWriter.java:622) at winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45) at java.io.PrintWriter.write(PrintWriter.java:607) at java.io.PrintWriter.write(PrintWriter.java:657) at java.io.PrintWriter.print(PrintWriter.java:455) at 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... The JDBC related code is running fine, performance also looks very good. I will contact Winstone developer to see if he can help in some way to identify the problem. He already helped me a few months ago to help identify a bug in GNU Classpath server socket API. 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] - Terms of use : http://incubator.apache.org
Re: Exceptions found while running servlet...
Unfortunately, imageio is not implemented yet. On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: Oleg: I added that line, but still cannot find the class, the JVM prints this log msg: Loading of javax/imageio/ImageIO class failed due to java/lang/ClassNotFoundException Which JAR should I check to see if this class is contained? Regards, Martin On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hmm, probably, you should try to set JAVA_HOME=c:\harmony\ On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: I am using the JRE snapshot (I did not build anything, just unpacked a ZIP): pre-alpha : not complete or compatible svn = r428649, (Aug 4 2006), Windows/ia32/msvc 1310, release build This is what I downloaded: * http://people.apache.org/dist/incubator/harmony/snapshots/latest-jre-windows.zip Yes I do have this class: org.apache.harmony.awt.gl.ImageSurface Should I set additional environment variable when starting my process? I am using: set path=c:\harmony\bin;%path% java -jar winstone-0.8.2-cvs.jar --config=./winstone.conf And seems to work fine for most cases, Harmony has only complained about that specific class. Should I include the /lib/boot to the %path%? Regards, Martin On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... Do you use harmony snapshot? I tried to run simple test which creates BufferedImage with aug 04 snapshot and got an UnsatisfiedLinkError instead of it. But absence of the gl.dll in that snapshot is a known issue and likely to be fixed in the next snapshot. Maybe you could try to look into your HARMONY_HOME/lib/boot/awt.jar and check if it includes org.apache.harmony.awt.gl.ImageSurface class? The snapshot has it and there shouldn't be any problems with loading this class. If you built harmony from sources, please consider refreshing awt module and rebuilding with -Dwith.awt.swing=true On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: Is it OK to send this type of feedback to the list? please let me know if not, and what subject conventions should I use (is there a link about this?). I am not a Harmony developer, just a new user, I can only provide feedback from my tests. I am running a small webapp, using Winstone servlet engine and IBM JDK 1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4), and found these exceptions: 1.- I see this error while using servlet includes and also at the end of some pages: java.lang.ArrayIndexOutOfBoundsException: 0..0 at org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java) at org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194) at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647) at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152) at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at java.io.PrintWriter.doWrite(PrintWriter.java:640) at java.io.PrintWriter.write(PrintWriter.java:622) at winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45) at java.io.PrintWriter.write(PrintWriter.java:607) at java.io.PrintWriter.write(PrintWriter.java:657) at java.io.PrintWriter.print(PrintWriter.java:455) at 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... The JDBC related code is running fine, performance also looks very good. I will contact Winstone developer to see if he can help in some way to identify the problem
Re: [general] platform support
This public document I've found with Google proves that SetUnhandledExceptionFilter is a real candidate for Win2k and production level VM It says also that VM would wrap all JNI and thread start calls into __try/__except. This is exactly what Gregory complained about. On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: + This public document I've found with Google proves that SetUnhandledExceptionFilter is a real candidate for Win2k and production level VM http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf 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. On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: The SWT FAQ mentions that the same issue, and recommends the following GDI+ redistributable from Microsoft: Good, so GDI+ is not a problem! -- Mikhail Fursov -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
BTW what are the real advantages of having one binary? I'd say that having separate binaries is more flexible solution in general: 1. Don't care about performance degradation due to runtime checks. 2. Easy to port to new platforms by expanding #define's. 3. Possibility to link statically against platform-specific libraries. 4. Easy to code platform-specific calls without additional code for dynamic invocations (calling by name, etc.). 5. Possibility of implementing functionality for one particular platform (e.g., we have something on XP for free and need to do a hard work enabling it on 2K), easy platform specific performance tuning. 6. Usage of platform-specific definitions won't break the build on other platforms. And the cost of having one binary rises with the number of differences in the API used. IMO, the best solution is to switch to the separate binary when the amount of platform-specific code becomes not neglible, say 1% :) Or the workload of this code (is it the right word?) becomes reasonably high, resulting in significant performance degradation due to runtime checks. So the question is: should we aim to have a single binary that works on W2K PIII /and/ WinXP IPF ? Hmm, are PIII and IPF binary compatible? At least, there are a lot of compile-time optimizations specific to IPF, if I am not missing something... thanks, Oleg On 8/9/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Maybe I'm missing something here, but we 'support' what ever code we have in our SVN. If somebody wants to work on the code to make it good for W2K, or Win95, or WinCE ... then why not? Would we really say 'no'? I agree that we may have more than one binary snapshot/release for different Windows versions -- but it is one code base, one configure/make build, etc. So the question is: should we aim to have a single binary that works on W2K PIII /and/ WinXP IPF ? That's a different question, isn't it? Yes, it is the question you also pose elsewhere -- can we have a binary that either (a) uses the lowest common denominator of the different windows platforms API without incurring an undue penalty performance, or (b) performs runtime checks and picks the best available APIs. 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: [general] platform support
The right way to do this would be to have different code bases and different distributions for W2K and WinXP. Having different codebases is far worse, this implies separate test suites, increased complexity of the build system and other bad things. It would be better to avoid this if possible. On 8/9/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I think Oleg has summarized and expressed better many of the things I was trying to say. A single binary on a least common denominator platform is a legacy binary. It runs unoptimized on other platforms. Though the term Win precedes these Microsoft operatig systems, that's a brand. W2K, WinXP etc. arecompletely different OS's with lose backward compatibility. The right way to do this would be to have different code bases and different distributions for W2K and WinXP. This may grow worse with Vista. That is unfortunate, but that is how Microsoft OS's are. Thanks, Rana On 8/9/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: BTW what are the real advantages of having one binary? I'd say that having separate binaries is more flexible solution in general: 1. Don't care about performance degradation due to runtime checks. 2. Easy to port to new platforms by expanding #define's. 3. Possibility to link statically against platform-specific libraries. 4. Easy to code platform-specific calls without additional code for dynamic invocations (calling by name, etc.). 5. Possibility of implementing functionality for one particular platform (e.g., we have something on XP for free and need to do a hard work enabling it on 2K), easy platform specific performance tuning. 6. Usage of platform-specific definitions won't break the build on other platforms. And the cost of having one binary rises with the number of differences in the API used. IMO, the best solution is to switch to the separate binary when the amount of platform-specific code becomes not neglible, say 1% :) Or the workload of this code (is it the right word?) becomes reasonably high, resulting in significant performance degradation due to runtime checks. So the question is: should we aim to have a single binary that works on W2K PIII /and/ WinXP IPF ? Hmm, are PIII and IPF binary compatible? At least, there are a lot of compile-time optimizations specific to IPF, if I am not missing something... thanks, Oleg - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support
It has a building cost, but the major overhead is not building, but testing. If we were to support a platform, we would need to test on it anyway. Good point! So, common denominator approach has at least that advantage that it needs less testing - on one platform. On 8/9/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On 8/9/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, it is the question you also pose elsewhere -- can we have a binary that either (a) uses the lowest common denominator of the different windows platforms API without incurring an undue penalty performance, or (b) performs runtime checks and picks the best available APIs. There are distinct approaches as I understand it. One option is a single binary image that contains code that supports multiple platforms seperately by doing a dynamic check for platform. Though less pernicious than a least common denominator approach, these runtime checks are not healthy for a binary image that targets performance. So if our ideal platform were XinXP, we would incur a penalty repeatedly when running with it to accomodate the fact that this binary could have also run on W2k. The second option is to use a least common denominator approach where we use code/functionality that is only available on the least platform. This is not a good idea for obvious reasons. For example it is not a good idea not to use the excellent vectored exception handling on WinXP and Win2003( which intentionally sharethe same debug and kernel codebases )If this were not, we would be writing code for DOS only. The third is to have a single codebase with the right _WIN32_WINNT guards to distinguish platform specific code, and build seperate distributions for seperate platforms. This is the most performance friendly. It has a building cost, but the major overhead is not building, but testing. If we were to support a platform, we would need to test on it anyway. Thanks, Rana - 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
Maybe [1] will give some additional info. It is out of the context of DRLVM discussion, but awt uses GDI+ extensively. According to [1] GDI+ is not available on w2k. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro/sdkintro/windows_xp.asp On 8/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Oleg Khaschansky wrote: The right way to do this would be to have different code bases and different distributions for W2K and WinXP. Having different codebases is far worse, this implies separate test suites, increased complexity of the build system and other bad things. It would be better to avoid this if possible. If you are going ot claim that you support a given platform, you better test on that platform. I agree that separate codebases have problematic aspects (such as ensuring that bugs are fixed in all codebases for a given version). I'll argue again that will help this conversation is a techincal discussion about what in DRLVM is winXP specific, what the alternatives are, and what the costs are. Geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Strange serialized form of java.util.TreeMap (re JIRA harmony-1066)
Shall we follow RI on this odd behavior in harmony?
My opinion is that we should not. But if 1.5 has deserialization issue
it won't be possible to make it read SubMap, serialized by harmony,
correctly. And I think this it's not a problem for us.
On 8/8/06, Spark Shen [EMAIL PROTECTED] wrote:
Hi, thank you for your information.
I slightly modified my second test case and run it on JDK6-beta.
public void test_HeadMap_Serializable() throws Exception {
// same as before
*assertNotNull(((SortedMap)outputObject).entrySet()); // This line
assertNull previously.*
assertNotNull(((SortedMap)outputObject).keySet());
assertNotNull(((SortedMap)outputObject).values());
*assertEquals(outputObject, headMap); // This line is previously
commented out, and now passes on JDK6.*
}
IMO, this shows that Inner classes of TreeMap on JDK5 do not have proper
serialization behavior. Shall we follow RI on this odd behavior in harmony?
Personally, I am against this.
Best regards
Oleg Khaschansky 写道:
Hi,
Take a look at this:
http://download.java.net/jdk6/docs/api/serialized-form.html
Maybe this document will give you an idea of what are those inner
classes... Of cause, in the new release serialized form may have
changed.
--
Oleg
On 8/7/06, Spark Shen [EMAIL PROTECTED] wrote:
Hi:
This is a long post, thanks for your patient to read it through :-)
I wrote a test case as below:
public void test_SubMap_Serializable() throws Exception {
TreeMapInteger, Double map = new TreeMapInteger, Double();
map.put(1, 2.1);
map.put(2, 3.1);
map.put(3, 4.5);
map.put(7, 21.3);
SortedMapInteger, Double headMap = map.headMap(3);
assertTrue(headMap instanceof Serializable);
assertFalse(headMap instanceof TreeMap);
assertTrue(headMap instanceof SortedMap);
}
Which says the returned headMap is not a TreeMap but a serializable
SortedMap.
IIRC, there are three mysterious serialized form immediately following
the serialized form of java.util.TreeMap. They are
Class **java.util.TreeMap$1** extends Object implements Serializable
Class **java.util.TreeMap$2** extends Object implements Serializable
Class **java.util.TreeMap$3** extends Object implements Serializable
respectively. This gives a hint that there are three inner classes of
TreeMap which should be serializable.
But what are they indeed?
IMHO, the returned SortedMap may
be one of the java.util.TreeMap$x classes. What is your opinion? (I
raised JIRA-1066 for this)
The above test case suggests me to make the returned SortedMap
serializable. But, I have another concern:
SortedMap returned by TreeMap is not a public class(does not have a
documented Serialized form), and the serialization behavior of this
SortedMap is strange. See the test case below:
public void test_HeadMap_Serializable() throws Exception {
TreeMapInteger, Double map = new TreeMapInteger, Double();
map.put(1, 2.1);
map.put(2, 3.1);
map.put(3, 4.5);
map.put(7, 21.3);
SortedMapInteger, Double headMap = map.headMap(3);
assertTrue(headMap instanceof Serializable);
assertFalse(headMap instanceof TreeMap);
assertTrue(headMap instanceof SortedMap);
// Write the SortedMap out and read it back.
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(headMap);
oos.close();
ByteArrayInputStream bis = new
ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
Object outputObject = (Object) ois.readObject();
*assertNull(((SortedMap)outputObject).entrySet());
assertNotNull(((SortedMap)outputObject).keySet());
assertNotNull(((SortedMap)outputObject).values());
* *// assertEquals(outputObject, headMap);*
}
The commented out assertion will throw out a NullPointerException, and
the entrySet of the SortedMap is Null while keySet and values are not.
This is strange. Do we need to follow RI to make the returned SortedMap
serializable like this?
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
Re: [classlib][luni] Strange serialized form of java.util.TreeMap (re JIRA harmony-1066)
Hi,
Take a look at this: http://download.java.net/jdk6/docs/api/serialized-form.html
Maybe this document will give you an idea of what are those inner
classes... Of cause, in the new release serialized form may have
changed.
--
Oleg
On 8/7/06, Spark Shen [EMAIL PROTECTED] wrote:
Hi:
This is a long post, thanks for your patient to read it through :-)
I wrote a test case as below:
public void test_SubMap_Serializable() throws Exception {
TreeMapInteger, Double map = new TreeMapInteger, Double();
map.put(1, 2.1);
map.put(2, 3.1);
map.put(3, 4.5);
map.put(7, 21.3);
SortedMapInteger, Double headMap = map.headMap(3);
assertTrue(headMap instanceof Serializable);
assertFalse(headMap instanceof TreeMap);
assertTrue(headMap instanceof SortedMap);
}
Which says the returned headMap is not a TreeMap but a serializable
SortedMap.
IIRC, there are three mysterious serialized form immediately following
the serialized form of java.util.TreeMap. They are
Class **java.util.TreeMap$1** extends Object implements Serializable
Class **java.util.TreeMap$2** extends Object implements Serializable
Class **java.util.TreeMap$3** extends Object implements Serializable
respectively. This gives a hint that there are three inner classes of
TreeMap which should be serializable.
But what are they indeed?
IMHO, the returned SortedMap may
be one of the java.util.TreeMap$x classes. What is your opinion? (I
raised JIRA-1066 for this)
The above test case suggests me to make the returned SortedMap
serializable. But, I have another concern:
SortedMap returned by TreeMap is not a public class(does not have a
documented Serialized form), and the serialization behavior of this
SortedMap is strange. See the test case below:
public void test_HeadMap_Serializable() throws Exception {
TreeMapInteger, Double map = new TreeMapInteger, Double();
map.put(1, 2.1);
map.put(2, 3.1);
map.put(3, 4.5);
map.put(7, 21.3);
SortedMapInteger, Double headMap = map.headMap(3);
assertTrue(headMap instanceof Serializable);
assertFalse(headMap instanceof TreeMap);
assertTrue(headMap instanceof SortedMap);
// Write the SortedMap out and read it back.
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(headMap);
oos.close();
ByteArrayInputStream bis = new
ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
Object outputObject = (Object) ois.readObject();
*assertNull(((SortedMap)outputObject).entrySet());
assertNotNull(((SortedMap)outputObject).keySet());
assertNotNull(((SortedMap)outputObject).values());
**// assertEquals(outputObject, headMap);*
}
The commented out assertion will throw out a NullPointerException, and
the entrySet of the SortedMap is Null while keySet and values are not.
This is strange. Do we need to follow RI to make the returned SortedMap
serializable like this?
Best regards
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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] Enhance the functionalities provided by BitSet
Do you mean to write a specific BitSet using one long type as its internal storage to deal with =64 elements enums? No, I suggest to implement a specific EnumSet using one long type. My opinion is that a specific =64 BitSet wouldn't be very useful. On 8/4/06, Spark Shen [EMAIL PROTECTED] wrote: Oleg Khaschansky 写道: Yes, I mean exactly one long type, not array. And I think that for this case the code in the BitSet and EnumSet implementation would be pretty simplier and then faster. Do you mean to write a specific BitSet using one long type as its internal storage to deal with =64 elements enums? But the =64 bit BitSet looks not very useful, so I don't suggest to optimize it. At the same time =64 elemnts enums are, probably, used much more often and EnumSet could be optimized in this way. It is just a suggestion, hope that it could be useful. Thank you very much for your suggestion. Best regards. On 8/3/06, Spark Shen [EMAIL PROTECTED] wrote: Oleg Khaschansky 写道: Hi all! I'd like to add to this discussion that, IMHO, implementation of the EnumSet based on the BitSet class, probably, would be relatively slow. I can not fully agree with you here. IIRC, BitSet already uses long array to store bits instead of Byte[] in our implementation. Every bit in any long of the long array corresponds to a enum type element. IMHO, this is the most effcient way to store bits. The only down side of using BitSet is that there are extra method invokations. I'd suggest to handle extra case when the number of elements in the enum is = 64 and it is possible to represent the set with one long value. For this case all the EnumSet API could be implemented using fast bitwise operations. Since the long array storage, no matter the number of elements in an enum type, fast bitwise operations can be applied. Do you mean to do extra optimization when number of elements in enum type is less than 64. Under this condition, may be we can use one long type instead of a long array. But will this kind of optimization bring any bonus is unknown right now. Correct me if I am wrong. Best regards Thank you. -- Oleg Khaschansky, Intel MPD On 8/3/06, Spark Shen [EMAIL PROTECTED] wrote: Richard Liang 写道: Spark Shen wrote: Hi All: IMHO, EnumSet provides a set view of enum types. According to its spec, Enum sets are represented internally as bit vectors. To avoid to re-invent the wheel, it could be more reasonable to utilize java.util.BitSet class to support the implementation of EnumSet. Agree :-) While current API methods provided by BitSet is not enough, I need to extend the function provided by BitSet. There are 2 options: 1. Implement these extension methods in BitSet directly as package private methods 2. Construct a package private utility class in org.apache.harmony.luni.util package, and implement extensions in this implementation class. I prefer the first option, since there is not many classes need these extension. If no objections, I will adopt the first schema. IMHO, it depends on the relationship between the extended functions and the whole class. Would you please provide more detail information? Thanks a lot. 1. It can be simply detected that on RI, EnumSet.noneOf() or EnumSet.allOf() method will return a concrete EnumSet. This concrete EnumSet provides its own iterator. All these iterator related methods are not implemented in BitSet right now. 2. To support the implementation of EnumSet, more utility methods used to set/unset bits may need to be added. All these requirements are EnumSet specific, do they need to be implemented in a separate class. Best regards Richard. Best regards. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [classlib][luni]Compatibility: java.util.GregorianCalendar
Take a look at this: http://www.twinsun.com/tz/tz-link.htm. According to them: Sun Java releases since 1.4 contain a copy of a subset of a recent tz database in a Java-specific format. It is not a bug that the range is greater then from -12 to +12. If you look into MS windows date/time settings - the range is from -12 to +13 there. And don't forget about daylight savings - there are summer/winter time zones. Also, I found a table at http://wwp.greenwichmeantime.com/info/timezone.htm and there are time zones from -12 to +14. -- Oleg On the other hand, I found a list of time zones at On 8/4/06, Richard Liang [EMAIL PROTECTED] wrote: Hello All, Several test cases in tests.api.java.util.GregorianCalendarTest fail on RI 5.0 because The maximum and minimum Calendar.ZONE_OFFSET of Harmony and RI are different. And I cound not find any related information in the specification. Could anybody suggest? Thanks a lot. Consider the following code: GregorianCalendar calendar = new GregorianCalendar(); System.out.println(Maximun zone offset(hour): + calendar.getMaximum(Calendar.ZONE_OFFSET)/360); System.out.println(Minimun zone offset(hour): + calendar.getMinimum(Calendar.ZONE_OFFSET)/360); *Output on RI 1.5.0_07:* Maximun zone offset(hour): 14 Minimun zone offset(hour): -13 *Output on Harmony:* Maximun zone offset(hour): 12 Minimun zone offset(hour): -12 Best regards, -- 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: [classlib][luni] Enhance the functionalities provided by BitSet
That is a good idea. But some guru says developers are used to optimize code at inappropriate spot. :-) . Kidding Microbenchmark may help to make right decision :) On 8/4/06, Spark Shen [EMAIL PROTECTED] wrote: Oleg Khaschansky 写道: Do you mean to write a specific BitSet using one long type as its internal storage to deal with =64 elements enums? No, I suggest to implement a specific EnumSet using one long type. My opinion is that a specific =64 BitSet wouldn't be very useful. Thank you for your suggestion. You mean to implement a specific EnumSet without wrapping BitSet when elements in enum is =64. That is a good idea. But some guru says developers are used to optimize code at inappropriate spot. :-) . Kidding I will consider your suggestion seriously.. Best regards On 8/4/06, Spark Shen [EMAIL PROTECTED] wrote: Oleg Khaschansky 写道: Yes, I mean exactly one long type, not array. And I think that for this case the code in the BitSet and EnumSet implementation would be pretty simplier and then faster. Do you mean to write a specific BitSet using one long type as its internal storage to deal with =64 elements enums? But the =64 bit BitSet looks not very useful, so I don't suggest to optimize it. At the same time =64 elemnts enums are, probably, used much more often and EnumSet could be optimized in this way. It is just a suggestion, hope that it could be useful. Thank you very much for your suggestion. Best regards. On 8/3/06, Spark Shen [EMAIL PROTECTED] wrote: Oleg Khaschansky 写道: Hi all! I'd like to add to this discussion that, IMHO, implementation of the EnumSet based on the BitSet class, probably, would be relatively slow. I can not fully agree with you here. IIRC, BitSet already uses long array to store bits instead of Byte[] in our implementation. Every bit in any long of the long array corresponds to a enum type element. IMHO, this is the most effcient way to store bits. The only down side of using BitSet is that there are extra method invokations. I'd suggest to handle extra case when the number of elements in the enum is = 64 and it is possible to represent the set with one long value. For this case all the EnumSet API could be implemented using fast bitwise operations. Since the long array storage, no matter the number of elements in an enum type, fast bitwise operations can be applied. Do you mean to do extra optimization when number of elements in enum type is less than 64. Under this condition, may be we can use one long type instead of a long array. But will this kind of optimization bring any bonus is unknown right now. Correct me if I am wrong. Best regards Thank you. -- Oleg Khaschansky, Intel MPD On 8/3/06, Spark Shen [EMAIL PROTECTED] wrote: Richard Liang 写道: Spark Shen wrote: Hi All: IMHO, EnumSet provides a set view of enum types. According to its spec, Enum sets are represented internally as bit vectors. To avoid to re-invent the wheel, it could be more reasonable to utilize java.util.BitSet class to support the implementation of EnumSet. Agree :-) While current API methods provided by BitSet is not enough, I need to extend the function provided by BitSet. There are 2 options: 1. Implement these extension methods in BitSet directly as package private methods 2. Construct a package private utility class in org.apache.harmony.luni.util package, and implement extensions in this implementation class. I prefer the first option, since there is not many classes need these extension. If no objections, I will adopt the first schema. IMHO, it depends on the relationship between the extended functions and the whole class. Would you please provide more detail information? Thanks a lot. 1. It can be simply detected that on RI, EnumSet.noneOf() or EnumSet.allOf() method will return a concrete EnumSet. This concrete EnumSet provides its own iterator. All these iterator related methods are not implemented in BitSet right now. 2. To support the implementation of EnumSet, more utility methods used to set/unset bits may need to be added. All these requirements are EnumSet specific, do they need to be implemented in a separate class. Best regards Richard. Best regards. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony
Re: [classlib][luni] Enhance the functionalities provided by BitSet
Hi all! I'd like to add to this discussion that, IMHO, implementation of the EnumSet based on the BitSet class, probably, would be relatively slow. I'd suggest to handle extra case when the number of elements in the enum is = 64 and it is possible to represent the set with one long value. For this case all the EnumSet API could be implemented using fast bitwise operations. Thank you. -- Oleg Khaschansky, Intel MPD On 8/3/06, Spark Shen [EMAIL PROTECTED] wrote: Richard Liang 写道: Spark Shen wrote: Hi All: IMHO, EnumSet provides a set view of enum types. According to its spec, Enum sets are represented internally as bit vectors. To avoid to re-invent the wheel, it could be more reasonable to utilize java.util.BitSet class to support the implementation of EnumSet. Agree :-) While current API methods provided by BitSet is not enough, I need to extend the function provided by BitSet. There are 2 options: 1. Implement these extension methods in BitSet directly as package private methods 2. Construct a package private utility class in org.apache.harmony.luni.util package, and implement extensions in this implementation class. I prefer the first option, since there is not many classes need these extension. If no objections, I will adopt the first schema. IMHO, it depends on the relationship between the extended functions and the whole class. Would you please provide more detail information? Thanks a lot. 1. It can be simply detected that on RI, EnumSet.noneOf() or EnumSet.allOf() method will return a concrete EnumSet. This concrete EnumSet provides its own iterator. All these iterator related methods are not implemented in BitSet right now. 2. To support the implementation of EnumSet, more utility methods used to set/unset bits may need to be added. All these requirements are EnumSet specific, do they need to be implemented in a separate class. Best regards Richard. Best regards. -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][beans] RI violates the spec in the Statement class
According to 15.9.3 Choosing the Constructor and its Arguments:
Once the actual arguments have been determined, they are used to
select a constructor of C, using the same rules as for method
invocations (§15.12).
On 8/3/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Well constructor is not a method :)
so RI and Harmony are not necessary violate the spec
I'd probably stick to the current behavior
Thanks,
Mikhail
2006/8/3, Alexei Zakharov [EMAIL PROTECTED]:
As far as I understand RI simply take the first declared method. In
other words, if we swap constructors in the above example like this
public static class MyBean {
static String calledM = null;
public MyBean(Integer arg) {
calledM = new2;
}
public MyBean(Object arg) {
calledM = new1;
}
}
the result will be PASS.
:-/
Thanks,
2006/8/3, Mikhail Loenko [EMAIL PROTECTED]:
How does RI behave if there are three methods? does it alway selects less
specific?
Thanks,
Mikhail
2006/8/3, Alexei Zakharov [EMAIL PROTECTED]:
Hi community,
I'd like to attract everyone's attention to another RI inconsistence.
It seems RI has a bug in the implementation of execute() method of the
java.beans.Statement class. The spec states:
1. When the target's class defines many methods with the given name
the implementation should choose the most specific method using the
algorithm specified in the Java Language Specification (15.11).
2. The reserved method name new may be used to call a class's
constructor as if all classes defined static new methods.
But the following test shows that RI does not follow these rules –
does not choose the most specific method:
import java.beans.*;
public class StatementTest {
public static class MyBean {
static String calledM = null;
public MyBean(Object arg) {
calledM = new1;
}
public MyBean(Integer arg) {
calledM = new2;
}
}
public static void main(String argv[]) throws Exception {
Statement stmt = new Statement(MyBean.class, new,
new Object[] { new Integer(17) });
stmt.execute();
if (!MyBean.calledM.equals(new2)) {
System.out.println(FAIL);
} else {
System.out.println(PASS);
}
}
}
The result is FAIL on RI. However, it behaves correctly for regular
methods (that aren't constructors). I think I should post Non-bug
differences from RI JIRA. I am also going to correct our
implementation of Statement since it is now compatible with RI. Any
objections?
Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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]
