RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
Stepan, all, I've created a JIRA to document the incompatibility of GapContent.replace(). There are several test cases added, and some of them are indirectly related to replace(). There's also patch which fixes incompatibilities of insertString() and remove(). By the way, HARMONY-1753 describes related problem which I suggest to resolve as non-bug difference. Regards, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 12:44 PM To: harmony-dev@incubator.apache.org Subject: RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java -Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 9:47 AM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java / comm on/javax/swing/text/GapContent.java On 11/8/06, Ivanov, Alexey A wrote: -Original Message- From: Stepan Mishura Sent: Wednesday, November 08, 2006 4:09 PM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java / comm on/javax/swing/text/GapContent.java 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? To summarize my position: I see no value in discussing compatibility issues on harmony-dev if a discussion doesn't have any outcome (JIRA to document a difference or a regression test to fix implementation behavior). IMHO, there are two JIRAs which document the issue: HARMONY-1809 and HARMONY-1975. I'll add another one to document the *incompatibility* in behaviour and add a small test case which will always fail on the RI (until a volunteer would make Harmony implementation compatible with RI in respect to GapContent.replace()). Thanks for your opinion, Stepan. Regards, Alexey. In our case evaluation of HARMONY-1809 and HARMONY-1975 showed a difference with RI. So we should fix/document it. Does this fit to 'Good Issue Resolution Guideline'? If a volunteer wants to make Harmony implementation of GapContent.replace() compatible with RI, they will provide many tests - to test all invalid and edge situations to ensure the behaviour is *compatible* - along with patch. And I see no reason to stop them. Sure, no reason to stop. (However, I believe a volunteer will search JIRA for GapContent before starting this work. And then they face this bug.) On the other hand, I hardly imagine an application depends on this functionality. That's why I haven't fixed it myself. IMHO, an assumption that there is no such application is not a reason for not documenting the difference. 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. It may make sense. From my experience it always makes sense to add a test (even simple and obvious). Thanks, Stepan. BWT, HARMONY-1809 should be marked as non-bug difference from RI. I'm against this. 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
RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
-Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 5:17 PM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java 2006/11/15, Ivanov, Alexey A [EMAIL PROTECTED]: Stepan, all, I've created a JIRA to document the incompatibility of GapContent.replace(). Great! What's the number? :) Sorry, missed one of the most important things :( https://issues.apache.org/jira/browse/HARMONY-2198 There are several test cases added, and some of them are indirectly related to replace(). There's also patch which fixes incompatibilities of insertString() and remove(). By the way, HARMONY-1753 describes related problem which I suggest to resolve as non-bug difference. Regards, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 12:44 PM To: harmony-dev@incubator.apache.org Subject: RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java -Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 9:47 AM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java / comm on/javax/swing/text/GapContent.java On 11/8/06, Ivanov, Alexey A wrote: -Original Message- From: Stepan Mishura Sent: Wednesday, November 08, 2006 4:09 PM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java / comm on/javax/swing/text/GapContent.java 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? To summarize my position: I see no value in discussing compatibility issues on harmony-dev if a discussion doesn't have any outcome (JIRA to document a difference or a regression test to fix implementation behavior). IMHO, there are two JIRAs which document the issue: HARMONY-1809 and HARMONY-1975. I'll add another one to document the *incompatibility* in behaviour and add a small test case which will always fail on the RI (until a volunteer would make Harmony implementation compatible with RI in respect to GapContent.replace()). Thanks for your opinion, Stepan. Regards, Alexey. In our case evaluation of HARMONY-1809 and HARMONY-1975 showed a difference with RI. So we should fix/document it. Does this fit to 'Good Issue Resolution Guideline'? If a volunteer wants to make Harmony implementation of GapContent.replace() compatible with RI, they will provide many tests - to test all invalid and edge situations to ensure the behaviour is *compatible* - along with patch. And I see no reason to stop them. Sure, no reason to stop. (However, I believe a volunteer will search JIRA for GapContent before starting this work. And then they face this bug.) On the other hand, I hardly imagine an application depends on this functionality. That's why I haven't fixed it myself. IMHO, an assumption that there is no such application is not a reason for not documenting the difference. 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. It may make sense. From my experience it always makes sense to add a test (even simple and obvious). Thanks, Stepan. BWT, HARMONY-1809 should be marked as non-bug difference from RI. I'm against this. 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
RE: [doc] site.css
-Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 10:49 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc] site.css 2006/11/14, Nathan Beyer [EMAIL PROTECTED]: Spaces only please! +1 OK. I'll convert all tabs to spaces and remove all tailing white-space and file a JIRA with a patch. Regards, Alexey. On 11/13/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hi all, I've updated formatting of definition lists DL on site: https://issues.apache.org/jira/browse/HARMONY-2173 The new formatting looks more natural to me; the screenshots can be found in the JIRA issue. When editing site.css I faced that there are many different styles of indentation used: * Some statements are indented using tabs, * Some -- using spaces, * And a mixture of tabs and space, in the worse case. There are also inconsistencies in formatting of rules, and trailing white-space. Let's agree on using either tabs or spaces for indentation of CSS statements. If they are different, it causes inconveniences when creating patches because some lines look changed while nothing was modified there. I have no strong opinion on which one to use here. But let it be one: either tabs or spaces. What do you think about it? Thank you in advance, -- Alexey A. Ivanov Intel EnterpriseSolutions SoftwareDivision -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
RE: [classlib][swing] Serialization of Swing classes
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 1:12 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Serialization of Swing classes Nathan Beyer wrote: Runtime optimization - I'm not positive of this, nor do I completely understand the actual affect, but wouldn't explicit 'serialVersionUID' fields mean that when those classes are actually serialized, a UID wouldn't need to be generated at runtime, correct? Now, I'll be the first to admit, this is a micro optimization, so it doesn't carry to much weight. However, I am curious about the details of the reality behind this thought, so if anyone knows, please post. Take a look at the effect of java.io.ObjectStreamClass#lookup(Class) for types that have a SUID field and those that don't. The actual work is done in ObjectStreamClass#computeSerialVersionUID(Class, Field[]), which scans the fields looking for a serialVersionUID field first, and computing it if not found using some non-trivial algorithm. The lookup result is cached, so any saving will be only on the first time the class is seen. Whether the computation is noticeable will depend upon the set of classes of objects being serialized as well as the presence (or absence) of the SUID field. Actually I don't mind having SUIDs declared in classes. Though IMHO without declaring this field, we communicate to developers serialized form of this class is not guaranteed to deserialize correctly. OTOH having looked through the methods Tim pointed, I can say that if classes declare SUID and one tries to serialize an object, there'll be no time spent to compute SUID during execution thus improving performance a little. Therefore I'm inclined to declare SUID rather than using @SuppressWarning(serial). However it may be worth to add a comment similar to that in the JavaDoc. What do you think? Regards, Alexey. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
[doc] site.css
Hi all, I've updated formatting of definition lists DL on site: https://issues.apache.org/jira/browse/HARMONY-2173 The new formatting looks more natural to me; the screenshots can be found in the JIRA issue. When editing site.css I faced that there are many different styles of indentation used: * Some statements are indented using tabs, * Some -- using spaces, * And a mixture of tabs and space, in the worse case. There are also inconsistencies in formatting of rules, and trailing white-space. Let's agree on using either tabs or spaces for indentation of CSS statements. If they are different, it causes inconveniences when creating patches because some lines look changed while nothing was modified there. I have no strong opinion on which one to use here. But let it be one: either tabs or spaces. What do you think about it? Thank you in advance, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Nadya, all, I've created JIRA issue and attached a patch to remove this extra table. See https://issues.apache.org/jira/browse/HARMONY-2140 I've checked several pages, nothing seems to be broken. Please review the changes. Regards, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 10:56 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I agree that the structure of the resulting HTML website page does not appear too linear. When editing the structure, I saw the additional table - and left as is; maybe, because I hoped somebody added it on some purpose. For me, the only matter of convenience is that all content that is varied on the page is in a separate table. If nobody has an idea why the structure is so complex, we can simplify it. The structure is defined in file site.vsl in site/xdocs/stylesheets. A JIRA with patch is welcome as usual. Thank you, Nadya Morozova -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
-Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 10:37 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, Thanks for the patch. I've looked it through and have fixed certain issues. The new patch is created (Harmony-2110). It'd be great, if you could find a chance to review it. Everything's fine. It's time to update the site then :) Regards, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:20 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL
RE: [classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 10:28 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][awt] Does Harmony awt support
win.xpstyle.dllName
desktop property in windows XP?
2006/11/9, Ivanov, Alexey A [EMAIL PROTECTED]:
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 9:51 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][awt] Does Harmony awt support
win.xpstyle.dllName
desktop property in windows XP?
On 11/9/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Andrew, you know a way! File a JIRA :)
ya, done, Harmony-2116.
http://issues.apache.org/jira/browse/HARMONY-2116
JIRAs are good, however, notifying dev-list of a problem is a good
thing
too because it attracts more attention to that problem.
So if one considers a problem is important, it's better to send a
message to dev-list as well as to create a JIRA issue.
It's better to create JIRA *AND* send a message to dev list :)
It is exactly what I meant.
Regards,
Alexey.
SY, Alexey
2006/11/9, Andrew Zhang [EMAIL PROTECTED]:
Thanks Dmitry and Paulex.
After applying Harmony-1887 patch, it returns valid property
value.
But there's another problem. Running following code against
Harmony
will
print NPE while RI returns silently.
public static void main(String[] args) {
MyToolkit myToolkit = new MyToolkit();
myToolkit.initializeDesktopProperties();
Map props = myToolkit.getDesktopProperties();
}
MyToolkit extends Toolkit, implements all abstract methods by
default
except
following two methods:
public Map getDesktopProperties() {
return desktopProperties;
}
public void initializeDesktopProperties() {
super.initializeDesktopProperties();
}
The output against Harmony:
java.lang.NullPointerException
at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java
:73)
at
java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
On 10/17/06, Dmitry Durnev [EMAIL PROTECTED] wrote:
AFAIK at least 4 'xpstyle'-related windows properties are not
described.
10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
How many are there that aren't described?
Sergey Soldatov wrote:
No, it doesn't. Unfortunately most of desktop properties
are
not
described
in j2se documentation. If you feel that we need to support
this
property please file JIRA issue and we'll try to fix it
ASAP.
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName
desktop
property
in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
-
Terms of use :
http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Dmitry A. Durnev,
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: harmony-dev-
[EMAIL PROTECTED]
--
Best regards,
Andrew Zhang
--
Best regards,
Andrew Zhang
--
Alexey A. Ivanov
Intel Middleware Product Division
--
Alexey A. Ivanov
Intel Middleware Product Division
RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
-Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 9:24 AM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java On 11/8/06, Ivanov, Alexey A wrote: -Original Message- From: Oleg Khaschansky Sent: Wednesday, November 08, 2006 4:20 PM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/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. I agree. This issue fixes bad method from JAPItools. Then we should create another JIRA to document the difference. Yep, I thought about it too. Regards, Alexey. -Stepan. Regards, Alexey. 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/jav a /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] -- Alexey A. Ivanov Intel Middleware Product Division -- 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] -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
-Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 9:47 AM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java On 11/8/06, Ivanov, Alexey A wrote: -Original Message- From: Stepan Mishura Sent: Wednesday, November 08, 2006 4:09 PM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java 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? To summarize my position: I see no value in discussing compatibility issues on harmony-dev if a discussion doesn't have any outcome (JIRA to document a difference or a regression test to fix implementation behavior). IMHO, there are two JIRAs which document the issue: HARMONY-1809 and HARMONY-1975. I'll add another one to document the *incompatibility* in behaviour and add a small test case which will always fail on the RI (until a volunteer would make Harmony implementation compatible with RI in respect to GapContent.replace()). Thanks for your opinion, Stepan. Regards, Alexey. In our case evaluation of HARMONY-1809 and HARMONY-1975 showed a difference with RI. So we should fix/document it. Does this fit to 'Good Issue Resolution Guideline'? If a volunteer wants to make Harmony implementation of GapContent.replace() compatible with RI, they will provide many tests - to test all invalid and edge situations to ensure the behaviour is *compatible* - along with patch. And I see no reason to stop them. Sure, no reason to stop. (However, I believe a volunteer will search JIRA for GapContent before starting this work. And then they face this bug.) On the other hand, I hardly imagine an application depends on this functionality. That's why I haven't fixed it myself. IMHO, an assumption that there is no such application is not a reason for not documenting the difference. 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. It may make sense. From my experience it always makes sense to add a test (even simple and obvious). Thanks, Stepan. BWT, HARMONY-1809 should be marked as non-bug difference from RI. I'm against this. 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
RE: Japi diffs for harmony
-Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:49 AM To: harmony-dev@incubator.apache.org Subject: Re: Japi diffs for harmony No problem on the name change, but doesn't what Stuart is talking about require that methods add this exception to the signature to actually show up in the reports? I guess the answer is yes. They can be added lazily when unimplemented methods are spotted. And new stubs should have this throws from the beginning. Maybe it's worth putting this info somewhere on the site. Also having this kind of declaration will simplify searching for not implemented methods. Regards, Alexey. On 11/8/06, Tim Ellison [EMAIL PROTECTED] wrote: Stuart Ballard wrote: Tim Ellison wrote: I'm no fan of stubs for just such reason. But for those dev's that are following along, there is an org.apache.harmony.luni.util.NotYetImplementedException that is defined for just such purposes. Would you consider renaming this to NotImplementedException since Japi recognizes that name in throws clauses and treats it specially? If you feel strongly about not changing the existing name, I can add NotYetImplementedException as an alternative hardcoded name in Japitools but that seems kinda redundant... What do you think? I have no objection to renaming it. If nobody objects in the next day or so then I'll go ahead and do it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
-Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya, we definetly need a link to this page. That's not a question. Question is where to place the link. And as I said in previous email link place suggestions are welcome. SY, Alexey 2006/11/7, Morozova, Nadezhda [EMAIL PROTECTED]: Alexey, Would be great if there we some page that had a link to the page; otherwise, you cannot find it from within wiki, only from the link in your mail :( Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey SNIP -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
-Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 2:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, Thank you so much for providing such a detailed review. I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Create as small test case, as possible sounds not very good. (The comma shouldn't be used here any way.) I think Create a test case as small as possible is better. What do you think? +1 The next item: ...about the steps to *reproduce* the bug. Using 'reproduce' is more conventional than 'recreate' in this case. Let it be recreate I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? And again extra comma: ...information about the failure, as possible: stack trace. You should remove it. Consider using bulleted list for enumeration here, I mean stack trace, failure output... might be marked up as list, how about it? Sorry, my fault, I've overlooked it. The comma shouldn't be there. IMHO we shouldn't use bulleted list in this case, since we do not publish the complete list of necessary diagnostic information, but just provide three examples. Suggest to leave it as it is. Yep, agree. Another point is lists can't be part of paragraph in HTML, thus you should remove the opening and closing tags of paragraph in the subsection. I mean: +subsection name=Reporting the Issue - p // remove it from file +ol ... /ol -p // remove it from file +/subsection +1, let's fix subsection Resolving *an* Issue. The first paragraph says To close *an* issue, define its type first. We're on stage of resolving here yet, so it should be To resolve an issue... Good catch! There's no ending punctuation in the list If reporter did not provide a patch to test:. Thanks! Should be fixed. Following, I'd re-write sentence like this: If you have any concerns, discuss *them* (was: questions) on the I'd say: If you have any questions, discuss them... That's even better :) IMHO, there are extra articles which should be omitted, however, I'm not a native speaker... Sorry, I'm not with you here. IMHO they are used appropriately. I won't insist on changing this. It's just my impression. subsection Closing *an* Issue. The first paragraph says we should define issue type first. I think the type is defined at the stage of resolving, thus it's better to use another word rather than 'define'. But nothing comes to mind at the moment. IMHO it's ok to say define. Before closing the issue, the one should know its type to choose the right way to deal with it, right? I'd leave it as it is. IIRC, non-bug difference issues are not closed. They are left open, to remind of the difference. Am I mistaken? Well, I'm not sure, really...you might know better... Oh, I've missed another place: All _pacthes_, test, and fix should be... Here the word *patch* is misspelled. To my mind, 'test and fix' explain which patches are meant, so this should be surrounded with commas, or even dashes (parentheses may be used as well). This change will make the sentence clearer: All patches - test and fix - should be... I'd better say: All patches, such as tests and fixes, should be Good! It's clearer. I can create another patch which will incorporate my comments, if you like. Go ahead, if you want to. Otherwise, I'll be glad to finalize it. Please let me know if you need my help. OK. I'll prepare patch update then. Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch
RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Sveta, all, I've attached the updated patch to the JIRA. Please review. Regards, Alexey. P.S. By the way, do we really need to place all the main content into another table? I've just looked at the source of the generated HTML file, and found it quite confusing. I agree to have a table to format the heading of the page and the list of contents on the left, but why there's another table where the main content is. I am about this one: /ul !-- end of the list of contents -- /td !-- end of list of contents cell -- td width=80% valign=topa name=top/a !-- the main content goes in this cell -- table cellspacing=0 cellpadding=2 width=100% !-- why is this table here -- trtd h1 a name=Good Issue Resolution GuidelineGood Issue Resolution Guideline/a /h1 /td/tr trtd... !-- and so on -- The comments here are added by me, and the source is slightly reformatted. I believe, the body part of the XML can be placed almost as is in the content cell of the top-level table without the need for another table because it's useless here. Or is it just Anakia limitation? -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Alexey, I'd change the heading Reporting the Issue to Reporting an Issue, or omit article at all. Well, both articles seem to be fine. Let it be a/an Maybe just omit articles then? Well, how about the third variant: Reporting Issues? I'm still for 'reproduce' because a bug can be (non-)reproducible but not recreatable. Any other opinions? Ok, reproduce is fine I'd say: If you have any questions, discuss them... That's even better :) Cool!:) All patches, such as tests and fixes, should be Good! It's clearer. Fine! OK. I'll prepare patch update then. Good luck! I'd be glad to review it, if you do not mind. :) Cheers, Sveta Thanks, Alexey. Best regards, Sveta -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:33 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:01 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've just submitted a new JIRA [http://issues.apache.org/jira/browse/HARMONY-2110]. I've added the necessary links from the website to the new page and have tried to perfect it a little. It would be great, if you could find a chance to look through the patch. Thanks in advance. Sveta, I've taken a look and added my comments to the JIRA itself. Regards, Alexey. Best regards, Sveta -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 11:18 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Good! Go ahead. Do you need help? I can review the patch - just let me know when you submit the JIRA. Thank you, Nadya Morozova -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 9:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Nadya wrote: Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html +1 it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. If you do not mind, I can create the necessary patches. Best regards, Sveta Konovalova -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 8:24 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) Well, I guess the simplest solution would be to add the link to the Conventions section on the front page of wiki. You can do it yourself! Adding a link from the static website would also be useful. Candidates: http://incubator.apache.org/harmony/guidelines.html http://incubator.apache.org/harmony/get-involved.html it's not quite convenient for me just now to add patches, so if someone volunteers to help, I'd be grateful. Thank you, Nadya Morozova -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:44 PM To: harmony-dev@incubator.apache.org Subject: Re
RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
Stepan, I must be missing something obvious... What kind of regression test do you expect? 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: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)
Hi, Do we really need a smiley in the header: Resolution Provider :)? AFAIK, for headings one should use Title Capitalization, i.e. first letter of each word is capitalized with exception for articles, prepositions, and conjunctions. Or am I wrong? Does anyone mind to mark up file names (build.xml) and paths (https://svn.apache.org/...) in monospaced font using code tags? Is it worth making repository path a link? And another comment. Will it be better to use different numbering in lists? I mean like this: 1. Issue is probably a non-bug... a. Discuss on dev-list. b. Add a link... 2. Issue is a bug: a. Notify the community... b. If reporter did not provide a patch to test... Any comments? Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs) I've published Good issue resolution guideline on Harmony site: http://incubator.apache.org/harmony/issue_resolution_guideline.html (wait for a while for the web site synchronization). It is not linked to other pages yet. So comments to guideline and link place suggestions are welcome. SY, Alexey 2006/9/28, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote: 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 :) And if you put in a patch for website, we can get it there too :) if you put in wiki, I'm going to take and put on site, so maybe save us some effort? (ok, save me the effort...) geir 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/trunk. 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 === -- Alexey A. Petrenko Intel Middleware Products Division
RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
-Original Message- From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 4:20 PM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/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. I agree. This issue fixes bad method from JAPItools. Regards, Alexey. 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/jav a /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] -- Alexey A. Ivanov Intel Middleware Product Division
RE: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
-Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 4:09 PM To: harmony-dev@incubator.apache.org Subject: Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm on/javax/swing/text/GapContent.java 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? If a volunteer wants to make Harmony implementation of GapContent.replace() compatible with RI, they will provide many tests - to test all invalid and edge situations to ensure the behaviour is *compatible* - along with patch. And I see no reason to stop them. (However, I believe a volunteer will search JIRA for GapContent before starting this work. And then they face this bug.) On the other hand, I hardly imagine an application depends on this functionality. That's why I haven't fixed it myself. 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. It may make sense. BWT, HARMONY-1809 should be marked as non-bug difference from RI. I'm against this. 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] -- Alexey A. Ivanov Intel Middleware Product Division
RE: [classlib][awt] Does Harmony awt support win.xpstyle.dllName desktop property in windows XP?
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 9:51 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][awt] Does Harmony awt support
win.xpstyle.dllName
desktop property in windows XP?
On 11/9/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
Andrew, you know a way! File a JIRA :)
ya, done, Harmony-2116.
http://issues.apache.org/jira/browse/HARMONY-2116
JIRAs are good, however, notifying dev-list of a problem is a good thing
too because it attracts more attention to that problem.
So if one considers a problem is important, it's better to send a
message to dev-list as well as to create a JIRA issue.
Regards,
Alexey.
2006/11/9, Andrew Zhang [EMAIL PROTECTED]:
Thanks Dmitry and Paulex.
After applying Harmony-1887 patch, it returns valid property value.
But there's another problem. Running following code against Harmony
will
print NPE while RI returns silently.
public static void main(String[] args) {
MyToolkit myToolkit = new MyToolkit();
myToolkit.initializeDesktopProperties();
Map props = myToolkit.getDesktopProperties();
}
MyToolkit extends Toolkit, implements all abstract methods by
default
except
following two methods:
public Map getDesktopProperties() {
return desktopProperties;
}
public void initializeDesktopProperties() {
super.initializeDesktopProperties();
}
The output against Harmony:
java.lang.NullPointerException
at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java
:73)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
On 10/17/06, Dmitry Durnev [EMAIL PROTECTED] wrote:
AFAIK at least 4 'xpstyle'-related windows properties are not
described.
10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
How many are there that aren't described?
Sergey Soldatov wrote:
No, it doesn't. Unfortunately most of desktop properties are
not
described
in j2se documentation. If you feel that we need to support
this
property please file JIRA issue and we'll try to fix it ASAP.
On 10/17/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi, does Harmony awt support win.xpstyle.dllName desktop
property
in
windows XP?
Consider following code:
public static void main(String[] args) {
Toolkit toolkit = Toolkit.getDefaultToolkit();
String xpstyleDll = (String) toolkit
.getDesktopProperty(win.xpstyle.dllName);
System.out.println(xpstyleDll);
}
RI Output:
C:\WINDOWS\resources\Themes\luna\luna.msstyles
Harmony Output:
null
--
Best regards,
Andrew Zhang
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Dmitry A. Durnev,
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: harmony-dev-
[EMAIL PROTECTED]
--
Best regards,
Andrew Zhang
--
Best regards,
Andrew Zhang
--
Alexey A. Ivanov
Intel Middleware Product Division
RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
-Original Message- From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 3:28 PM To: harmony-dev@incubator.apache.org Subject: 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? I've created a separate patch which also adds final modifier to three methods which are final according to the spec. There were two votes for silently ignoring BadLocationException which may be thrown from methods implementing replace() in Harmony. There were no other votes. Hence silent ignore was selected. Thanks for everybody who participated. Alexey. 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.htm l Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm l #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division -- Alexey A. Ivanov Intel Middleware Product Division
RE: [classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow
Good job, Daniel! -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Daniel Fridlender [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:22 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][java.math] optimization of BigInteger.modPow and BigInteger.pow Hi Alexey, yes we often tested the speed in our several attempts to improve performance. Comparing modPow before and after this new patch gave us the following figures: size before after 16 5.636e+05 6.351e+05 32 9.727e+04 1.293e+05 48 3.225e+04 4.623e+04 64 1.436e+04 2.148e+04 128 19413114 192590 970 256252 420 384 75127 512 32 55 where the first column shows the size of the arguments in bytes and the other two the number of modPow operations per 100 seconds before and after the patch. The method modPow is used in cryptography, we tested several cryptographic algorithms obtaining in all cases figures in favor of the optimized version (the one in the patch). For instance, for RSA key generation we obtained: size before after 5123,00 2,06 102420,1713,58 2048 280,38 149,48 where the first column shows the length of the key in bits and the other two the time in seconds taken to perform 30 iterations of the key generation algorithm before and after the patch. Thanks, Daniel On 11/3/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Hi, Daniel. Great job! Have you made any performance testing to understand how much the patch increases the speed of the methods? SY, Alexey 2006/11/3, Daniel Fridlender [EMAIL PROTECTED]: Hi, We have submitted in http://issues.apache.org/jira/browse/HARMONY-1981 an optimization of BigInteger methods modPow and pow. The optimization in modPow was achieved by introducing sliding windows instead of the square-and-multiply method. Some gain was obtained also from an optimized Montgomery multiplication used for computing squares. The method pow was optimized accordingly by improving the computation of squares. Thanks Daniel
RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
-Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 1:49 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour On 11/3/06, Ivanov, Alexey A wrote: -Original Message- From: Stepan Mishura Sent: Friday, November 03, 2006 9:43 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour On 11/2/06, Ivanov, Alexey A wrote: 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. SNIP Any objections, comments, opinions? Hi Alexey, Hi Stepan, I'm not quite convinced by your evaluation (I'm not an expert in Swing API so I may be wrong). My experiments with GapContent showed that Harmony Let me give a quick introduction what GapContent is then. This class serves as the default storage for all Document implementations within javax.swing.text. It stores text in char[] array... but with a gap in it. Using the default constructor the array will have length 10. And one character will be placed into the buffer; the other 9 characters in the array will be the gap, and they are not considered to be portion of the content. This prevents frequent re-allocations of the underlying storage array where text is inserted or removed. Moving the gap is cheaper than re-allocating the array. When an insert or remove occurs, the gap is moved so that it starts at the position of insert or remove. Thanks for the explanation. You're welcome. initially created different object then RI, for example, if you create an object with GapContent() constructor, Harmony will return start==0 and end==9 while RI will return start==1 and end==10. The next point that It doesn't really matter where the gap is. This difference shows only that the gap in the text buffer is located at different location. Using content.shiftGap(0) on RI, you'll get start = 0, end = 9. Accordingly using content.shiftGap(1) on Harmony, you'll get start = 1, end = 10. IMO it might be compatibly issue. I can extend GapContent class and it may depend on what getGapStart() and getGapEnd() return. No, it can't. Because these methods report where the gap is, and no one stops you from moving it to another location using GapContent protected methods. What matters is that content.length() = 1 in both cases, and content.getString(0, content.length()) returns \n. Actually, setting the gap to be at 0 is more efficient because the next (or first) insert is likely to happen at position 0 rather than 1. Therefore to insert text at position 0, the gap will be moved to 0 on RI (which involves array copying and some other operations). This won't be the case with Harmony because the gap is already at 0. If you do: GapContent gc = new GapContent(); gc.insertString(0, text); then gc.getGapStart() returns 4 on RI not 0 as you wrote. Of course! Because you added four characters: text. The gap was moved to position 0, the characters were copied to the array, and the gap position was updated. You can check it by getting the array with getArray() and examining its contents. The first four chars will be text and the last char at index 9 will be '\n'. To move gap, you should use shiftGap(). You can easily check that insertString() calls shiftGap() to move the gap in the array. Everything starting at getGapStart() index in the array up to getGapEnd() (not inclusive if I remember correctly) is garbage. If there's not enough space in the gap (array) to store new text, the array gets re-allocated which -- in its turn -- enlarges the gap. confuses me that the spec. says about position as logical position in the storage...and... This is not the location in the underlying storage array. So negative value for position may be considered as valid. It's all about how the text is stored in GapContent. Because there's a gap modeled the location in the underlying storage array differs from the logical position in storage. If you look at the spec of any methods which throw BadLocationException, you'll see that position (it's called 'where') is to be = 0. Since this method is used to perform operations of insertString() and remove() in RI, negative positions are invalid. I believe they put no checks here because validation of parameters is performed in those methods which call replace(). As I understood the spec. it is true for methods that change content but there is no such restriction for methods that work with gap (see shiftGapEndUp, shiftGapStartDown, shiftEnd, shiftGap) Yes, that's true. Because this methods are protected, you *must* understand what you do. Most likely you'll get
[classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
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. 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] Really trivial comment about exception messages
+1 Let it be consistent :) -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 1:30 PM To: Apache Harmony Dev List Subject: [classlib] Really trivial comment about exception messages While checking and applying some of Ilya's patches for internationalisation, I noticed that there were quite a few messages that end with a fullstop. Aside from the inconsistency (which unfortunately always seems to irritate me), it occurs to me that we will end up with stack traces that read like: IllegalArgumentException: position less than zero. at blah(blah.java:101) So, unless anyone objects, can we avoid putting fullstops on the end of exception messages. Thanks, Mark.
RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
-Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour HARMONY-1975is already applied and closed ;) Yep, I know. But the section with GapContent modification is *not* applied as can be seen from comments in the issue. Regards, Alexey. 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.htm l Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm l #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division -- Alexey A. Ivanov Intel Middleware Product Division
RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 5:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour Ivanov, Alexey A wrote: -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour HARMONY-1975is already applied and closed ;) Yep, I know. But the section with GapContent modification is *not* applied as can be seen from comments in the issue. Stepan explained why, and Oleg (as issue rasier) agreed/verified the issue for closure. The GapContent is covered by HARMONY-1809. Just let things take their course. And I agreed with both Stepan and Oleg as well. This discussion is part of the course to resolve HARMONY-1809. Regards, Alexey. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Middleware Product Division
RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
-Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 5:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour Why not? It was decided to resolve the issue with GapContent in issue: HARMONY-1809. Regards, Alexey. Ivanov, Alexey A wrote: -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 3:50 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour HARMONY-1975is already applied and closed ;) Yep, I know. But the section with GapContent modification is *not* applied as can be seen from comments in the issue. Regards, Alexey. 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.htm l Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm l #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division -- Alexey A. Ivanov Intel Middleware Product Division -- Alexey A. Ivanov Intel Middleware Product Division
RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour
-Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 9:43 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour On 11/2/06, Ivanov, Alexey A wrote: 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. SNIP Any objections, comments, opinions? Hi Alexey, Hi Stepan, I'm not quite convinced by your evaluation (I'm not an expert in Swing API so I may be wrong). My experiments with GapContent showed that Harmony Let me give a quick introduction what GapContent is then. This class serves as the default storage for all Document implementations within javax.swing.text. It stores text in char[] array... but with a gap in it. Using the default constructor the array will have length 10. And one character will be placed into the buffer; the other 9 characters in the array will be the gap, and they are not considered to be portion of the content. This prevents frequent re-allocations of the underlying storage array where text is inserted or removed. Moving the gap is cheaper than re-allocating the array. When an insert or remove occurs, the gap is moved so that it starts at the position of insert or remove. initially created different object then RI, for example, if you create an object with GapContent() constructor, Harmony will return start==0 and end==9 while RI will return start==1 and end==10. The next point that It doesn't really matter where the gap is. This difference shows only that the gap in the text buffer is located at different location. Using content.shiftGap(0) on RI, you'll get start = 0, end = 9. Accordingly using content.shiftGap(1) on Harmony, you'll get start = 1, end = 10. What matters is that content.length() = 1 in both cases, and content.getString(0, content.length()) returns \n. Actually, setting the gap to be at 0 is more efficient because the next (or first) insert is likely to happen at position 0 rather than 1. Therefore to insert text at position 0, the gap will be moved to 0 on RI (which involves array copying and some other operations). This won't be the case with Harmony because the gap is already at 0. confuses me that the spec. says about position as logical position in the storage...and... This is not the location in the underlying storage array. So negative value for position may be considered as valid. It's all about how the text is stored in GapContent. Because there's a gap modeled the location in the underlying storage array differs from the logical position in storage. If you look at the spec of any methods which throw BadLocationException, you'll see that position (it's called 'where') is to be = 0. Since this method is used to perform operations of insertString() and remove() in RI, negative positions are invalid. I believe they put no checks here because validation of parameters is performed in those methods which call replace(). Another point is that replace() in never used in Harmony implementation - it's called from tests only. Regards, Alexey. Thanks, Stepan. 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 -- 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] -- Alexey A. Ivanov Intel Middleware Product Division
RE: [classlib][swing][test] Excluded tests clean up
Thank you, Alexey. Some of them were successfully applied. Some are in indeterminate state because several tests fail on Mark's machine. I can't reproduce any of those failures on my machines :(. Therefore I can't figure out where the problem is and fix them. You can run tests which were un-excluded and report your results. Thank you in advance, Alexey. P.S. See also this message: http://thread.gmane.org/gmane.comp.java.harmony.devel/16579/focus=16835 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 9:40 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing][test] Excluded tests clean up Alexey, I'll take a look. SY, Alexey 2006/10/20, Ivanov, Alexey A [EMAIL PROTECTED]: Hello, I am working to clean up the excluded list and to make all the tests run-able without failures. I've created several JIRA issues. https://issues.apache.org/jira/browse/HARMONY-1825 https://issues.apache.org/jira/browse/HARMONY-1866 https://issues.apache.org/jira/browse/HARMONY-1910 And https://issues.apache.org/jira/browse/HARMONY-1892 to make all Windows users happier. :) Can anyone look at them and apply patches to make creation of patches to build.xml easier and less reject-prone? Thank you in advance, Alexey. -- Alexey A. Ivanov 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] -- Alexey A. Petrenko Intel Middleware Products Division
RE: [testing][support] Where to place xxxTestCase support classes
Thank you, Nathan, for your reply. I believe these classes can be put to a support package in the module rather than java.* and javax.* correspondingly. I need to try it. At the moment they are along with the tests. But we can't help use javax.swing.* for swing tests since most of them are designed to be run on bootclasspath. See also the related message: http://thread.gmane.org/gmane.comp.java.harmony.devel/16591/focus=16591 Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 3:15 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing][support] Where to place xxxTestCase support classes If the support classes aren't used outside of one module, then I would put them in that module. Like the beans example mentioned. As for the package name, I would prefer to avoid the java.* and javax.* package names whenever possible, so we can avoid classpath issues. -Nathan On 10/31/06, Alexei Zakharov [EMAIL PROTECTED] wrote: FYI in beans we have the following folders for this purpose: src/test/support/java/org/apache/harmony/beans/tests/support src/test/support/java/org/apache/harmony/beans/tests/support/mock Thanks, 2006/10/31, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, Both AWT and Swing modules have testing support classes. Some of them are extensions of junit.framework.TestCase which provide some utility methods for tests. To mention several: AWTTestCase, ShapeTestCase, BasicSwingTestCase, SwingTestCase. There are test cases which extend these classes. There are also several classes which provide special mock objects, fields, for example ViewTestHelpers, DefStyledDoc_Helpers. The question about support classes was discussed [1] but no decision was taken. The bad thing about these classes is that: * some are stored along with tests utilizing these classes (modules/awt/src/test/api/java/common/java/awt/), * some are stored in support folder (support/src/test/java/javax/swing/). I think we should decide where such classes are to be stored. And move them appropriately. Comments, opinions? Regards, Alexey. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/9487/focus=9561 P.S. Mikhail, did you add the text from the message above into any doc? -- Alexei Zakharov, Intel Enterprise Solutions Software Division
RE: [testing][support] Where to place xxxTestCase support classes
-Original Message- From: Denis Kishenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 1:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [testing][support] Where to place xxxTestCase support classes Alexey thanks for question, because I'm intereseted in this too As I understand from your discession, for example suport class modules\awt\src\test\api\java\common\java\awt\geom\ShapeTestCase.java should be moved to modules\awt\src\test\support\java\org\apache\harmony\awt\geom\tests\sup port \ShapeTestCase.java Am I right? Yep. Regards, Alexey. 2006/11/1, Ivanov, Alexey A [EMAIL PROTECTED]: Thank you, Nathan, for your reply. I believe these classes can be put to a support package in the module rather than java.* and javax.* correspondingly. I need to try it. At the moment they are along with the tests. But we can't help use javax.swing.* for swing tests since most of them are designed to be run on bootclasspath. See also the related message: http://thread.gmane.org/gmane.comp.java.harmony.devel/16591/focus=16591 Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 3:15 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing][support] Where to place xxxTestCase support classes If the support classes aren't used outside of one module, then I would put them in that module. Like the beans example mentioned. As for the package name, I would prefer to avoid the java.* and javax.* package names whenever possible, so we can avoid classpath issues. -Nathan On 10/31/06, Alexei Zakharov [EMAIL PROTECTED] wrote: FYI in beans we have the following folders for this purpose: src/test/support/java/org/apache/harmony/beans/tests/support src/test/support/java/org/apache/harmony/beans/tests/support/mock Thanks, 2006/10/31, Ivanov, Alexey A [EMAIL PROTECTED]: Hi all, Both AWT and Swing modules have testing support classes. Some of them are extensions of junit.framework.TestCase which provide some utility methods for tests. To mention several: AWTTestCase, ShapeTestCase, BasicSwingTestCase, SwingTestCase. There are test cases which extend these classes. There are also several classes which provide special mock objects, fields, for example ViewTestHelpers, DefStyledDoc_Helpers. The question about support classes was discussed [1] but no decision was taken. The bad thing about these classes is that: * some are stored along with tests utilizing these classes (modules/awt/src/test/api/java/common/java/awt/), * some are stored in support folder (support/src/test/java/javax/swing/). I think we should decide where such classes are to be stored. And move them appropriately. Comments, opinions? Regards, Alexey. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/9487/focus=9561 P.S. Mikhail, did you add the text from the message above into any doc? -- Alexei Zakharov, Intel Enterprise Solutions Software Division -- Denis M. Kishenko Intel Middleware Products Division -- Alexey A. Ivanov Intel Middleware Product Division
[testing][support] Where to place xxxTestCase support classes
Hi all, Both AWT and Swing modules have testing support classes. Some of them are extensions of junit.framework.TestCase which provide some utility methods for tests. To mention several: AWTTestCase, ShapeTestCase, BasicSwingTestCase, SwingTestCase. There are test cases which extend these classes. There are also several classes which provide special mock objects, fields, for example ViewTestHelpers, DefStyledDoc_Helpers. The question about support classes was discussed [1] but no decision was taken. The bad thing about these classes is that: * some are stored along with tests utilizing these classes (modules/awt/src/test/api/java/common/java/awt/), * some are stored in support folder (support/src/test/java/javax/swing/). I think we should decide where such classes are to be stored. And move them appropriately. Comments, opinions? Regards, Alexey. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/9487/focus=9561 P.S. Mikhail, did you add the text from the message above into any doc? -- Alexey A. Ivanov Intel Middleware Product Division
RE: [jira] No change notification from JIRA
Geir, Thank you for your quick answer. Regards -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 5:02 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] No change notification from JIRA infrastructure still isn't fully back up yet. Minotaur, the main user machine, didn't make the journey. Ivanov, Alexey A wrote: Hi to everybody, Does anybody know why JIRA stopped sending notifications of a change to issue reporter? Some time ago it didn't work as well. And before the infrastructure move on Monday, it worked fine. Now it doesn't again. Notifications for issues watched are sent as before. Thank you in advance, -- Alexey A. Ivanov Intel Middleware Product Division
RE: [classlib][swing][test] Excluded tests clean up
-Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 12:53 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing][test] Excluded tests clean up On 20 October 2006 at 11:31, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hello, I am working to clean up the excluded list and to make all the tests run-able without failures. I've created several JIRA issues. https://issues.apache.org/jira/browse/HARMONY-1825 https://issues.apache.org/jira/browse/HARMONY-1866 https://issues.apache.org/jira/browse/HARMONY-1910 Thanks for looking at these excluded tests. I've taken a look and added some comments about the unexcluded tests that still fail for me on linux. Thank you, Mark, for trying this out. Yet I can reproduce none of the failures you mentioned (both on Linux and on Windows): javax.swing.text.PlainViewTest javax.swing.JFormattedTextField_CommitActionRTest javax.swing.JTextField_NotifyActionRTest Can anyone try to run these tests and say whether they pass or not? Thank you in advance, Alexey. And https://issues.apache.org/jira/browse/HARMONY-1892 to make all Windows users happier. :) I'll leave that to a committer who can reproduce the problem. Can anyone look at them and apply patches to make creation of patches to build.xml easier and less reject-prone? Don't worry too much about the rejects on removal of exclude lines from build.xml it's really pretty trivial to see what is intend and manually remove the required lines. (Feel free to worry about more complicated rejects in code though - committers like an easy life. ;-) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division
RE: [vote] Graduate Apache Harmony podling from the Incubator
+1 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 11:30 PM To: harmony-dev@incubator.apache.org Subject: [vote] Graduate Apache Harmony podling from the Incubator We're trying something a little different. I think Roy Fielding one said something along the lines of when a community gets organized enough to vote itself out of the Incubator, it's appropriate. So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it hosted by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
-Original Message- From: Alex Blewitt [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 3:32 AM To: harmony-dev@incubator.apache.org Subject: Re: RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful On 21/10/06, Fedotov, Alexei A [EMAIL PROTECTED] wrote: Alex, I see and accept your point. I believe that partial commits are a must - we should be a community. My point is simple - the code under active development shouldn't be a subject of beautification - it just should be safe for other Harmony modules. The first goal is to make it work. Completely agree. Code which is fluctuating under development shouldn't cause a concern that it's generating warnings for this kind of thing. Once the code matures, and is fully implemented and tested, *then* that's the time to start the beautification process :-) I agree with this too. No beautification should be performed on code which is actively being developed. I think everybody understands it clearly. But once the code is quite stable and only bug fixes are applied to it, I see no harm from deleting unused local variables and imports. Removing unreferenced private fields and methods can be dangerous. Nevertheless I'd vote for removing ones as well. It makes code more concise leaving no legacy. Regards, -- Alexey A. Ivanov Intel Middleware Product Division
[classlib][swing][test] Excluded tests clean up
Hello, I am working to clean up the excluded list and to make all the tests run-able without failures. I've created several JIRA issues. https://issues.apache.org/jira/browse/HARMONY-1825 https://issues.apache.org/jira/browse/HARMONY-1866 https://issues.apache.org/jira/browse/HARMONY-1910 And https://issues.apache.org/jira/browse/HARMONY-1892 to make all Windows users happier. :) Can anyone look at them and apply patches to make creation of patches to build.xml easier and less reject-prone? Thank you in advance, Alexey. -- Alexey A. Ivanov 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]
[classlib][swing][test] HTML tests
Hi everyone, I am starting a new thread to answer the question asked at http://thread.gmane.org/gmane.comp.java.harmony.devel/8056/focus=16282 HTML tests are not currently run when doing ant test. The reason is they are in 'java.injected' source folder. Another point is that there's still no HTML parser in Harmony, and majority of HTML tests will fail. On the other hand, tests can pretend they pass. The current guidelines [1] say the tests which are designed to be run from bootclasspath are to be in 'java.injected' folder. Most of Swing tests are designed this way, however they are located 'java' folder but run on the bootclasspath. Therefore we have two options to resolve the issue: 1. Move all HTML tests to 'java' folder where other Swing tests are located. 2. Move all other Swing tests to 'java.injected' folder. Of course there are tests that can be run successfully from classpath, and there are a few implementation-specific tests. Shall I try to sort them all out? Thank you in advance, Alexey. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.h tml -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Coverage (was Re: 37% of total test execution time is spent in a single test)
Gabriel, See another thread for the answer: http://thread.gmane.org/gmane.comp.java.harmony.devel/16591/focus=16591 Thanks for noticing that. Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Gabriel Miretti [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 5:28 PM To: harmony-dev@incubator.apache.org Subject: Re: Coverage (was Re: 37% of total test execution time is spent in a single test) Vladimir Do you know why javax.swing.text.html tests weren't computed by the coverage tool if they are present in the SVN tree? Gabriel Miretti 2006/10/10, Vladimir Ivanov [EMAIL PROTECTED]: On 10/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: - 'cc' - for cruise control script (and move current stuff to this dir); - 'coverage' - for coverage scripts (It will nice if somebody also placed here data from issue 564); - 'japi' - for script to run 'japi'-tool. Agreed on all three. It will fine if somebody do it :). We have updated version of CC ( HARMONY-995 http://issues.apache.org/jira/browse/HARMONY-995) and coverage scripts (HARMONY-564 http://issues.apache.org/jira/browse/HARMONY-564 ). I hope we will have a japi script soon. Now I'm going to: - improve notification for CC to include txt files (output of cunit and smoke tests for DRLVM); - add imageio/print/applet modules to coverage script. I hope, it will be small updated to 'buildtest' module instead of reattach to jira a whole scripts again. thanks, Vladimir Do we have a japi script? geir Seems, that directory 'tests' also should be created in this module to place non-unit tests when we will have one. thanks, Vladimir - 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] Non-bug difference HARMONY-1745?
-Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 9:45 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Non-bug difference HARMONY-1745? On 10/13/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hello, Can HARMONY-1745 be treated as non-bug difference? In short, in Harmony implementation method j.s.t.CompositeView.getView(int n) throws ArrayIndexOutOfBoundsException unless the parameter n is in the range [0, getViewCount() - 1]. Yet the RI throws the same exception in some cases, and it doesn't throw any exception and silently returns null in other cases where n is outside the range mentioned above. It seems the RI always accepts getViewCount() as valid parameter value. Shall we bother to fix it or can we leave the code as is? IMHO, it's a bug of RI. We could leave the code as it and change the components of Harmony-1745 to Non-bug differences from RI. Great! Can any of the committers change the component with which the issue [1] is associated? Thank you in advance, Alexey. [1] https://issues.apache.org/jira/browse/HARMONY-1745 Best regards, Richard. Thank you in advance for your comments, Alexey. -- Alexey A. Ivanov 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] -- 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] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][swing] Non-bug difference HARMONY-1745?
Thank you, Tim. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 1:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Non-bug difference HARMONY-1745? Ivanov, Alexey A wrote: Can any of the committers change the component with which the issue [1] is associated? Done -- 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] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Richard, Thank you for your comments. See mine inline. -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 11:35 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription On 10/17/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Richard, I've filed JIRA issue [1] for this problem. To my mind, we should just remove these locale dependent assertions. On the other hand there will be only a few tests left after then. Any other suggestions? If the behavior is depended on the (default) locale setting of java, we could do like this: Locale defaultLocale = Locale.getDefault(); Locale.setDefault(Locale.US); test.. Locale.setDefault(defaultLocale); Yep, but... But it seems that the behavior is depended on the locale setting of OS, this solution does not work. ;-) You are right. We need to change the OS locale here. As far as I know, on Win the locale can be changed for a single thread. I don't know about Linux. I agree we remove the locale dependent assertions temporarily. On the other hand, these assertions merely check that file corresponds to File, and folder corresponds to Folder or File Folder. We can check that the return value is not null and is not empty string, at least temporarily. Later we can implement locale switching, if we want to. What do you think? Regards, Alexey. Best regards, Richard Regards, Alexey. P.S. See also related issue [2]: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:. [1] https://issues.apache.org/jira/browse/HARMONY-1893 [2] https://issues.apache.org/jira/browse/HARMONY-1892 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- 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] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:
-Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 1:21 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A: On 10/17/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hello everyone, When running tests on Windows, FileSystemViewTest.testGetSystemDisplayName() pops up a dialog prompting to insert disk into drive A:. This dialog prevents normal running of other tests. Is this still a problem? I cannot reproduce it on my WinXP. Do I miss anything? Yes, it is. I can't explain why but sometimes it appears, and sometimes it doesn't. Alexey. Richard IMO, the problem assertion could be deleted without loss of coverage. Any other comments/opinions? See the JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1892 Regards, Alexey. P.S. The problem code is at lines 85-86 in FileSystemViewTest.java: file = File.listRoots()[0]; assertNotSame(file.getName(), view.getSystemDisplayName(file)); -- Alexey A. Ivanov 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] -- 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] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:
-Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 4:41 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A: 2006/10/17, Ivanov, Alexey A [EMAIL PROTECTED]: Hello everyone, When running tests on Windows, FileSystemViewTest.testGetSystemDisplayName() pops up a dialog prompting to insert disk into drive A:. This dialog prevents normal running of other tests. LOL IMO, the problem assertion could be deleted without loss of coverage. Any other comments/opinions? See the JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1892 Regards, Alexey. P.S. The problem code is at lines 85-86 in FileSystemViewTest.java: file = File.listRoots()[0]; assertNotSame(file.getName(), view.getSystemDisplayName(file)); The assertion doesn't look foolproof anyway. Accordingly to spec getSystemDisplayName() should return *some* name, max what we may assert that it is not null and not empty. It's supposed to do what you pointed out. Actually here it merely asserts file.getName() != view.getSystemDisplayName(file), which is likely to be true even if file.getName().equals(view.getSystemDisplayName(file)). Most likely the author wanted the following assertion: assertFalse(file.getName().equals(view.getSystemDisplayName(file))) file.getName() returns both on Windows and Linux. And view.getSystemDisplayName(file) returns 3.5 Floppy (A:) on Windows and / on Linux. Regards, Alexey. -- Alexey A. Ivanov 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. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:
I've attached the patch to resolve the issue to https://issues.apache.org/jira/browse/HARMONY-1892 Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 1:27 PM To: harmony-dev@incubator.apache.org Subject: RE: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A: -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 1:21 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A: On 10/17/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hello everyone, When running tests on Windows, FileSystemViewTest.testGetSystemDisplayName() pops up a dialog prompting to insert disk into drive A:. This dialog prevents normal running of other tests. Is this still a problem? I cannot reproduce it on my WinXP. Do I miss anything? Yes, it is. I can't explain why but sometimes it appears, and sometimes it doesn't. Alexey. Richard IMO, the problem assertion could be deleted without loss of coverage. Any other comments/opinions? See the JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1892 Regards, Alexey. P.S. The problem code is at lines 85-86 in FileSystemViewTest.java: file = File.listRoots()[0]; assertNotSame(file.getName(), view.getSystemDisplayName(file)); -- Alexey A. Ivanov 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] -- 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] -- Alexey A. Ivanov 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][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Richard, I've attached a patch to resolve the issue [1] where I modified locale-dependent string comparisons with assertion the string returned is not empty. Please try it. Regards, Alexey. [1] https://issues.apache.org/jira/browse/HARMONY-1893 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey Varlamov [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 2:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription [snip] I agree we remove the locale dependent assertions temporarily. On the other hand, these assertions merely check that file corresponds to File, and folder corresponds to Folder or File Folder. We can check that the return value is not null and is not empty string, at least temporarily. Yes, just perform this check more carefully. Later we can implement locale switching, if we want to. If we will want it ever. What do you think? Regards, Alexey. Best regards, Richard Regards, Alexey. P.S. See also related issue [2]: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:. [1] https://issues.apache.org/jira/browse/HARMONY-1893 [2] https://issues.apache.org/jira/browse/HARMONY-1892 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- 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: 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] -- 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] -- Alexey A. Ivanov 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]
RE: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations to all! -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 7:59 AM To: harmony-dev@incubator.apache.org Subject: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov 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] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Richard, I've filed JIRA issue [1] for this problem. To my mind, we should just remove these locale dependent assertions. On the other hand there will be only a few tests left after then. Any other suggestions? Regards, Alexey. P.S. See also related issue [2]: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:. [1] https://issues.apache.org/jira/browse/HARMONY-1893 [2] https://issues.apache.org/jira/browse/HARMONY-1892 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- 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]
[classlib][swing] test hangs: j.s.filechooser.FileSystemViewTest prompts to insert disk into drive A:
Hello everyone, When running tests on Windows, FileSystemViewTest.testGetSystemDisplayName() pops up a dialog prompting to insert disk into drive A:. This dialog prevents normal running of other tests. IMO, the problem assertion could be deleted without loss of coverage. Any other comments/opinions? See the JIRA issue: https://issues.apache.org/jira/browse/HARMONY-1892 Regards, Alexey. P.S. The problem code is at lines 85-86 in FileSystemViewTest.java: file = File.listRoots()[0]; assertNotSame(file.getName(), view.getSystemDisplayName(file)); -- Alexey A. Ivanov 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]
[classlib][swing] Non-bug difference HARMONY-1745?
Hello, Can HARMONY-1745 be treated as non-bug difference? In short, in Harmony implementation method j.s.t.CompositeView.getView(int n) throws ArrayIndexOutOfBoundsException unless the parameter n is in the range [0, getViewCount() - 1]. Yet the RI throws the same exception in some cases, and it doesn't throw any exception and silently returns null in other cases where n is outside the range mentioned above. It seems the RI always accepts getViewCount() as valid parameter value. Shall we bother to fix it or can we leave the code as is? Thank you in advance for your comments, Alexey. -- Alexey A. Ivanov 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]
[jira] Problem attaching patch
Hi to everybody, I am trying to attach patch with fix to HARMONY-1797 and I get the following error message from JIRA: Errors * Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1797 Could anyone please check that everything is OK there? Thank you in advance, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Problem attaching patch
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? Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Sidelnikov, Nikolay A [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 3:12 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Problem attaching patch My unlucky patch is the fix to HARMONY-1774 and 1775 issues. Nikolay A. Sidelnikov, SSG/MRTD/DRL/DRL JIT software engineer, Intel Corporation, Novosibirsk e-mail: [EMAIL PROTECTED] phone: +7 383 3340950 ext. 2173 -Original Message- From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 6:04 PM To: harmony-dev@incubator.apache.org Subject: RE: [jira] Problem attaching patch Forgot to say that in my case I tried to attach a patch with fix to HARMONY-1730 and I got the same error message from JIRA as Alexey did. Cheers, Sveta -Original Message- From: Elena Semukhina [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 1:53 PM To: harmony-dev@incubator.apache.org Subject: Re: [jira] Problem attaching patch I face the same problem. On 10/12/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hi to everybody, I am trying to attach patch with fix to HARMONY-1797 and I get the following error message from JIRA: Errors * Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/HARMONY/HARMONY-1797 Could anyone please check that everything is OK there? Thank you in advance, Alexey. -- Alexey A. Ivanov 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] -- Thanks, Elena - 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] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription
Hello, Richard, I'll take a look at it. Thanks, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: [classlib][swing] test failure: javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription Hello, The test fails on Windows XP when the locale-setting is zh_CN. It's because that view.getSystemTypeDescription(file) returns Chinese words 文件 instead of File. Could any one help to verify this issue? Thanks a lot. -- 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: [general] Marking JIRA issues before creation of patches.
-Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 12:38 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] Marking JIRA issues before creation of patches. Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. +1 Regards, Alexey. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: 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] - 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] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Created: (HARMONY-1395) Code for reading and writing binary DTDs using ASN.1 encoding
-Original Message-
From: Miguel Montes [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 07, 2006 4:26 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-1395) Code for reading and
writing
binary DTDs using ASN.1 encoding
Hi Mikhail:
The attach button in the JIRA form doesn't have the checkbox to grant
the
license. Now I notice the button is there when you try to attach files
to
an
already created issue, so i understand I have to create the issue
first,
and
attach the files later.
What should i do now to grant the license? Re-attach the files granting
the
license? Sorry if this was explained before, but i didn't read IT
Miguel,
Yes, just re-attach the files granting the license.
It was discussed several weeks ago [1]. There were also several other
threads about this issue.
Regards,
Alexey.
[1]
http://thread.gmane.org/gmane.comp.java.harmony.devel/11975/focus=11991
Miguel
On 9/7/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Miguel
Thanks for your patches! Could you please grant ASF license to them?
Thanks,
Mikhail
2006/9/7, Miguel Montes (JIRA) [EMAIL PROTECTED]:
Code for reading and writing binary DTDs using ASN.1 encoding
-
Key: HARMONY-1395
URL:
http://issues.apache.org/jira/browse/HARMONY-1395
Project: Harmony
Issue Type: Improvement
Components: Contributions
Reporter: Miguel Montes
Attachments: ASN1_01.patch,
ASN1_ITC-Contribution_20060905.zip
The class javax.swing.text.html.parser.DTD has a method read() for
loading a binary DTD. The format of this binary file is not
specified, so
the current implementation uses serialization. This approach has
several
problems, so it was suggested in harmony-dev the use of ASN.1 to
encode
the DTD information.
Attached is a zip file with a set of classes for encoding and
decoding
a
DTD, using the ASN.1 framework already in use in javax.crypto; and
two
bdtds, one for HTML 3.2 and one for HTML 4.01. Also attached is a
patch
for DTD.java and DTDUtilities.java.
The proposed format is:
BDTD ::= SEQUENCE {
name UTF8String,
entity SET OF HTMLEntity,
element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
name UTF8String,
value INTEGER,
general [0] IMPLICIT BOOLEAN DEFAULT FALSE,
parameter [1] IMPLICIT BOOLEAN DEFAULT FALSE,
data UTF8String
}
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions [0] IMPLICIT SET OF INTEGER OPTIONAL,
inclusions [1] IMPLICIT SET OF INTEGER OPTIONAL,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
type INTEGER,
index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
name UTF8String,
type INTEGER,
modifier INTEGER,
defaultValue UTF8String OPTIONAL,
possibleValues SET OF UTF8String OPTIONAL
}
--
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]
--
Miguel Montes
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][TestNG] groups of Harmony test
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Monday, September 04, 2006 10:56 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][TestNG] groups of Harmony test
Mikhail Loenko wrote:
Hi Vladimir
Could you please decribe for what purpose it will be used?
I mean why one might have to either exclude or run only regression
tests?
If running all tests takes up much time, running all regression test
(for one particular version) may be a convenient way to verify the
correctness of bug-fixing.
I can be used for informational purposes as well. If the test fails, you
need simply re-open the associated bug provided the bug number can be
easily found.
Regards,
Alexey.
Best regards,
Richard.
Thanks,
Mikhail
2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Yes, I do. While tests can have more than one group it will enough.
thanks, Vladimir
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the
related
threads which posted by George, Vladimir Ivanov and Alexei
Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the
following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO,
most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for
one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive,
that
is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
because
of bugs of tests or implementation. We need to fix the bugs
of
tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail
on one
specific platform. A test may be in more than one of the
groups. e.g
.,
@Test(groups={state.broken.linux.IA32,
os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient
way
to indicate that a test is platform-specific. e.g., If we
support 10
platforms, and one test are designed for 9 platforms except
for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the
Java
Specification
*type.impl* - groups of tests which are tests for
Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
verification
of
the entire system. Maybe we'll put them into a separate
project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we
may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try
to
figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG
to add
a
new option -groups for its JUnitConverter which allow us to
specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your
comments
or suggestion. ;-)
--
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]
--
Richard Liang
China Software Development Lab, IBM
-
RE: [classlib][TestNG] groups of Harmony test
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Monday, September 04, 2006 6:18 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][TestNG] groups of Harmony test
On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Well, my question was for what particular reason? for example?
Tio verify correctness of bug-fixing IMHO all the unit,
intergration,
api, and
regression tests should be run
Running all tests are always good to verify our code quality. And I
think this is what we have been doing. But what will we do if it
takes
us 24 hours to run all Harmony tests? Anyway, running regression
tests
could provide some confidence to our bug-fixing. We may consider it
as
another option. :-)
I prefer to run all tests in one module instead. :) Although it can not
guarentee all tests would pass, it's less likey to break build system
frequently. If the fix causes other module fails, it shows the lack of
tests in its module. And we should add the corresponding test in the
module.
Currently, Harmony regression test is a test for certain Harmony jira
issue.
So IMHO, running all regression tests for certain issue doesn't make
sense.
But whether using annotation to mark regression test is another story.
At
least, it doesn't have any disadvantages compared with comment way,
does it?
Agree. We may introduce a special annotation for this purpose.
Regards,
Alexey.
Best regards,
Richard
Thanks,
Mikhail
2006/9/4, Richard Liang [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Hi Vladimir
Could you please decribe for what purpose it will be used?
I mean why one might have to either exclude or run only
regression
tests?
If running all tests takes up much time, running all regression
test
(for one particular version) may be a convenient way to verify
the
correctness of bug-fixing.
Best regards,
Richard.
Thanks,
Mikhail
2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Yes, I do. While tests can have more than one group it will
enough.
thanks, Vladimir
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED]
wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the
related
threads which posted by George, Vladimir Ivanov and
Alexei
Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the
following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform.
IMHO,
most of
our tests should be in this group.
*os.platform id* - group of tests which are designed
for
one
specific platform. A test may be in more than one of
the
groups. e.g
.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually
exclusive,
that
is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform
id
*state.broken* - group of tests which fail on every
platform,
because
of bugs of tests or implementation. We need to fix the
bugs
of
tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which
only
fail
on one
specific platform. A test may be in more than one of
the
groups. e.g
.,
@Test(groups={state.broken.linux.IA32,
os.broken.linux.IA64})
**state.broken.platform id group may be used as a
convenient
way
to indicate that a test is platform-specific. e.g., If
we
support 10
platforms, and one test are designed for 9 platforms
except
for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in
the
Java
Specification
*type.impl* - groups of tests which are tests for
Harmony-specific
implementation
** type.api and type.impl are also mutually
exclusive.
4) [Test Level] level.unit, level.integration,
level.system,
level.stress, etc. (Levels of Test refer to the
increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
verification
of
the entire system. Maybe we'll put them
RE: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
Geir, Any way I have to check that we can ignore these chunks, just to be sure everything's in the way expected. So why not just remove them from the patch, and make life of a committer a little bit easier? Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 2:45 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing Please don't waste the time because I am not comfortable voting on one code contribution, and committing something else. If you just give me a list of all chunks that I can ignore, I'll be eternally grateful... geir On Aug 31, 2006, at 2:52 AM, Ivanov, Alexey A wrote: -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 7:04 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing Most (probably all) of the failures are already applied failures. So additional patch has no sense here. Alexey can just remove already applied chunks to not disturb the patcher... This is what I'm going to do. Regards, Alexey. 2006/8/30, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, but the correct way here is probably not a completely new patch, but one that can follow the original patch with fix-ups geir Ivanov, Alexey A wrote: Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. 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] -- 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: harmony-dev- [EMAIL PROTECTED] -- Alexey A. Ivanov 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
RE: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. 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]
RE: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
+1 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Ilya Okomin [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 12:10 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing +1 On 8/28/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/8/28, Vladimir Gorr [EMAIL PROTECTED]: I see these improvements don't contain very important thing allowing us to automatically build (or get) the gl library. Or is this another story? This is another story. Otherwise only the advanced people can look at these enhancements :-). Nevertheless +1 for me. Thanks, Vladimir. On 8/28/06, Alexey Petrenko [EMAIL PROTECTED] wrote: +1 2006/8/28, Geir Magnusson Jr [EMAIL PROTECTED]: +1 Geir Magnusson Jr 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: harmony-dev- [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: harmony-dev- [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- 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][TestNG] How to handle bootclasspath tests
-Original Message-
From: Mark Hindess [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 24, 2006 6:37 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][TestNG] How to handle bootclasspath tests
On 24 August 2006 at 13:58, Oliver Deakin
[EMAIL PROTECTED]
wrote:
Richard Liang wrote:
Hello All,
I'm investigating the possibilities of migrating Harmony tests from
JUnit/Directory layout to TestNG while reviewing all the related
thread in mailing list. And I will try to answer the open issues.
To
make things simple, I will post the issues one by one. ;-)
Question: How to handle bootclasspath tests?
IMHO, I'm not sure whether it is a good idea to use TestNG groups
to
differentiate the bootclasspath tests and classpath tests.
If we put bootclasspath and classpath tests in the same
directory,
and use TestNG groups to differentiate them. When we want to run
the
bootclasspath tests, we have to put all tests in bootclasspath
including the classpath tests. I don't think it's a good
approach.
And I cannot find any ways to compile the java sources from one
directory into several different directories (ANT or Eclipse). So I
suggest we put bootclasspath tests and classpath tests into
different
directories.
Agreed - this is a fairly simple separation, and there is good reason
to
do it.
My vote's for keeping bootclasspath and classpath tests physically
separate.
Yes, I think this is the best way to handle this distinction too.
+1
There are going to be more than enough groups. I thought about some
more earlier while trying the awt tests... we should identify which
tests require a display to run and which may be run headless.
It makes sense, so that we can exclude the tests which can't run without
a display, and still run those which don't need a display.
Regards,
Alexey.
Regards,
Mark.
But if we think putting all tests into bootclasspath is not a
problem, we may have a workaround: running bootclasspath and
classpath tests in separate tasks. I mean:1) Running bootclasspath
tests with all tests in bootclasspath 2) running all classpath
tests
with all tests in classpath
Please correct me if I'm wrong.
Here is sample of how to launch TestNG in ANT:
testng outputDir=${testng.report.dir}
sourcedir=${test.src.dir}
haltOnfailure=true
verbose=3
jvm=${HarmonyVM}/bin/java
bootclasspath
pathelement path=../bin/tests.boot /
/bootclasspath
classpath
pathelement path=../bin/tests /
/classpath
xmlfileset dir=. includes=suite.xml /
/testng
Thanks for reading this far. ;-)
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
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. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][TestNG] groups of Harmony test
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Friday, August 25, 2006 7:18 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][TestNG] groups of Harmony test
Hello All,
Now let's talk about the TestNG groups. I have read the related threads
which posted by George, Vladimir Ivanov and Alexei Zakharov. All of
them
are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our
tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific
platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests or
implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project. e.g.,
harmony/enhanced/SVT (System Verification Test).
5) [Environment] env.display, env.headless
To distinguish AWT and Swing tests which need a display to run, and
those which don't, as Mark proposed [1].
Regards,
Alexey.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200608.mb
ox/[EMAIL PROTECTED]
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of
{os.any,
type.api, level.unit}, and I have asked TestNG to add a new option
-groups for its JUnitConverter which allow us to specify the test
groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or
suggestion. ;-)
--
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]
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][TestNG] groups of Harmony test
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Monday, August 28, 2006 1:06 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][TestNG] groups of Harmony test
On 8/28/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Friday, August 25, 2006 7:18 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][TestNG] groups of Harmony test
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads
which posted by George, Vladimir Ivanov and Alexei Zakharov. All of
them
are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our
tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific
platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
because
of bugs of tests or implementation. We need to fix the bugs of tests
or
implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on
one
specific platform. A test may be in more than one of the groups.
e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient
way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification
of
the entire system. Maybe we'll put them into a separate project.
e.g.,
harmony/enhanced/SVT (System Verification Test).
5) [Environment] env.display, env.headless
To distinguish AWT and Swing tests which need a display to run, and
those which don't, as Mark proposed [1].
Will display option be passed manually as an argument to TestNG, or
detected automatically when running test?
I think it should be passed as an argument to TestNG.
Ant script can be setup to detect the state by default, with the ability
to override it from the command line.
Regards,
Alexey.
Regards,
Alexey.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200608.mb
ox/[EMAIL PROTECTED]
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of
{os.any,
type.api, level.unit}, and I have asked TestNG to add a new
option
-groups for its JUnitConverter which allow us to specify the test
groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your
comments
or
suggestion. ;-)
--
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]
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Updated: (HARMONY-1137) [classlib][swing/text] unit test AbstractDocument_DefaultDocumentEventTest fails
Hello, Can someone take a look and apply patches from HARMONY-1137 [1]? There's also a patch to un-exclude the tests which stop failing after applying the patch for HARMONY-1028 [2]. These tests are: javax.swing.text.AbstractDocument_DefaultDocumentEventTest, javax.swing.text.AbstractDocument_ElementEditTest, javax.swing.text.AbstractDocument_UpdateTest. Thanks, Alexey. [1] https://issues.apache.org/jira/browse/HARMONY-1137 [2] https://issues.apache.org/jira/browse/HARMONY-1028 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey A. Ivanov (JIRA) [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 4:59 PM To: Ivanov, Alexey A Subject: [jira] Updated: (HARMONY-1137) [classlib][swing/text] unit test AbstractDocument_DefaultDocumentEventTest fails [ http://issues.apache.org/jira/browse/HARMONY-1137?page=all ] Alexey A. Ivanov updated HARMONY-1137: -- Attachment: swing-build-unexclude-tests.patch After fixing the issue HARMONY-1028, the AbstractDocument_ tests excluded from run have stopped failing. After applying patches from this issue, no test case should fail in the AD_DefaultDocumentEventTest too. So swing-build-unexclude-tests.patch removes such tests from the exclude section. [classlib][swing/text] unit test AbstractDocument_DefaultDocumentEventTest fails - --- Key: HARMONY-1137 URL: http://issues.apache.org/jira/browse/HARMONY-1137 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey A. Ivanov Attachments: swing-build-unexclude-tests.patch, UndoRedoNames_Src.patch, UndoRedoNames_Tests.patch The following tests fail becuase of incorrect tests: testGetUndoPresentationName(javax.swing.text.AbstractDocument_DefaultDo cume ntEventTest) junit.framework.ComparisonFailure: expected:...addition but was:...Text added at javax.swing.text.AbstractDocument_DefaultDocumentEventTest.testGetUndoP rese ntationName(AbstractDocument_DefaultDocumentEventTest.java:241) testGetRedoPresentationName(javax.swing.text.AbstractDocument_DefaultDo cume ntEventTest) junit.framework.ComparisonFailure: expected:...addition but was:...Text added at javax.swing.text.AbstractDocument_DefaultDocumentEventTest.testGetRedoP rese ntationName(AbstractDocument_DefaultDocumentEventTest.java:247) testGetPresentationName(javax.swing.text.AbstractDocument_DefaultDocume ntEv entTest) junit.framework.ComparisonFailure: expected:addition but was:Text added at javax.swing.text.AbstractDocument_DefaultDocumentEventTest.testGetPrese ntat ionName(AbstractDocument_DefaultDocumentEventTest.java:253) The text to compare with should be fetched from the UIManager. -- 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][text] Bidi returns directional runs in visual order rather than in logical
Richard,
Thank you for the patch.
It works as expected. And j.s.t.AbstractDocument tests which depend on
j.t.Bidi stopped failing.
I have another issue with the Bidi implementation. It is its
incompatibility with the RI with regard to processing of new lines in
the text.
The Unicode Bidirectional Algorithm [1] states that text should be
divided into paragraphs, which are processed separately.
This is true for Harmony implementation of Bidi, and it's false for the
RI. That's why the third run has level 0 (on RI) rather than 2 (on
Harmony).
2: 0 [5, 7]
I prefer Harmony follows the standard. In this case, the code in
j.s.t.AbstractDocument, which is in charge for bidirectional text
support, may be somewhat optimized. Now AbstractDocument handles new
lines (paragraphs) explicitly, and we can drop this code since Bidi will
handle it.
Thanks,
Alexey.
[1] http://www.unicode.org/reports/tr9/
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 22, 2006 7:40 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][text] Bidi returns directional runs in visual
order
rather than in logical
Sorry for my late reply, Alexey.
I'm discussing this issue with ICU team, and have not drawn any
conclusion
till now.
Richard.
Ivanov, Alexey A wrote:
Hello Richard,
Have you taken a look at this issue?
Thanks,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 12:12 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][text] Bidi returns directional runs in
visual
order
rather than in logical
Hello Ivanov,
I will have a look at this issue, and will give my feedback later.
Thanks a lot.
Best regards,
Richard.
Ivanov, Alexey A wrote:
All,
I'd like to attract more attention to this problem because this
incompatibility makes many tests in javax.swing.text package fail.
The
implementation of jx.s.t.AbstractDocument depends on j.t.Bidi.
The root of the problem lies in ICU library. Here we have two
options:
1. Fix the Bidi implementation, to be more precise its counterpart
in
ICU;
2. Fix AbstractDocument to handle such illogical run order.
Can text guys comment on this issue?
I decided to cite the test case from the JIRA:
public class Test {
public static final String LTR = \u0061\u0062; // these are
ab
public static final String RTL = \u05DC\u05DD;
public static final String newLine = \n;
public static final String defText = LTR + newLine
+ RTL + LTR + RTL;
public static void main(String[] args) {
Bidi bi = new Bidi(defText,
Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Runs: );
final int count = bi.getRunCount();
for (int i = 0; i count; i++) {
System.out.println(i + : + bi.getRunLevel(i)
+ [ + bi.getRunStart(i)
+ , + bi.getRunLimit(i)
+ ]);
}
}
}
Thank you in advance.
--
Alexey A. Ivanov
Intel Middleware Product Division
P.S. Shall I add compatibility to the subject line?
-Original Message-
From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 3:27 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][text] Bidi returns directional runs in visual
order
rather than in logical
Hi all.
Harmony implementation of java.text.Bidi returns directional runs
(getRunStart(), getRunLimit(), getRunLevel()) in visual order if
paragraph reading order is Right-to-Left. I mean the first run is
at
the
end of character buffer, and the last is at the beginning. I'd
expect
directional runs are enumerated in the order of the characters in
the
buffer, i.e. the logical order.
I've created a JIRA issue for this:
https://issues.apache.org/jira/browse/HARMONY-1028
Another difference from the RI is that in Harmony the text is
divided
into paragraphs before directional analysis, which is not done in
the
RI
despite the Unicode Bidirectional Algorithm [1] requires it.
The output of the test case when run on Harmony:
0: 0 [0, 3]
1: 1 [7, 9]
2: 2 [5, 7]
3: 1 [3, 5]
However, I'd expect the following output:
0: 0 [0, 3]
1: 1 [3, 5]
2: 2 [5, 7]
3: 1 [7, 9]
The output of the test case when run on the RI:
0: 0 [0, 3]
1: 1 [3, 5]
2: 0 [5, 7]
3: 1 [7, 9]
Any thoughts?
[1] http://www.unicode.org/reports/tr9/
Regards,
--
Alexey A. Ivanov
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
RE: [doc] Intrim solution
-Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 23, 2006 4:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc] Intrim solution Morozova, Nadezhda wrote: Geir, Thanks for your effort in migrating docs to a more stable state inside the website. I've been examining your solution, and here are my comments: 1) Nice and quick way to import new docs into the website without converting them into XML for internal processing. Never thought of it :) 2) Source of resulting file is not optimal because: - Doctype declarations, metatags and head content are copied from the imported document into the middle of the resulting HTML code - body of the page HTML has a nested body of imported document Yep, but has there been any reported bad effects? 3) Stylesheet referenced in resulting document is applied to the whole page,including the left navigation menu. Yep. This last point can be workarounded easily by making minor changes in the referenced stylesheet (I could do this and send you a patch). However, I don't like this solution and would rather vote for a common CSS for the whole website. Yep! A major obstacle to having one CSS for the Harmony website is that there's no such CSS at the moment! LF of page content is set in the .vsl file that Anakia uses. I suggest that we move away from this by reducing .vsl to processing only and move out all presentation tags into a Harmony-wide CSS. This would help us: - reduce file size (and consequently i-net traffic) for Harmony website: you load only one file instead of loading the same styles for each page - reduce effort of integrating more docs into the website: each doc references the same stylesheet and is displayed in the same way - simplify doc structure: no nested body and meta elements; numerous font tags replaced with a hierarchical HTML tag and class structure - clarify website functioning mechanism: distinguish processing macros and presentation of resulting output If the community agrees, I could try and implement this solution. That would take a relatively significant amount of time as it would include: 1) Editing .vsl to remove presentation info and improving structure of resulting HTML code 2) Creating a .css and testing it to fit existing files and new ones 3) Going through all current XML files making up the website to make adjustments in body content per new CSS requirements (can be done by a script or auto-replacement but still) The last one I don't understand. Rarely is there any LF info in the XML - that's the point of this approach - that the document content - the XML - is independent of the rendering. All in all, this seems like a serious effort. Help most welcomed! Sounds good - I wouldn't try to bite it all off at once - I'd start with seeing what it takes to get a basic CSS applied in the .vsl and start looking at it from there. Lets try to do this incrementally, so if we decide not to do it, the investment is as small as possible. +1 I'd even prefer the resulting HTML could be validated as valid HTML 4.01 Strict. Regards, Alexey. (IOW, go for it!) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Vladimir, I am working to minimize hang-up of swing tests. Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Vladimir Ivanov [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 4:28 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test) The coverage information was updated on the wiki. Also, coverage for accessibility, awt, instrument and sound modules was added. I have a problem to calculate coverage for swing module (test run hang up) so issue 564 will be updated later. thanks, Vladimir On 6/20/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir Ivanov wrote: Classes from exclude list are now specified as green. I've update wiki (http://wiki.apache.org/harmony/Coverage_information) and coverage pages. Great, thank you, Vladimir! Thanks, Vladimir On 6/16/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir Vladimir Ivanov wrote: The current reports don't provide code source linking. Are you going to add it? There were no information for 'security' and 'auth' modules, but, I have updated the pages and now there is source code linking for all modules. One more issue to discuss: excluded classes present in the coverage table now with 0 coverage. May be it is more convenient do not have these classes in coverage tables at all? In this case one won't wonder why the class has 0 coverage - go to exclude list to look at the class and decide whether the class is really untested or just excluded from coverage, instead, all really uncovered classes will be shown with 0 coverage, if a class is missed in coverage table - it is in exclude list. +1 for current 0 coverage is not convenient. But if we can remove them from the report, how about just mark them in another way? say, mark the excluded class with different background colors? At least people don't need to care about two documents for one package. Thanks, Vladimir Now I have 2 questions/ issues to discuss: 1) preferable VM to calculate coverage (seems, the exclude list is a little bit different for j9 and drlvm) If the only difference is the exclude list then I'd suggest using VM with the shortest one. :-) 2) preferable sorting mode for results (by name, by blocks or by methods) IMHO, sorting by name looks more natural. Thanks, Stepan. Thanks, Vladimir SNIP -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [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] -- 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]
RE: [classlib][text] Bidi returns directional runs in visual order rather than in logical
Hello Richard,
Have you taken a look at this issue?
Thanks,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 12:12 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][text] Bidi returns directional runs in visual
order
rather than in logical
Hello Ivanov,
I will have a look at this issue, and will give my feedback later.
Thanks a lot.
Best regards,
Richard.
Ivanov, Alexey A wrote:
All,
I'd like to attract more attention to this problem because this
incompatibility makes many tests in javax.swing.text package fail.
The
implementation of jx.s.t.AbstractDocument depends on j.t.Bidi.
The root of the problem lies in ICU library. Here we have two
options:
1. Fix the Bidi implementation, to be more precise its counterpart in
ICU;
2. Fix AbstractDocument to handle such illogical run order.
Can text guys comment on this issue?
I decided to cite the test case from the JIRA:
public class Test {
public static final String LTR = \u0061\u0062; // these are
ab
public static final String RTL = \u05DC\u05DD;
public static final String newLine = \n;
public static final String defText = LTR + newLine
+ RTL + LTR + RTL;
public static void main(String[] args) {
Bidi bi = new Bidi(defText,
Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
System.out.println(Runs: );
final int count = bi.getRunCount();
for (int i = 0; i count; i++) {
System.out.println(i + : + bi.getRunLevel(i)
+ [ + bi.getRunStart(i)
+ , + bi.getRunLimit(i)
+ ]);
}
}
}
Thank you in advance.
--
Alexey A. Ivanov
Intel Middleware Product Division
P.S. Shall I add compatibility to the subject line?
-Original Message-
From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 3:27 PM
To: harmony-dev@incubator.apache.org
Subject: [classlib][text] Bidi returns directional runs in visual
order
rather than in logical
Hi all.
Harmony implementation of java.text.Bidi returns directional runs
(getRunStart(), getRunLimit(), getRunLevel()) in visual order if
paragraph reading order is Right-to-Left. I mean the first run is at
the
end of character buffer, and the last is at the beginning. I'd
expect
directional runs are enumerated in the order of the characters in
the
buffer, i.e. the logical order.
I've created a JIRA issue for this:
https://issues.apache.org/jira/browse/HARMONY-1028
Another difference from the RI is that in Harmony the text is
divided
into paragraphs before directional analysis, which is not done in
the
RI
despite the Unicode Bidirectional Algorithm [1] requires it.
The output of the test case when run on Harmony:
0: 0 [0, 3]
1: 1 [7, 9]
2: 2 [5, 7]
3: 1 [3, 5]
However, I'd expect the following output:
0: 0 [0, 3]
1: 1 [3, 5]
2: 2 [5, 7]
3: 1 [7, 9]
The output of the test case when run on the RI:
0: 0 [0, 3]
1: 1 [3, 5]
2: 0 [5, 7]
3: 1 [7, 9]
Any thoughts?
[1] http://www.unicode.org/reports/tr9/
Regards,
--
Alexey A. Ivanov
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]
--
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: [general] platform support
Rana, SetUnhandledExceptionFilter [1] is documented function which is available since Windows 95. It is part of the Structured Exception Handling. Windows XP introduced the Vectored Exception Handling which is an extension of SEH according to MSDN. Using this function and therefore SEH (but not VEH) mechanism requires you to guard each call with __try/__except as Gregory and Oleg pointed out. I'm not proficient in this kind of rather low-level Windows API though, so I might be wrong. Regards, Alexey. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b ase/setunhandledexceptionfilter.asp -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Rana Dasgupta [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 9:51 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] platform support Hi Mikhail, As far as I know, SetUnhandledExceptionFilter was introduced as a backdoor method in in Win2K SP4 to get around the problem that the SEH handlers are limited to the frame and not process wide. It does handle problems like NPE and AV, but as you point out, it works by hijacking the first and last chance debugger handlers. So, unlike VEH which are fully functional when debugging, these SetUnhandled...filters are not visible when debugging. I also believe that they execute in the context of the current thread, which means that they are not so good to handle stack corruption, SOE etc. which we are currently using VEH. Since one does not expect them to be used on the newer Windows boxes, the .Net framework overwrites them ...which means that any process that loads a Microsoft dll that has any Microsoft managed code in it ( and many do ), is at a risk that the SetUnhandled.. may or may not work. I think that SetUnhandled..was a great(probably only ) solution on the Win2K boxes, but VEH was put in place to solve some of its limitations. The bottom line is that one needs to experiment with this on several Windows boxes before we know how good or bad it is. I myself don't have a lot of experience with it. Thanks, Rana On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: **Using SetUnhandledExceptionFilter API call we can handle hardware NPE for Win2k too. The only problem is debbuging of applications with exception filter installed. AFAIK debugger will catch all of these events. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: [classlib][suncompat] created
I agree with Alex, we should *not* have this by default. Having it enabled by default will not give a hint something's wrong with the code. I believe no one will ever look in the sources if everything works just fine, and therefore no one will see the deprecation. At least, the new code won't reference these classes. However we'll provide a workaround to keep legacy applications running on Harmony in cases where the code can't be updated properly. When suncompat.jar is removed from the default distribution, people will be frustrated as well. Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alex Blewitt [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 12:06 PM To: harmony-dev@incubator.apache.org Subject: Re: RE: [classlib][suncompat] created I think the @deprecated is a good idea, but I strongly believe that we should *not* have this as a default. There's an easy workaround for the subset of applications that need it (e.g. enable it in the .properties file) whilst still preventing new code from being able to reference it. A simple FAQ should be enough to help people do this. Mind you, I seem to be in the minority on this view on this list :-) Alex. On 11/08/06, Nathan Beyer [EMAIL PROTECTED] wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][suncompat] created Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. geir Alex Blewitt wrote: Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Alex Blewitt wrote: OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] platform support
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 10:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] platform support (Your post had weird quoting, I've tried to fix it up in my reply) Rana Dasgupta 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. But there are degrees to which this is done too right? Somewhere along the spectrum from a start-up check that chooses between the winxp.dll and win2k.dll, to repeatedly choosing between any number of possible OS function calls. I also thought about the approach of using just separate DLLs with the same external API. At start-up the VM chooses one of them, and then forgets about platform-specific differences. This might be a rather good solution. Regards, Alexey. Oh, and I'm assuming that we are leaving the jitted code out of this. Of course the jit will know what platform it is targeting and can generate the code appropriately. So we are discussing the performance of the interpreter and the compiler itself. 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 share the same debug and kernel codebases )If this were not, we would be writing code for DOS only. Again, there may be cases where you may well choose the least common denominator solution because it is 'good enough' and the overhead elsewhere (testing etc.) is not worth the gain found here. Is vectored exception handling a slam dunk case for making the binary winxp only? I don't know -- what would happen if we didn't use it? Where is the example in the current code that makes ensuring it runs on W2K unpalatable? 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. Agree, so there is a balance to be struck. But I'm guessing from you descriptions that you favour this approach of multiple distributions for different OS releases. 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. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Created: (HARMONY-1116) [classlib][text] Bidi.getLength() result differs from RI when flag 61
Denis,
I think this Harmony behavior contradicts the spec:
getLength()
Return the length of text in the line.
So, it should return 16 despite the fact Bidi cannot interpret the flags
parameter correctly.
Have you tried this test with some RTL text?
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 3:43 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-1116) [classlib][text]
Bidi.getLength() result differs from RI when flag 61
Behavior of Harmony Bidi implementation differs from RI when Bidi is
created with flag parameter more then 61 According spec flag should be
a combination of predefined constants and 62 is invalid value.
I filed this issue as non-bug difference. Does anybody have objection?
2006/8/9, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][text] Bidi.getLength() result differs from RI when flag
61
---
Key: HARMONY-1116
URL:
http://issues.apache.org/jira/browse/HARMONY-1116
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI returns 0 for java.text.Bidi.getLength() if object was created via
Bidi(String paragraph, int flags) with flag61 like below:
Bidi bd = new Bidi(Java is the best, 62);
From the specification for Bidi constructor:
flags - a collection of flags that control the algorithm. The
algorithm
understands the flags DIRECTION_LEFT_TO_RIGHT,
DIRECTION_RIGHT_TO_LEFT,
DIRECTION_DEFAULT_LEFT_TO_RIGHT, and DIRECTION_DEFAULT_RIGHT_TO_LEFT.
Other values are reserved.
- Test --
import java.text.*;
public class bug9383 {
public static void main (String[] args) {
try {
Bidi bd = new Bidi(Java is the best, 62);
System.out.println(len=+bd.getLength());
} catch (Exception e) {
e.printStackTrace();
}
}
}
Output
-
--
RI
len=0
Harmony
len=16
--
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]
-
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-1116) [classlib][text] Bidi.getLength() result differs from RI when flag 61
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 5:39 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-1116) [classlib][text]
Bidi.getLength() result differs from RI when flag 61
Alexey,
Seems you are confused, Harmony returns 16 while RI returns 0, so
Harmony looks more correct.
Sorry, I should've been more attentive.
Regards,
Alexey.
For RTL text I have the same result.
2006/8/9, Ivanov, Alexey A [EMAIL PROTECTED]:
Denis,
I think this Harmony behavior contradicts the spec:
getLength()
Return the length of text in the line.
So, it should return 16 despite the fact Bidi cannot interpret the
flags
parameter correctly.
Have you tried this test with some RTL text?
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 3:43 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-1116) [classlib][text]
Bidi.getLength() result differs from RI when flag 61
Behavior of Harmony Bidi implementation differs from RI when Bidi is
created with flag parameter more then 61 According spec flag should
be
a combination of predefined constants and 62 is invalid value.
I filed this issue as non-bug difference. Does anybody have
objection?
2006/8/9, Denis Kishenko (JIRA) [EMAIL PROTECTED]:
[classlib][text] Bidi.getLength() result differs from RI when flag
61
---
Key: HARMONY-1116
URL:
http://issues.apache.org/jira/browse/HARMONY-1116
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Denis Kishenko
RI returns 0 for java.text.Bidi.getLength() if object was created
via
Bidi(String paragraph, int flags) with flag61 like below:
Bidi bd = new Bidi(Java is the best, 62);
From the specification for Bidi constructor:
flags - a collection of flags that control the algorithm. The
algorithm
understands the flags DIRECTION_LEFT_TO_RIGHT,
DIRECTION_RIGHT_TO_LEFT,
DIRECTION_DEFAULT_LEFT_TO_RIGHT, and
DIRECTION_DEFAULT_RIGHT_TO_LEFT.
Other values are reserved.
- Test --
import java.text.*;
public class bug9383 {
public static void main (String[] args) {
try {
Bidi bd = new Bidi(Java is the best, 62);
System.out.println(len=+bd.getLength());
} catch (Exception e) {
e.printStackTrace();
}
}
}
Output
-
--
RI
len=0
Harmony
len=16
--
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]
-
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]
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] new snapshots up early morning... is the win2k problem gone?
-Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 7:57 AM To: harmony-dev@incubator.apache.org Subject: Re: [general] new snapshots up early morning... is the win2k problem gone? Sorry for response so late, I must get to office for a win2k PC... Just tried it, the dgbhelp.dll error gone, but another one emerge: Cannot locate entry AddVectoredExceptionHandler at kernel32.dll (translate from Chinese so probably you'll get a slightly different message from this) AFAIK this feature (vectored exceptions) is available in Windows XP only. So it seems we need separate build for Win2K. Regards, Alexey. Env: win2k+sp4 .net framework 1.1 Windows PlatformSDK for Win2003 Geir Magnusson Jr wrote: can anyone test? 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] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [doc]proposal to improve and expand website
Nadezhda, -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 8:52 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [doc]proposal to improve and expand website Geir, Let me double-check what exactly you are proposing: I wonder if it's time we pull that stuff out of classlib/ and move to the site itself... Do you mean that we do the following: 1) Move the ASN1 and REGEXP docs out of docs/externals to xdocs/subcomponents/classlib by converting them to XML? What kind of XML do you mean? I just can't understand. 2) Move the html docs packaged with classlib donations (JNDI DNS, AWT, JAVA2D) to the same directory with conversion involved? I'd also recommend that we do the same for stable VM docs, like DevGuide and Getting Started. Now, the idea of integrating the docs into the site is just fine with me. However, the docs are very HTML-driven now, so you can't just cutpaste the HTML content with a couple of manual replacements and have a valid XML. There're over 15 styles that cannot map to standard XML tags. We'll What are standard XML tags? Or do you mean XHTML? Or am I just missing anything? Thank you in advance, Alexey. have to think of some content model and a DTD for those, probably. And still this will mean a lot of work. So I was wondering whether it is worth the effort? What will the major benefits of conversion be? Couldn't we just have the docs statically in HTML? At least for now? Best regards, Nadya Morozova, -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 6:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc]proposal to improve and expand website Morozova, Nadezhda wrote: I scanned the svn repository for classlib packages, and found a few more that had docs with them, namely the JNDI DNS Service Provider, the AWT framework and the Java2D implementation. I could move their docs to the externals/ directory as well. Now, this makes multiple docs in one folder, so I thought I'd group all classlib package docs into a classlib/ subfolder and all DRLVM docs into the drlvm/ subfolder. Shared files, like the style sheet, could be placed in those folders to avoid duplication. I wonder if it's time we pull that stuff out of classlib/ and move to the site itself... 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] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [doc]proposal to improve and expand website
Nadezhda, Thank you for your explanation. I've never looked at the internals. I'll look through it before making any suggestions. I hope I'll be able to help here. Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 12:14 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc]proposal to improve and expand website Alexey, If you look into the structure of the Harmony website, you'll see that permanent pages are originally written in XML, then built with Ant using Anakia for XMLHTML transformation into normal HTML. So, the source XML files are stored in xdocs/ and resulting HTML files in docs/. This is described in README.txt in harmony/standard/site/. So far, external materials on classlib packages were placed in HTML in docs/externals directory as a read-only copy from repository. Now, as I understood Geir, the number of useful materials that are relatively stable grows (5 classlib docs + several drlvm docs) and placing them all in externals/ does not seem reasonable any more. So, Geir has suggested, and Tim Ellison has agreed that we need to transfer the external HTML files to the XML format and make them part of site this way. The issue is the volume of this task. For a short HTML doc, you can transfer the content fairly easily: change h tags to section and subsection and leave p and ul tags as they are interpreted normally. However, for longer docs with a variety of CSS styles applied and various content unit used, e.g. notes, definition lists, formatted tables, and so forth. For such formatting-rich documents, the HTML XML transfer does not appear so linear. As I understand, this will take a significant amount of manual editing. Or am I missing something? Your suggestions on format transformations are most welcome :) Best regards, Nadya Morozova, -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 11:25 AM To: harmony-dev@incubator.apache.org Subject: RE: [doc]proposal to improve and expand website Nadezhda, -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 8:52 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [doc]proposal to improve and expand website Geir, Let me double-check what exactly you are proposing: I wonder if it's time we pull that stuff out of classlib/ and move to the site itself... Do you mean that we do the following: 1) Move the ASN1 and REGEXP docs out of docs/externals to xdocs/subcomponents/classlib by converting them to XML? What kind of XML do you mean? I just can't understand. 2) Move the html docs packaged with classlib donations (JNDI DNS, AWT, JAVA2D) to the same directory with conversion involved? I'd also recommend that we do the same for stable VM docs, like DevGuide and Getting Started. Now, the idea of integrating the docs into the site is just fine with me. However, the docs are very HTML-driven now, so you can't just cutpaste the HTML content with a couple of manual replacements and have a valid XML. There're over 15 styles that cannot map to standard XML tags. We'll What are standard XML tags? Or do you mean XHTML? Or am I just missing anything? Thank you in advance, Alexey. have to think of some content model and a DTD for those, probably. And still this will mean a lot of work. So I was wondering whether it is worth the effort? What will the major benefits of conversion be? Couldn't we just have the docs statically in HTML? At least for now? Best regards, Nadya Morozova, -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 6:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc]proposal to improve and expand website Morozova, Nadezhda wrote: I scanned the svn repository for classlib packages, and found a few more that had docs with them, namely the JNDI DNS Service Provider, the AWT framework and the Java2D implementation. I could move their docs to the externals/ directory as well. Now, this makes multiple docs in one folder, so I thought I'd group all classlib package docs into a classlib/ subfolder and all DRLVM docs into the drlvm/ subfolder. Shared files, like the style sheet, could be placed in those folders to avoid duplication. I wonder if it's time we pull that stuff out of classlib/ and move to the site itself... 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] -- Alexey A. Ivanov
RE: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Miguel,
Does it make sense using ASN.1 then, if it's complex and not pretty?
OTOH formal description is an advantage.
I believe we can write the data needed with just DataOutputStream
methods, but it might not be clear.
We can improve serialization so that it works fine and in
JVM-independent way by overriding readObject/writeObject methods in the
classes to be serialized. (The classes under consideration are from
html.parser package, I believe so.)
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Miguel Montes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 8:40 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][html] Should we try to be binary compatible
with
Sun's bdtd?
As I suggested earlier, I would use ASN.1. I don't like it, but there
are
several arguments for using it:
1) We can make a formal description of the format, so anyone can write
his
own encoder/decoder. Something like:
BDTD ::= SEQUENCE {
Entity SET OF HTMLEntity,
Element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
Name NameId,
Type HTMLEntityType,
Data OCTET STRING
}
NameId ::= OCTET STRING
2) We already have an ASN.1 encoder/decoder, developed by the people of
Intel Middleware Product Division (Stepan and others). It is used in
the
crypto framework, so it must be included in Harmony, anyway.
It's complex, and it's not pretty. I wouldn't suggest it if we didn't
already have the decoder available. But it is there, and we can use it.
On 8/2/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote:
Diego,
I tried to read this file using both J9 and DRLVM, and I didn't
manage.
Hence using serialization is not the best approach, and we need to
choose another archive format.
Serialization might fail because it contains some classes which
serialized form is not specified (Element, Entity etc.) and which
don't
contain serialVersionUID field.
We may use DataOutputStream methods to save the required information,
and directly use DataInputStream to read it. (However using
serialization looks simpler.)
Any ideas about the binary format?
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Diego Mercado [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 1:36 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][html] Should we try to be binary compatible
with
Sun's bdtd?
HARMONY-948 has a serialized dtd file called transitional401.bdtd.
When I try to read it by calling DTD.read(DataInputStream) I get a
java.io.EOFException. But, on the other hand, when I create a binary
DTD by calling DTDUtilities.create(String) I can get it with
succeed.
How can I read transitional401.bdtd file? I used the JRE Harmony
424571 release in GNU/Linux.
Thanks,
Diego Mercado
On 7/28/06, Miguel Montes [EMAIL PROTECTED] wrote:
On 7/28/06, Stepan Mishura [EMAIL PROTECTED] wrote:
On 7/28/06, Miguel Montes wrote:
So, it seems there is consensus on the following steps:
1) We ask Sun again about the bdtd specs
2) We do NOT reverse engineer the bdtd
3) We choose a format, and document it.
It also seems that serialization is not the proper way of
doing
3),
so
we
must select a format that doesn't depend on the implementation
of,
say,
Hashtable, and we remain compatible with future versions of
the
class
libraries.
What about using ASN.1? We already have a decoder, so it
shouldn't be
difficult
Yep, using ASN.1 for binary format seems logical. If we agree
on
this
I
can share my experience of working with ASN.1.
In fact, I was thinking in using your decoder, Stepan, so that's
great
news.
Thanks,
Stepan.
On 7/27/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote:
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 26, 2006 9:08 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][html] Should we try to be binary
compatible
with
Sun's bdtd?
SNIP
The method read(DataInputStream). It's poorly
documented,
but
it
reads a
DTD in an unspecified binary format. The default DTD is
stored
in
this
format in a file named html32.bdtd (or html401.bdtd, in
the
case
of
the
recent contribution).
This method seems to be undocumented at all until people
asked
for
it
[1].
As Alexey pointed out, there is no method to write a DTD,
so
maybe
nobody
uses the method read() anyway. But I see no point in
having
a
public
method
that nobody can use. So I think we can:
1) Ask Sun to release the specification (if there is one)
We should try this once more (The first attempt was made in
[1]).
or
2) Figure it out, and document it
or
3) Release our
RE: [doc]proposal to improve and expand website
Nadezhda, I've looked through the structure of site directory, and I think there should be no problem in converting the docs into XML whatever the formatting is. (I must say that I studied the XSL transformation rather than the Anakia one. But both of them should give the same result.) As far as I understand the hX tags are to be converted to section and subsection, all other tags may be left without any change. Also the header (meta, title) information needs converting. I think there should be a way to link in additional CSS style sheet to preserve the original formatting. And CSS style sheets might need adjusting because of the change in the resulting HTML document structure, but it shouldn't be too complex though. I can try to convert one of the docs. Shall I try? And there may be a way to automate the conversion using a script. Any other thoughts? Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 12:54 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc]proposal to improve and expand website Nadezhda, Thank you for your explanation. I've never looked at the internals. I'll look through it before making any suggestions. I hope I'll be able to help here. Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 12:14 PM To: harmony-dev@incubator.apache.org Subject: RE: [doc]proposal to improve and expand website Alexey, If you look into the structure of the Harmony website, you'll see that permanent pages are originally written in XML, then built with Ant using Anakia for XMLHTML transformation into normal HTML. So, the source XML files are stored in xdocs/ and resulting HTML files in docs/. This is described in README.txt in harmony/standard/site/. So far, external materials on classlib packages were placed in HTML in docs/externals directory as a read-only copy from repository. Now, as I understood Geir, the number of useful materials that are relatively stable grows (5 classlib docs + several drlvm docs) and placing them all in externals/ does not seem reasonable any more. So, Geir has suggested, and Tim Ellison has agreed that we need to transfer the external HTML files to the XML format and make them part of site this way. The issue is the volume of this task. For a short HTML doc, you can transfer the content fairly easily: change h tags to section and subsection and leave p and ul tags as they are interpreted normally. However, for longer docs with a variety of CSS styles applied and various content unit used, e.g. notes, definition lists, formatted tables, and so forth. For such formatting-rich documents, the HTML XML transfer does not appear so linear. As I understand, this will take a significant amount of manual editing. Or am I missing something? Your suggestions on format transformations are most welcome :) Best regards, Nadya Morozova, -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 11:25 AM To: harmony-dev@incubator.apache.org Subject: RE: [doc]proposal to improve and expand website Nadezhda, -Original Message- From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 8:52 PM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: RE: [doc]proposal to improve and expand website Geir, Let me double-check what exactly you are proposing: I wonder if it's time we pull that stuff out of classlib/ and move to the site itself... Do you mean that we do the following: 1) Move the ASN1 and REGEXP docs out of docs/externals to xdocs/subcomponents/classlib by converting them to XML? What kind of XML do you mean? I just can't understand. 2) Move the html docs packaged with classlib donations (JNDI DNS, AWT, JAVA2D) to the same directory with conversion involved? I'd also recommend that we do the same for stable VM docs, like DevGuide and Getting Started. Now, the idea of integrating the docs into the site is just fine with me. However, the docs are very HTML-driven now, so you can't just cutpaste the HTML content with a couple of manual replacements and have a valid XML. There're over 15 styles that cannot map to standard XML tags. We'll What are standard XML tags? Or do you mean XHTML? Or am I just missing anything? Thank you in advance, Alexey. have to think of some content model and a DTD for those, probably. And still this will mean a lot of work. So I was wondering whether it is worth the effort? What will the major benefits of conversion be? Couldn't we just have the docs statically in HTML? At least for now? Best regards, Nadya Morozova, -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 6:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc
RE: [jira] Updated: (HARMONY-649) [classlib][text]compatibility: unexpected ArrayIndexOutOfBoundsException for java.text.Bidi.getRunLimit(-1)
Hi all,
Does it make sense to follow the RI in this situation?
I'm asking this because one of the comments to this issue says we
shouldn't.
IMO we should.
Any other thoughts?
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Alexey A. Ivanov (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 12:06 PM
To: Ivanov, Alexey A
Subject: [jira] Updated: (HARMONY-649) [classlib][text]compatibility:
unexpected ArrayIndexOutOfBoundsException for
java.text.Bidi.getRunLimit(-1)
[ http://issues.apache.org/jira/browse/HARMONY-649?page=all ]
Alexey A. Ivanov updated HARMONY-649:
-
Attachment: Bidi.patch
The original Bidi patch contains the same code in three functions, and
so
this code should be moved into a separate function to eliminate
duplication.
This is what I've done.
This patch should be applied instead of the original one.
[classlib][text]compatibility: unexpected
ArrayIndexOutOfBoundsException
for java.text.Bidi.getRunLimit(-1)
-
--
Key: HARMONY-649
URL: http://issues.apache.org/jira/browse/HARMONY-649
Project: Harmony
Issue Type: Bug
Reporter: Vladimir Ivanov
Attachments: Bidi.patch, Bidi.patch, BidiTest.patch
The Harmony method java.text.Bidi.getRunLimit(-1) throws
ArrayIndexOutOfBoundsException while RI return valid value.
Note, the spec says nothing about exceptions in this case.
test.java ===
import java.text.*;
public class test {
public static void main (String[] args) {
Bidi bidi = new Bidi(text, Bidi.DIRECTION_LEFT_TO_RIGHT);
try {
System.out.println(getRunLimit(-1) = +
bidi.getRunLimit(-1)
+ \npassed!);
} catch (Exception e) {
e.printStackTrace();
System.out.println(failed);
}
}
}
==
C:\tmp\tmp17C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-
win-ia32,
Native Threads, GC strategy: parallel)
getRunLimit(-1) = 4
passed!
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -
showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors,
as app
licable.
java.lang.ArrayIndexOutOfBoundsException: Array index out of range:
-1
at java.text.Bidi.getRunLimit(Bidi.java:349)
at test.main(test.java:7)
failed
C:\tmp\tmp17
--
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: [jira] Updated: (HARMONY-649) [classlib][text]compatibility: unexpected ArrayIndexOutOfBoundsException for java.text.Bidi.getRunLimit(-1)
Having tested the issue more thoroughly, I must agree with Sergey it's
not a bug in our code. It seems that the RI performs no analysis where
text doesn't require it as in the case with text. It just constructs a
light-weight object, thus accepting any value to getRunLimit() and
similar methods.
If Bidi object is initialized with RTL-text only (e.g. \u0634\u0627),
there will be one directional run as with text. But in the latter case
getRunLimit() throws ArrayIndexOutOfBoundsException if its parameter is
not between 0 and getRunCount().
Thanks to Sergey for pointing it out.
So we need to close the issue without applying any patches.
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 12:34 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Updated: (HARMONY-649)
[classlib][text]compatibility:
unexpected ArrayIndexOutOfBoundsException for
java.text.Bidi.getRunLimit(-1)
I agree with Sergey that RI behaviour is strange in this case and
there is more logic in Harmony.
But... We still need to be compatible with RI. So I vote for fixing
this
bug.
SY, Alexey
2006/8/2, Ivanov, Alexey A [EMAIL PROTECTED]:
Hi all,
Does it make sense to follow the RI in this situation?
I'm asking this because one of the comments to this issue says we
shouldn't.
IMO we should.
Any other thoughts?
Regards,
--
Alexey A. Ivanov
Intel Middleware Product Division
-Original Message-
From: Alexey A. Ivanov (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 12:06 PM
To: Ivanov, Alexey A
Subject: [jira] Updated: (HARMONY-649)
[classlib][text]compatibility:
unexpected ArrayIndexOutOfBoundsException for
java.text.Bidi.getRunLimit(-1)
[ http://issues.apache.org/jira/browse/HARMONY-649?page=all ]
Alexey A. Ivanov updated HARMONY-649:
-
Attachment: Bidi.patch
The original Bidi patch contains the same code in three functions,
and
so
this code should be moved into a separate function to eliminate
duplication.
This is what I've done.
This patch should be applied instead of the original one.
[classlib][text]compatibility: unexpected
ArrayIndexOutOfBoundsException
for java.text.Bidi.getRunLimit(-1)
-
--
Key: HARMONY-649
URL:
http://issues.apache.org/jira/browse/HARMONY-649
Project: Harmony
Issue Type: Bug
Reporter: Vladimir Ivanov
Attachments: Bidi.patch, Bidi.patch, BidiTest.patch
The Harmony method java.text.Bidi.getRunLimit(-1) throws
ArrayIndexOutOfBoundsException while RI return valid value.
Note, the spec says nothing about exceptions in this case.
test.java ===
import java.text.*;
public class test {
public static void main (String[] args) {
Bidi bidi = new Bidi(text,
Bidi.DIRECTION_LEFT_TO_RIGHT);
try {
System.out.println(getRunLimit(-1) = +
bidi.getRunLimit(-1)
+ \npassed!);
} catch (Exception e) {
e.printStackTrace();
System.out.println(failed);
}
}
}
==
C:\tmp\tmp17C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion
test
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-
win-ia32,
Native Threads, GC strategy: parallel)
getRunLimit(-1) = 4
passed!
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -
showversion test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors,
as app
licable.
java.lang.ArrayIndexOutOfBoundsException: Array index out of
range:
-1
at java.text.Bidi.getRunLimit(Bidi.java:349)
at test.main(test.java:7)
failed
C:\tmp\tmp17
--
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]
--
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
RE: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Diego, I tried to read this file using both J9 and DRLVM, and I didn't manage. Hence using serialization is not the best approach, and we need to choose another archive format. Serialization might fail because it contains some classes which serialized form is not specified (Element, Entity etc.) and which don't contain serialVersionUID field. We may use DataOutputStream methods to save the required information, and directly use DataInputStream to read it. (However using serialization looks simpler.) Any ideas about the binary format? Regards, -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Diego Mercado [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 1:36 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? HARMONY-948 has a serialized dtd file called transitional401.bdtd. When I try to read it by calling DTD.read(DataInputStream) I get a java.io.EOFException. But, on the other hand, when I create a binary DTD by calling DTDUtilities.create(String) I can get it with succeed. How can I read transitional401.bdtd file? I used the JRE Harmony 424571 release in GNU/Linux. Thanks, Diego Mercado On 7/28/06, Miguel Montes [EMAIL PROTECTED] wrote: On 7/28/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 7/28/06, Miguel Montes wrote: So, it seems there is consensus on the following steps: 1) We ask Sun again about the bdtd specs 2) We do NOT reverse engineer the bdtd 3) We choose a format, and document it. It also seems that serialization is not the proper way of doing 3), so we must select a format that doesn't depend on the implementation of, say, Hashtable, and we remain compatible with future versions of the class libraries. What about using ASN.1? We already have a decoder, so it shouldn't be difficult Yep, using ASN.1 for binary format seems logical. If we agree on this I can share my experience of working with ASN.1. In fact, I was thinking in using your decoder, Stepan, so that's great news. Thanks, Stepan. On 7/27/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 9:08 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? SNIP The method read(DataInputStream). It's poorly documented, but it reads a DTD in an unspecified binary format. The default DTD is stored in this format in a file named html32.bdtd (or html401.bdtd, in the case of the recent contribution). This method seems to be undocumented at all until people asked for it [1]. As Alexey pointed out, there is no method to write a DTD, so maybe nobody uses the method read() anyway. But I see no point in having a public method that nobody can use. So I think we can: 1) Ask Sun to release the specification (if there is one) We should try this once more (The first attempt was made in [1]). or 2) Figure it out, and document it or 3) Release our own specification Maybe specification is not the right word here. I believe we _can_ document which format we use. So that anyone can prepare their own archive file with DTD, read it using jx.s.t.html.parser.DTD.read, pass it to parser. since the method is public and part of javax.swing, we need to implement it, but this looks like a mistake or an overlook (and there are no swing tests in the TCK anyway so we can do whatever we please). It is not the only place where a public method is present, but it has no use because of lack of documentation. I think it's safe to try #1 and #2 in parallel with different people. Geir can do #1 while you can do #2. /me loves to delegate ;-) (aka lazy ass mode) I would suggest against #3: specifications are something that we are not tasked to do (even to compensate lack of such), as it might deliver the wrong message. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4216248 Regards, -- Alexey A. Ivanov Intel Middleware Product Division -- 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] -- Miguel Montes - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
[classlib][text] Bidi returns directional runs in visual order rather than in logical
Hi all. Harmony implementation of java.text.Bidi returns directional runs (getRunStart(), getRunLimit(), getRunLevel()) in visual order if paragraph reading order is Right-to-Left. I mean the first run is at the end of character buffer, and the last is at the beginning. I'd expect directional runs are enumerated in the order of the characters in the buffer, i.e. the logical order. I've created a JIRA issue for this: https://issues.apache.org/jira/browse/HARMONY-1028 Another difference from the RI is that in Harmony the text is divided into paragraphs before directional analysis, which is not done in the RI despite the Unicode Bidirectional Algorithm [1] requires it. The output of the test case when run on Harmony: 0: 0 [0, 3] 1: 1 [7, 9] 2: 2 [5, 7] 3: 1 [3, 5] However, I'd expect the following output: 0: 0 [0, 3] 1: 1 [3, 5] 2: 2 [5, 7] 3: 1 [7, 9] The output of the test case when run on the RI: 0: 0 [0, 3] 1: 1 [3, 5] 2: 0 [5, 7] 3: 1 [7, 9] Any thoughts? [1] http://www.unicode.org/reports/tr9/ Regards, -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
-Original Message- From: Miguel Montes [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:58 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? So, it seems there is consensus on the following steps: 1) We ask Sun again about the bdtd specs 2) We do NOT reverse engineer the bdtd 3) We choose a format, and document it. Agree with that. Thanks for summarizing. It also seems that serialization is not the proper way of doing 3), so we must select a format that doesn't depend on the implementation of, say, Hashtable, and we remain compatible with future versions of the class libraries. Using serialization we do not depend on Hashtable implementation because its serialized form is specified [1]. But we do depend on implementation of classes in jx.s.t.html.parser package, the serialized form of which is not specified. However, I don't insist and we should consider other possibilities too. What about using ASN.1? We already have a decoder, so it shouldn't be difficult What is ASN.1? [1] file:///C:/Langs/JDK%205%20API/api/serialized-form.html#java.util.Hashta ble Regards, Alexey. SNIP -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AWT 2D PERFORMANCE ISSUE
-Original Message- From: Igor Stolyarov [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:25 AM To: harmony-dev@incubator.apache.org Subject: Re: AWT 2D PERFORMANCE ISSUE I'm sorry. May be I don't clear explained my question. Main target of my question was discussion of synchronization of two arrays one of these is java array, second is native array. Main issue of this synchronization is the fact that customer can recieve reference to the java array and we don't know when customer will release the array. What about using Weak- or PhantomReferences and ReferenceQueue? They may solve your problem. Regards, -- Alexey A. Ivanov Intel Middleware Product Division SNIP - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AWT 2D PERFORMANCE ISSUE
-Original Message- From: Igor Stolyarov [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 1:04 PM To: harmony-dev@incubator.apache.org Subject: Re: AWT 2D PERFORMANCE ISSUE I think using WeakReference and ReferenceQueue can't help because according to RI I have to give customer array You give the customer that array, and store a Weak- or PhantomReference in your object. When you need to update some data, you can check if the array you gave is still alive or not. I dealt with this kind of problem in javax.swing.text.GapContent. Its createPosition() method should return an object to client. This object returned must be updated when data (text) stored in GapContent is modified. To reduce the number of Position objects to be updated, I used PhantomReferences to be notified that the object I returned to client was cleared by garbage collector. Has anyone else dealt with reference APIs and similar problems? Regards, Alexey. On 7/28/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: -Original Message- From: Igor Stolyarov [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 9:25 AM To: harmony-dev@incubator.apache.org Subject: Re: AWT 2D PERFORMANCE ISSUE I'm sorry. May be I don't clear explained my question. Main target of my question was discussion of synchronization of two arrays one of these is java array, second is native array. Main issue of this synchronization is the fact that customer can recieve reference to the java array and we don't know when customer will release the array. What about using Weak- or PhantomReferences and ReferenceQueue? They may solve your problem. Regards, -- Alexey A. Ivanov Intel Middleware Product Division SNIP - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Igor V. Stolyarov Intel Middleware Products Division -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [optimization] Algorithmic tricks
-Original Message-
From: Denis Kishenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 26, 2006 7:25 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [optimization] Algorithmic tricks
Mikhail, you are right, in some places it can be very critical.
Now HashCode works only with primitive types int, long, float, double,
boolean and doesn't override String.hashCode(), so don't care about
strings.
It can handle Objects and uses object.hashCode().
Actually I don't understand the purpose of *combine()* method. I
suppose we
can reduce it to improve perfomance.
combine() performs the calculations. append() is a convenience method
that returns the object it was called upon, so that your example can be
re-written as follows:
public int hashCode() {
return new HashCode().append(m00)
.append(m01)
.append(m02)
.append(m10)
.append(m11)
.append(m12)
.hashCode();
}
It's like StringBuffer.append().
Regards,
Alexey.
2006/7/26, Mikhail Fursov [EMAIL PROTECTED]:
Some hashCode functions are actually very *hot* methods (e.g. String)
In this case I think that a bad but fast hashCode() could be better
than
good but slow. May be I'm wrong but only tests can show the
difference.
So if you have tests, I'm +1
On 7/26/06, Denis Kishenko [EMAIL PROTECTED] wrote:
Any comments?
--
Mikhail Fursov
--
Denis M. Kishenko
Intel Middleware Products Division
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [testing] locale dependent tests
Tim, Tests for DecimalFormat are not locale-specific. They fail because of the difference in the default data. I mean those five mentioned in the other thread (HARMONY-925). There's a problem with using DecimalFormatSymbols in this class which causes test_setDecimalFormatSymbolsLjava_text_DecimalFormatSymbols to fail. (This test is now excluded from running with 'failing' prefix; moreover the whole test class is excluded.) I logged this issue in HARMONY-965, and prepared a patch to fix the problem. Could you look at it? As for failing test ChoiceFormatterTest.test_toPattern(), I've also attached a patch to HARMONY-925 which fixes the problem. Later today I'm going to create a patch for DecimalFormatTest. I think to set the locale to en_US, so that the result of formatting is the same as expected. What do you think about it? Still it has several other tests failing, and I can't figure out why. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 7:47 PM To: harmony-dev@incubator.apache.org Subject: Re: [testing] locale dependent tests On 25/07/06, Richard Liang [EMAIL PROTECTED] wrote: snip Not sure what the fake hard-coded locale is. I used to set the default locale to some particular one, e.g., en_US, but it seems that someone (Tim) does not like the idea. :-) What I objected to was setting the locale to a specific value that made the tests pass even where the logic is locale-specific. So, for example, if an application using the ru_RU locale would experience the problem that Alexey is seeing with the DecimalFormat, then the tests should use the default locale, and we (Harmony) get the benefit of a wide community of hetrogeneous testers. i.e. don't make all tests run on a uniform machine set-up -- let them be realistic. Do you think we should always use the default locale, take the data from it, generate the result of formatting using these data, and then compare the strings? In my opinion, this will lead to almost unreadable tests? On the other hand, tests may still use the default locale until they proved to fail on some of the locales. And then we'll take a decision how to update test and whether we need an additional test for another locale. I mean, if necessary, we can create several tests for one method but with different locales, like en_US, ru_RU. Does it make sense? Thanks, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division 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: [testing] locale dependent tests
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 1:05 PM To: harmony-dev@incubator.apache.org Subject: Re: [testing] locale dependent tests On 26/07/06, Richard Liang [EMAIL PROTECTED] wrote: Tim Ellison wrote: On 25/07/06, Richard Liang [EMAIL PROTECTED] wrote: snip Not sure what the fake hard-coded locale is. I used to set the default locale to some particular one, e.g., en_US, but it seems that someone (Tim) does not like the idea. :-) What I objected to was setting the locale to a specific value that made the tests pass even where the logic is locale-specific. So, for example, if an application using the ru_RU locale would experience the problem that Alexey is seeing with the DecimalFormat, then the tests should use the default locale, and we (Harmony) get the benefit of a wide community of hetrogeneous testers. i.e. don't make all tests run on a uniform machine set-up -- let them be realistic. Agree :-) Maybe we will two kinds of locale-related tests: 1) tests which should pass on any locale 2) tests which are intended to be executed in one particular locale, for these tests, we can restrict the default locale to a specific one. Exactly. A comment in the source that slams the locale should be sufficient to show people that it is a type (2) test. Yeah, agree with this. Regards, Alexey. Regards, Tim Any comments? Thanks a lot. Best regards, Richard Regards, Tim -- 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] -- 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. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? On 25/07/06, Miguel Montes [EMAIL PROTECTED] wrote: Hi: Working on the HTML parser, I found the following problem. The HTML parser can be parameterized by a DTD. The class javax.swing.text.html.parser.DTD has a method read(DataInputStream), that reads a DTD in binary format. AFAIK, there is no public specification of this format, and the recent contribution of the HTML component (HARMONY- 948) seems to use its own binary format. Although I don´t know if there are applications out there using this method to load custom DTDs, the method is public, so I think we should be compatible with Sun. That is, we should be able to read Sun's bdtd, and our bdtd should be readable by Sun's implementation. I agree that it would be good to aim for interoperability here. Am i missing something? Does anyone know if there is a specification? Is it OK to reverse engineer the file html32.bdtd? I don't know of a spec, if you don't find one after some searching it may be something we want to go back and ask Sun. I recommend that you don't reverse engineer their implementation/format to figure it out. In the meantime we shall have to remain incompatible. I don't know about any spec. The bug on Sun site [1] seems to prove there is no spec for the binary format of DTD. In this implementation binary format is just a serialized version of DTD based on HTML 4.01 Transitional. Why do we need to read the binary DTD of Sun? Harmony classlib will have its own bdtd, which it is able to deal with. IMHO if we need to, we can create our own html32.bdtd. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4216248 Regards, Alexey. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Miguel, -Original Message- From: Miguel Montes [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 5:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? On 7/26/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 1:32 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd? On 25/07/06, Miguel Montes [EMAIL PROTECTED] wrote: Hi: Working on the HTML parser, I found the following problem. The HTML parser can be parameterized by a DTD. The class javax.swing.text.html.parser.DTD has a method read(DataInputStream), that reads a DTD in binary format. AFAIK, there is no public specification of this format, and the recent contribution of the HTML component (HARMONY- 948) seems to use its own binary format. Although I don´t know if there are applications out there using this method to load custom DTDs, the method is public, so I think we should be compatible with Sun. That is, we should be able to read Sun's bdtd, and our bdtd should be readable by Sun's implementation. I agree that it would be good to aim for interoperability here. Am i missing something? Does anyone know if there is a specification? Is it OK to reverse engineer the file html32.bdtd? I don't know of a spec, if you don't find one after some searching it may be something we want to go back and ask Sun. I recommend that you don't reverse engineer their implementation/format to figure it out. In the meantime we shall have to remain incompatible. I don't know about any spec. The bug on Sun site [1] seems to prove there is no spec for the binary format of DTD. In this implementation binary format is just a serialized version of DTD based on HTML 4.01 Transitional. Why do we need to read the binary DTD of Sun? Harmony classlib will have its own bdtd, which it is able to deal with. IMHO if we need to, we can create our own html32.bdtd. The method is public, so anyone can use it to read his own DTD. If it were private, or with package visibility, there wouldn't be any problem. The problem is with Sun's design. The implementation is completely exposed, with a lot of public fields. But being the method public, I think we should be interoperable. If someone decides to build his own DTD, it should work with any implementation. Yes, it should but there's no write method to write out a new DTD. There's only read which doesn't specify the format. So actually there's no way for anyone to use DTD.read method. Maybe what i'm saying is not even possible. Maybe there is no such thing as a Sun format, and they don't even try to preserve compatibility between versions. (although I tested that the JDK 1.5 can read the bdtd from 1.4.2). I believe this file hasn't changed in 1.5. And other files in html.parser package might not have changed. But that leads to another question. Doesn't the use of serialization tie us to a specific version of the class? What if the implementation changes? If we are not going to support Sun's format, I think we shouldn't make the same mistake as them. We should define a format, make it public, and adhere to it. This sounds reasonable. We can define a format, so that anyone could prepare its own binary DTD. On the other hand, using other DTD but HTML one with Swing HTML implementation has almost no meaning. HTML package is designed to handle HTML only. For instance, the JavaDoc for DocumentParser [1] says: actually, you can specify a DTD, but you should really only use this class with the html dtd in swing. Using serialization does tie us to a specific version of the class. If the implementation changes, we'll have to regenerate binary form. Any other thoughts? Regards, Alexey. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/html/parser/DocumentParser.html [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4216248 Regards, Alexey. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov 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] -- Miguel Montes -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [testing] locale dependent tests
-Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 6:26 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing] locale dependent tests Ivanov, Alexey A wrote: -Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 10:27 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing] locale dependent tests Andrew Zhang wrote: On 7/19/06, Richard Liang [EMAIL PROTECTED] wrote: Tim Ellison wrote: Richard Liang wrote: Although the spec does not require the round-trip of applyPattern and toPattern, we still want to get one *certain* pattern through toPattern. Now the problem is the returned pattern is locale-dependent. I'm uncertain about the reason to remove the assertion: 1) Because the behavior is not required by spec, or 2) Because the behavior is locale-dependent It would seem that rather than forcing the locale to be en_US to make the test assertions valid, you could work with the default locale and guard any assertions that are locale-specific. It would seem a shame to loose the diversity of testing on multiple locale machines if the tests always force everyone to look like an American (horror! ;-) ) I would expect the fix therefore to be something like, if locale is en_US go ahead and assert more round-tripping code, otherwise can't test it as the spec allows variances. If a test case passes in all locales, could we think that the behavior tested by the test case is locale-independent? We still have to think about how to test locale-dependent behavior. For example, java.util.Locale.getDisplayName() and java.lang.String.toUpperCase(). To verify both the code logic and locale data, shall we have some tests like ABC_en_US_Test, ABC_en_UK_Test, and ABC_ru_RU_Test? I still confuse what we want to test, the logic or the data? I think most (if not all) i18n related methods actually have same single executable with multiple resource bundles, i.e., the single executable should be locale-independent, the different return value is due to the resource data difference. I think at least for now, we should pay our attention to logic of single executable, and leave the data verification to the i18n libraries' author, say, ICU, they have much more knowledge and authority (at least than me) on this area. If we can get agree on the above, so the i18n related test cases organization are easier to judge: the logic is locale-independent, so ideally the tests should be locale-independent, but we have some exceptional cases, say, the en_UK in MessageFormat case, so we cannot make our tests rely on the default locale, then we just specify one locale(en_US) to the tests, and supplement some exceptional case when we find some. i.e., I don't think we need ABC_en_US_Test, or so. Comments? I don't think we need several test cases like ABC_en_US_Test and ABC_ru_RU_Test because users can modify locale data. Perhaps not all data can be changed, but some can be surely, for example, date/time formats, decimal and group separators. Thus a test which passes on one machine can fail on another one because locale data are different from the default values. I agree that we do not need the test cases like ABC_en_US_Test and ABC_ru_RU_Test. But I'm just wondering whether users could modify the locale data. Would you please give some instructions? Thanks a lot. In Windows XP, open the Control Panel, choose Date, Time, Language, and Regional Options group and then click Regional and Language Options (if in Classic View, just click this option). On the Regional Options tab click Customize button. A dialog opens. Here one can change formatting options like decimal separator symbol, digit grouping symbol, date format, time format and others. I can't give you instructions for Linux but surely there should be a way to customize these data. I know for sure that in Russia many users customize decimal separator to be point like in English locale. This is because many programs had problems dealing with something other than point in numbers. As far as I know the situation is better now. So, I think the best way to deal with such tests is to provide a fake hard-coded locale which can't be changed at all. And tests will become locale-independent. Not sure what the fake hard-coded locale is. I used to set the default locale to some particular one, e.g., en_US, but it seems that someone (Tim) does not like the idea. :-) By fake locale I mean a locale that doesn't fetch any settings from operating system. It may be en_US or another. However we should ensure the data in this locale can't be changed. If you had set en_US in the tests, we wouldn't have found bugs in DecimalFormatter, for example HARMONY-965. All tests would have passed successfully in Russian locale as well. So we need to ensure that the logic is correct. How? It's
RE: [classlib][html] HTML 3.2 or 4.01
I agree that we should implement both 3.2 and 4.01 DTDs. Moreover 3.2 is just a subset of 4.01 and, I believe, it doesn't require much work to support 3.2 too. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Saturday, July 22, 2006 11:44 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][html] HTML 3.2 or 4.01 I agree that we should implement both if it possible. Since we can easile determine the HTML version by DTD in the header. SY, Alexey 2006/7/22, Miguel Montes [EMAIL PROTECTED]: HI all: Intel has just contributed javax.swing.text.html, based on HTML 4.01. Sun's implementation, on the other hand, claims to be based on HTML 3.2, although there are same differences. ¿Which one should we follow? ¿Both? The parser behavior is parameterized by a DTD, so perhaps we should provide a 3.2 DTD, to be compatible with Sun, and a 4.01 DTD. Any ideas? Miguel Montes On 7/21/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Miguel Montes wrote: Hi all: On behalf of ITC, I would like to offer our help to complete this package. We could work in the missing parser. Fantastic. Please have the people working on it work here and with much discussion with the rest of the community. The new contribution is based on HTML 4.01, while Sun's version is based on HTML 3.2, (in fact, the DTD used is different from the HTML 3.2 DTD, perhaps is based on an early draft). ¿Which one should we follow? ¿How important is to be compatible with the existing codebase? To start the discussion, fire that off as a new thread w/ the subject : [classlib][html] .. or something. geir On 7/21/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hi all, I'd like to announce the contribution of javax.swing.text.html package on behalf of Intel. The archive can be found here: https://issues.apache.org/jira/browse/HARMONY-948 The contribution includes new files implementing HTML text functionality and a small patch for already existing files in javax.swing to integrate the new code. The package is incomplete, the code there is not sufficient to enable those nice help windows in jEdit... yet. If anyone wants to help making it complete, you have an excellent chance to do so! For the biggest issue, there is no HTML parser. Some tags are not supported yet, such as AREA, MAP, APPLET, IFRAME, OBJECT, PARAM and some others, as well as incomplete support of CSS1 properties. The list of known issues and TODOs can be found in the README file included in the contribution, as well as the building and testing instructions. Please don't hesitate to contact me for more details if needed, and I intend to keep working on this package in Harmony. -- Alexey A. Ivanov 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: 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] -- Miguel Montes -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
-Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Ivanov, Alexey A wrote: Hi all. BTW, my default locale is Russian That's the reason. DecimalFormatTest is locale-dependent, but the test logic doesn't take it into account. In Russian locale, comma is used as decimal separator but not dot. And it is the reason why some tests fail. I see two ways to resolve the problem: 1. Make tests locale-independent by explicitly specifying DecimalFormatSymbols. 2. Fetch these symbols from the DecimalFormat object, and modify the expected values using these data. 3. Specify a locale to the DecimalFormat in the test, should be similar with option 1, actually I suspect they are both necessary, because either locale setting or DecimalFormatSymbols setting should be part of DecimalFormat logic. This option is similar to the first one. And this option is not worth because any user may change their preferences as opposed to the default values. For example, I can change decimal separator used in US or UK locale to comma like in Russian. After that change the tests mentioned below will fail, the reason being the same as they fail now when run in Russian locale. Since it is logic that we want to test, setting DecimalFormatSymbols explicitly is the right way to do it. This way tests will not depend on locale data (which might be different from the default values). I tried to fix DecimalFormatTest using this approach and faced with bug in DecimalFormat implementation. I filed JIRA issue for that: https://issues.apache.org/jira/browse/HARMONY-965 Thanks, Alexey. I prefer the first approach since this ensures we test the underlying logic. [1] I can prepare patch if nobody objects. As for ChoiceFormatTest failure, there seems to be a bug in ChoiceFormatter which can't parse negative numbers. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mb ox/[EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 4:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test BTW, my default locale is Russian 2006/7/18, Alexei Zakharov [EMAIL PROTECTED]: Sure, DecimalFormatTest: Testcase: test_parseLjava_lang_String_Ljava_text_ParsePosition took 0 sec FAILED null junit.framework.AssertionFailedError at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_parseLja va_l ang_String_Ljava_text_ParsePosition(DecimalFormatTest.java:66) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setDecimalSeparatorAlwaysShownZ took 0 sec FAILED Wrong set result expected: but was:..., junit.framework.ComparisonFailure: Wrong set result expected: but was:..., at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setDecim alSe paratorAlwaysShownZ(DecimalFormatTest.java:1361) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMaximumFractionDigitsI took 0 sec FAILED Wrong maximum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong maximum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMaxim umFr actionDigitsI(DecimalFormatTest.java:1410) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumFractionDigitsI took 0,016 sec FAILED Wrong minimum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong minimum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMinim umFr actionDigitsI(DecimalFormatTest.java:1436) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumIntegerDigitsI took 0 sec FAILED Incorrect integer expected:... but was:...,... junit.framework.ComparisonFailure: Incorrect integer expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMinim umIn tegerDigitsI(DecimalFormatTest.java:1452) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) ChoiceFormatTest: === Testcase: test_toPattern took 0,016 sec Caused an ERROR null java.lang.IllegalArgumentException at java.text.ChoiceFormat.applyPattern(ChoiceFormat.java:126) at java.text.ChoiceFormat.init(ChoiceFormat.java:65) at org.apache.harmony.text.tests.java.text.ChoiceFormatTest.test_toPattern (Cho iceFormatTest.java:421) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Does this make sense? Regards, 2006/7/18, Tim Ellison [EMAIL
RE: [testing] locale dependent tests
-Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 10:27 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing] locale dependent tests Andrew Zhang wrote: On 7/19/06, Richard Liang [EMAIL PROTECTED] wrote: Tim Ellison wrote: Richard Liang wrote: Although the spec does not require the round-trip of applyPattern and toPattern, we still want to get one *certain* pattern through toPattern. Now the problem is the returned pattern is locale-dependent. I'm uncertain about the reason to remove the assertion: 1) Because the behavior is not required by spec, or 2) Because the behavior is locale-dependent It would seem that rather than forcing the locale to be en_US to make the test assertions valid, you could work with the default locale and guard any assertions that are locale-specific. It would seem a shame to loose the diversity of testing on multiple locale machines if the tests always force everyone to look like an American (horror! ;-) ) I would expect the fix therefore to be something like, if locale is en_US go ahead and assert more round-tripping code, otherwise can't test it as the spec allows variances. If a test case passes in all locales, could we think that the behavior tested by the test case is locale-independent? We still have to think about how to test locale-dependent behavior. For example, java.util.Locale.getDisplayName() and java.lang.String.toUpperCase(). To verify both the code logic and locale data, shall we have some tests like ABC_en_US_Test, ABC_en_UK_Test, and ABC_ru_RU_Test? I still confuse what we want to test, the logic or the data? I think most (if not all) i18n related methods actually have same single executable with multiple resource bundles, i.e., the single executable should be locale-independent, the different return value is due to the resource data difference. I think at least for now, we should pay our attention to logic of single executable, and leave the data verification to the i18n libraries' author, say, ICU, they have much more knowledge and authority (at least than me) on this area. If we can get agree on the above, so the i18n related test cases organization are easier to judge: the logic is locale-independent, so ideally the tests should be locale-independent, but we have some exceptional cases, say, the en_UK in MessageFormat case, so we cannot make our tests rely on the default locale, then we just specify one locale(en_US) to the tests, and supplement some exceptional case when we find some. i.e., I don't think we need ABC_en_US_Test, or so. Comments? I don't think we need several test cases like ABC_en_US_Test and ABC_ru_RU_Test because users can modify locale data. Perhaps not all data can be changed, but some can be surely, for example, date/time formats, decimal and group separators. Thus a test which passes on one machine can fail on another one because locale data are different from the default values. So, I think the best way to deal with such tests is to provide a fake hard-coded locale which can't be changed at all. And tests will become locale-independent. Any thoughts? Thanks, Alexey. Hi Richard, For getDisplayName, getDisplayLanguage() and methods like so, which are locale-dependent, I suggest we write implementation tests for them. The test may look like: 1. get default locale 2. get i18n string from ResourceBundle directly 3. get i18n string by locale-dependent method 4. assertEquals If we write test cases like this, these tests are probably locale-independent, because: the executable is probably single. I don't think we should have many locale-dependent methods, we just have many methods with locale-dependent data. Sounds reasonable? Any comments? Thank you! Best regards, Richard Regards, Tim -- Richard Liang China Software Development Lab, IBM -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov 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]
Contribution of the HTML sub-component of the SWING component
Hi all, I'd like to announce the contribution of javax.swing.text.html package on behalf of Intel. The archive can be found here: https://issues.apache.org/jira/browse/HARMONY-948 The contribution includes new files implementing HTML text functionality and a small patch for already existing files in javax.swing to integrate the new code. The package is incomplete, the code there is not sufficient to enable those nice help windows in jEdit... yet. If anyone wants to help making it complete, you have an excellent chance to do so! For the biggest issue, there is no HTML parser. Some tags are not supported yet, such as AREA, MAP, APPLET, IFRAME, OBJECT, PARAM and some others, as well as incomplete support of CSS1 properties. The list of known issues and TODOs can be found in the README file included in the contribution, as well as the building and testing instructions. Please don't hesitate to contact me for more details if needed, and I intend to keep working on this package in Harmony. -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Investigation shows that ChoiceFormatTest fails because of the same reason as DecimalFormatTest. ChoiceFormat uses DecimalFormat to parse template passed. And the template contains 1.0is 1+, so that DecimalFormat stops parsing when it encounters '.' because dot is not decimal separator in Russian locale. This is definitely not what was expected. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 3:02 PM To: harmony-dev@incubator.apache.org Subject: RE: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Hi all. BTW, my default locale is Russian That's the reason. DecimalFormatTest is locale-dependent, but the test logic doesn't take it into account. In Russian locale, comma is used as decimal separator but not dot. And it is the reason why some tests fail. I see two ways to resolve the problem: 1. Make tests locale-independent by explicitly specifying DecimalFormatSymbols. 2. Fetch these symbols from the DecimalFormat object, and modify the expected values using these data. I prefer the first approach since this ensures we test the underlying logic. [1] I can prepare patch if nobody objects. As for ChoiceFormatTest failure, there seems to be a bug in ChoiceFormatter which can't parse negative numbers. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.m b ox/[EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 4:36 PM To: harmony-dev@incubator.apache.org Subject: Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test BTW, my default locale is Russian 2006/7/18, Alexei Zakharov [EMAIL PROTECTED]: Sure, DecimalFormatTest: Testcase: test_parseLjava_lang_String_Ljava_text_ParsePosition took 0 sec FAILED null junit.framework.AssertionFailedError at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_parseLj a va_l ang_String_Ljava_text_ParsePosition(DecimalFormatTest.java:66) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setDecimalSeparatorAlwaysShownZ took 0 sec FAILED Wrong set result expected: but was:..., junit.framework.ComparisonFailure: Wrong set result expected: but was:..., at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setDeci m alSe paratorAlwaysShownZ(DecimalFormatTest.java:1361) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMaximumFractionDigitsI took 0 sec FAILED Wrong maximum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong maximum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMaxi m umFr actionDigitsI(DecimalFormatTest.java:1410) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumFractionDigitsI took 0,016 sec FAILED Wrong minimum expected:... but was:...,... junit.framework.ComparisonFailure: Wrong minimum expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMini m umFr actionDigitsI(DecimalFormatTest.java:1436) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Testcase: test_setMinimumIntegerDigitsI took 0 sec FAILED Incorrect integer expected:... but was:...,... junit.framework.ComparisonFailure: Incorrect integer expected:... but was:...,... at org.apache.harmony.text.tests.java.text.DecimalFormatTest.test_setMini m umIn tegerDigitsI(DecimalFormatTest.java:1452) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) ChoiceFormatTest: === Testcase: test_toPattern took 0,016 sec Caused an ERROR null java.lang.IllegalArgumentException at java.text.ChoiceFormat.applyPattern(ChoiceFormat.java:126) at java.text.ChoiceFormat.init(ChoiceFormat.java:65) at org.apache.harmony.text.tests.java.text.ChoiceFormatTest.test_toPatter n (Cho iceFormatTest.java:421) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Does this make sense? Regards, 2006/7/18, Tim Ellison [EMAIL PROTECTED]: Can you send details (e.g. a walkback) from the failing tests? Thanks Tim Alexei Zakharov wrote: Are you talking about HARMONY-910? I've applied it and MessageFormatTest is ok now (thanks, Richard!) But ChoiceFormatTest and DecimalFormatTest continue failing. 2006/7/18, Geir Magnusson Jr [EMAIL PROTECTED]: Read back to the [build] status thread I think that Richard has the fix done... Alexei Zakharov wrote: Nathan, SNIP -- Alexei Zakharov, Intel Middleware Product Division -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org
