RE: Component status pages (was:Re: any donations expected for awt and swing?)
> -Original Message- > From: zoe slattery [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 07, 2006 7:50 AM > To: harmony-dev@incubator.apache.org > Subject: Component status pages (was:Re: any donations expected for awt > and swing?) > > Tim Ellison wrote: > > Geir Magnusson Jr wrote: > > > >> Tim Ellison wrote: > >> > >>> Probably best to put the 'concerted work in progress' description on > the > >>> wiki, so anyone can join in; the website status page was intended to > be > >>> more of a current state of the code overview. We should also start to > >>> set ourselves some goals, in terms of applications to run, etc. > >>> > >> Why not have "started" on the webpage, and then a like to the wiki page > >> if there is one? > >> > >> Or just encourage people to ask here on the dev list... > >> > > > > Yes, that would be fine. If somebody wants to hack the wiki for module > > status pages, I'll volunteer to point to the website to them. > > > To start with (because it is easier for people to update) I've > replicated Tim's table on the Wiki > (here:http://wiki.apache.org/harmony/component_development_status). I've > linked one component (j.l.mangement) to a seperate page and marked it as > "started". How about other people marking up the areas that they are > working in? [Nathan Beyer] I added a LUNI page [1]. I've been trying to implement and stub out all of the missing Java 5 stuff, so I've put some of my information up there. [1] http://wiki.apache.org/harmony/LUNI > > Regards, > > Tim > > > > > >>> If you want to make a start on the wiki page that would be good, or if > >>> anyone else has an idea for tracking intent... > >>> > >>> It's also worth mentioning that I don't believe we should be exclusive > >>> about areas of work within, and contribution to, Harmony. > >>> > >> Absolutely. > >> > >> > >>> While I > >>> understand that the goal is to minimize redundant work, we may find > >>> ourselves in the situation of having more than one implementation of > the > >>> same APIs (we already saw this happen with 'security' and 'security2' > >>> contributions). This is no bad thing as it allows us to evaluate the > >>> best technical option (quickly) and proceed with the combined group of > >>> experts collaborating on a single code base. I hope we can continue > to > >>> do so 'harmoniously'. > >>> > >> Choice and competition is good. This isn't "live or die" competition, > >> but "we can choose best of breed" competition, and we all benefit. > There > >> are no losers. > >> > >> geir > >> > >> > >>> Regards, > >>> Tim > >>> > >>> karan malhi wrote: > >>> > Hi, > > I am writing the interfaces for the javax.accessibility package. Some > of > the interfaces are dependent on classes from the awt package. Are we > expecting any donations for awt, swing packages? > If donations are not expected then what approach should I take? > Should I > start writing stuff for awt and swing (on which accessibility > depends > on) so that accessibility classes compile during a build in harmony? > Please guide me here. > > Secondly, once a volunteer starts working on a "Missing" module as > stated on > > http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html > > , should the status be changed to something else like "Work in > progress" > or something? > > > > > >
Re: luni test script tweaks
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: do you want to discuss what you are undoing? I assume the monster diff is due to EOL differences or something... 1. I've make the test report location a variable I thought you pointed it back into luni? Nope, see http://svn.apache.org/viewcvs?rev=383948&view=rev 2. I've undone somebody else's undoing of the test suite invocation Right, because we didn't get the same info from doing the suite as we did form running individual tests, IIRC. Such as...? Launching the VM for every individual test case is not helpful here. forkmode="once" Yep Meaning that forkmode="once" solves that problem. So this isn't an issue. Since the suite was only a set of tests (no extra setup) what? IOW, you don't do anything else. It's just a bag. Once we get HARMONY-57 tests installed we will wrap the suite in the exclusions list support code, and can apply any other logic to select which tests are run, check for performance regressions, etc. It will still look like one JUnit suite to the Ant task. If we build the suite from including *Test.java then I don't think we can do that? I guess we can see what's proposed and accept or shoot it down then. I'm trying to limit the number of touch and maintenance points, and make the reporting richer. Maybe an ant task that reads meta-data (an exclusion list, a grouping, etc) and runs junit with suites created on the fly hm. So tests can be just dropped in, and there is some default suite that just picks them up automatically... Hmmm... [SNIP] Just looking at a report from a test suite, I can see the individual tests that were run. Is that what you meant? Here's what I did: cd make ant (to build the classlib code) copy across the VM into deploy, and XML jars into lib/boot ant -f build-test.xml test-luni,gen-report then browse ..\build\test_report\html\index.html So compare these two... First as is now in SVN : http://people.apache.org/~geirm/test_report_alltests/html/ And as it was in SVN (I just locally reverted the build.xml in luni/common/ to do this...) http://people.apache.org/~geirm/test_report_indiv/html/ The latter has more information. It lets you view by package, and by test class, which is a useful unit of measure. It also churns out more We may be able to get the same out of using a test suite, but IIRC, I tried a few week ago when I set this up, and wasn't able to... It's hard to imagine that there isn't a way... geir Regards, Tim [EMAIL PROTECTED] wrote: Author: tellison Date: Tue Mar 7 10:08:47 2006 New Revision: 383950 URL: http://svn.apache.org/viewcvs?rev=383950&view=rev Log: Use the test suite, and put the results in the reporting dir Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff == --- incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Tue Mar 7 10:08:47 2006 @@ -1,111 +1,99 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Re: enhanced/classlib/trunk/depends
Tim Ellison wrote: Jean-frederic Clere wrote: Tim Ellison wrote: Jean-frederic Clere wrote: Mark Hindess wrote: Using "touch .now; sleep 2; (cd make; ant) ; find depends ... \! -anewer .now" on both builds shows that the only files that aren't accessed by either build are the README files and: depends/files/java.security That probably isn't needed since the build uses: modules/security/src/java.home/lib/security/java.security instead. But that's the only one that's obviously redundant. Yep... I would prefer to classlib depends directory a readme that tells classlib depends on: CU4C version 3.4 (how to get and install it). ICU4JNI FDLIBM zlib Like this? http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/depends/oss/README.txt?view=markup Well I am complaining the svn contains binary files that could be "easly" rebuild... Should I propose an additional ant target to build those components? Sure - send it along. Done... (for Linux for the moment), please comment Cheers Jean-Frederic Thanks Tim On 04/03/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote: Hi, There are a lot of objects in this repos directory, do we really need them? Cheers Jean-Frederic -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. ftp://ftp.software.ibm.com/software/globalization/icu/3.4.1/icu-3.4.1.tgz"; dest="file.tar.gz" /> ftp://ftp.software.ibm.com/software/globalization/icu/icu4j/icu4jni/3.4/icu4jni_3_4.zip"; dest="file.zip" /> http://www.validlab.com/software/fdlibm52.tar.gz"; dest="file.tar.gz" /> http://www.zlib.net/zlib-1.2.3.tar.gz"; dest="file.tar.gz" />
Re: luni test script tweaks
Geir Magnusson Jr wrote:
>
>
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>>>
>>> Tim Ellison wrote:
Geir Magnusson Jr wrote:
> do you want to discuss what you are undoing?
I assume the monster diff is due to EOL differences or something...
1. I've make the test report location a variable
>>> I thought you pointed it back into luni?
>>
>> Nope, see http://svn.apache.org/viewcvs?rev=383948&view=rev
>>
2. I've undone somebody else's undoing of the test suite invocation
>>> Right, because we didn't get the same info from doing the suite as we
>>> did form running individual tests, IIRC.
>>
>> Such as...? Launching the VM for every individual test case is not
>> helpful here.
>
> forkmode="once"
Yep
>>> Since the suite was only a set of tests (no extra setup)
>>
>> what?
>
> IOW, you don't do anything else. It's just a bag.
Once we get HARMONY-57 tests installed we will wrap the suite in the
exclusions list support code, and can apply any other logic to select
which tests are run, check for performance regressions, etc. It will
still look like one JUnit suite to the Ant task. If we build the suite
from including *Test.java then I don't think we can do that?
>>> and explicitly for Eclipse users because
>>> Eclipse's JUnit support is/was broken ;)
>>
>> I use Eclipse all the time (and use the suite all the time from
>> Eclipse). This tweak makes the Ant script behave that way too.
>
> I thought you had to use the suite because it wouldn't run more than one
> test at a time... maybe that was before the current version...
As above, running a decorated test suite from Eclipse works ok.
>>> I thought there was no harm in
>>> running the individual tests. It also makes it easy to just drop in a
>>> test...
>>
>> I've had no problem so far adding tests. There is value in having
>> multiple suites (which we have only eluded to so far on the list).
>
> Sure - but that would be for developer testing, right? Meaning we'd
> want to organize into sensible suites for subareas of the library?
We can also use multiple suites for different 'exotic' configurations as
described by Mikhail a while ago. That is, we may choose to reserve
some tests for environments that are complex to set-up and only run them
as a specific test target (rather then ant -f build-tests.xml).
> The thing that we lose is individual test information in reporting...
> that's why I changed the ant script to just run the tests, and ignore
> the suites, as I thought of that as a crutch...
Just looking at a report from a test suite, I can see the individual
tests that were run. Is that what you meant?
Here's what I did:
cd make
ant (to build the classlib code)
copy across the VM into deploy, and XML jars into lib/boot
ant -f build-test.xml test-luni,gen-report
then browse ..\build\test_report\html\index.html
Regards,
Tim
> [EMAIL PROTECTED] wrote:
>> Author: tellison
>> Date: Tue Mar 7 10:08:47 2006
>> New Revision: 383950
>>
>> URL: http://svn.apache.org/viewcvs?rev=383950&view=rev
>> Log:
>> Use the test suite, and put the results in the reporting dir
>>
>> Modified:
>>
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>>
>>
>>
>>
>> Modified:
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>>
>>
>>
>> URL:
>> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff
>>
>>
>>
>> ==
>>
>>
>>
>> ---
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>>
>>
>> (original)
>> +++
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>>
>>
>> Tue Mar 7 10:08:47 2006
>> @@ -1,111 +1,99 @@
>> -
>> -
>> -
>> -
>> - -
>> -
>> - -
>> -
>> -> -srcdir="${hy.luni.src.main.java}"
>> -destdir="${hy.luni.bin.main}"
>> -source="${source.ver}"
>> -debug="${java.debug.option}">
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> - -
>> -> manifest="${hy.luni}/META-INF/MANIFEST.MF">
>> -
>> -
>> -
>> -
>> - -
>> -
>> -
>> -
>> -
>> -> - destdir="${hy.luni.bin.test}"
>> - sourcepath=""
>> - source="${source.ver}"
>> - debug="${java.debug.option}">
>> -
>> -
>> -
>> -
>> -
Re: jira messages redirected to commits mailing list
Geir Magnusson Jr wrote: > Tim Ellison wrote: >> Geir Magnusson Jr wrote: >>> >>> Tim Ellison wrote: >> What steps should I stop doing? > > It was a joke, referring to my continual plea to get some of the > conversations out and into -dev@ Sorry, the joke was lost on me. I would like to help reduce the volume of jira mail. For me it is easy enough to create a client filter to put messages sent from [EMAIL PROTECTED] in a separate folder, but I can quite understand the request to filter server-side, by moving the mail to a less-subscribed mailing list (commits) or its own mailing list or whatever. Every state change produces mail to the world - even though it is likely only of interest to the reporter, assignee, and watchers. i.e. any way to solve the problem rather than move it ;-) >>> Every change should be visible to everyone for maximum transparency, or >>> so I believe. It would be a pain in the rear if one had to explicitly >>> sign up for each jira one was interested in. >> >> Some people say every JIRA state change / comment is too much 'spam' -- >> you want to see them all ... > > Yes, because mail is easy to delete, filter, ignore. > > More importantly, I think a model that requires the community to > individually add themselves to each JIRA as a watcher is one prone to > failure of oversight. I know that I'd forget, and I believe that full > flows like this sometimes catch the attention of a new person to > participate. There also is the issue of archiving that mail stream... > It could be that isn't as important because JIRA has the info, but OTOH > someone might want to prove something was done with full exposure to the > community. Sure. > I guess my answer right now is that given how we are currently using > JIRA, I can't think of anything to cut out... > > Now that it doesn't go to -dev@, it's easier for those that want to > participate less? > > Maybe we have a separate list for the jira flow that we ask every > committer to sub to, but then people can just watch -dev@ and/or > -commit@ and not have to deal with it? Lets see how it goes with the mail going to -commit@ >>> That said, once the VM activity gets really honking, we'll probably need >>> a second stream for those... >> >> Not sure why the VM is special here. > > Not special, but different. It will be a separate group of people > working on different things, so we may want to start segmenting the mail > streams. People may really not care about VM stuff if the work on > classlib stuff, or classlib stuff if they are focused on the JIT or > something. > > We'll have to see. I agree. Regards, Tim Leo Simons wrote: > Taking care of this now... > > I will note that this makes it even more important for committers and > active contributors to subscribe to the commits mailing list - a > lot of > important information is in those jira messages. > > I will also note that it *also* makes it even more important that Jira > is not used for discussion - that really needs to happen here on the > mailing list where everyone can track it. The ASF has had some bad > experience in the past with too much communication going via the issue > tracker; this isn't so much a guideline as it is a pretty hard > requirement. > > - Leo > > On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: >> Mark Hindess wrote: >>> Geir, There are quite a lot of JIRA messages these days, perhaps it >>> is time to split the JIRA traffic to a separate list with a reply-to >>> set to harmony-dev. Or perhaps just have them sent to the commit >>> list? >> Yes, please... +1e6 >> >> -Archie >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Location of ResourceBundle classes for javax.accessibility.AccessibleBundle
Since nobody objected to this package structure, I will just assume the package to be org.apache.harmony.accessibility.internal Paulex Yang wrote: I'm not sure myself, but I personally think that is fine. There is also a "Resources" directory in every source folder, I have no idea what it is used for. Anyone can help? karan malhi wrote: Thanks Paulex, What about ResourceBundles specific to a package like for example javax.accessibility. Should we put the ResourceBundles in org.apache.harmony.accessibility.internal ? Paulex Yang wrote: Karan, karan malhi wrote: Hi, The javax.accessibility.AccessibleBundle class requires a default ResourceBundle. 1. Which package would we put the default resource bundle classes in? Currently the resource bundles are located in http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/internal/locale/ I think the classes without locale in its name is default bundles, for example, "Country" is a default one. 2. What locales are supported by Harmony? try java.util.Locale.getAvailableLocales() :) -- Karan Singh
Re: jira messages redirected to commits mailing list
That's great! I wonder if we have that feature turned on in the ASF installation Craig Blake wrote: One of the cooler Jira features is the mailing list integration. You can subscribe it to the mailing list, after which it will automatically scan email subjects for issue identifiers (i.e. HARMONY-) and add the email content as a comment to the referenced issue, including attachments. That might make it easier to maintain discussion on the list and have it propagated into JIRA rather than the other way around, if that's the way people want to go. http://www.atlassian.com/software/jira/docs/latest/issue_creation_email.html Craig On Mar 7, 2006, at 10:48 AM, Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Is there some way to teach JIRA not to send so much mail? Stop using it as a chat room. :) So what is the right way to use JIRA? - people open an issue, - maybe comment with a test case - maybe attach a patch or two - I may comment on the issue, with comments that are relevant to that specific issue - when I work on it I assign it to me, and say progress started - when I'm done I resolve it - when the reporter has verified it they comment to say so - I close it as verified What steps should I stop doing? Every state change produces mail to the world - even though it is likely only of interest to the reporter, assignee, and watchers. i.e. any way to solve the problem rather than move it ;-) Every change should be visible to everyone for maximum transparency, or so I believe. It would be a pain in the rear if one had to explicitly sign up for each jira one was interested in. Some people say every JIRA state change / comment is too much 'spam' -- you want to see them all ... That said, once the VM activity gets really honking, we'll probably need a second stream for those... Not sure why the VM is special here. Regards, Tim Leo Simons wrote: Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: jira messages redirected to commits mailing list
One of the cooler Jira features is the mailing list integration. You can subscribe it to the mailing list, after which it will automatically scan email subjects for issue identifiers (i.e. HARMONY- ) and add the email content as a comment to the referenced issue, including attachments. That might make it easier to maintain discussion on the list and have it propagated into JIRA rather than the other way around, if that's the way people want to go. http://www.atlassian.com/software/jira/docs/latest/ issue_creation_email.html Craig On Mar 7, 2006, at 10:48 AM, Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Is there some way to teach JIRA not to send so much mail? Stop using it as a chat room. :) So what is the right way to use JIRA? - people open an issue, - maybe comment with a test case - maybe attach a patch or two - I may comment on the issue, with comments that are relevant to that specific issue - when I work on it I assign it to me, and say progress started - when I'm done I resolve it - when the reporter has verified it they comment to say so - I close it as verified What steps should I stop doing? Every state change produces mail to the world - even though it is likely only of interest to the reporter, assignee, and watchers. i.e. any way to solve the problem rather than move it ;-) Every change should be visible to everyone for maximum transparency, or so I believe. It would be a pain in the rear if one had to explicitly sign up for each jira one was interested in. Some people say every JIRA state change / comment is too much 'spam' -- you want to see them all ... That said, once the VM activity gets really honking, we'll probably need a second stream for those... Not sure why the VM is special here. Regards, Tim Leo Simons wrote: Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: luni test script tweaks
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: do you want to discuss what you are undoing? I assume the monster diff is due to EOL differences or something... 1. I've make the test report location a variable I thought you pointed it back into luni? Nope, see http://svn.apache.org/viewcvs?rev=383948&view=rev 2. I've undone somebody else's undoing of the test suite invocation Right, because we didn't get the same info from doing the suite as we did form running individual tests, IIRC. Such as...? Launching the VM for every individual test case is not helpful here. forkmode="once" Since the suite was only a set of tests (no extra setup) what? IOW, you don't do anything else. It's just a bag. and explicitly for Eclipse users because Eclipse's JUnit support is/was broken ;) I use Eclipse all the time (and use the suite all the time from Eclipse). This tweak makes the Ant script behave that way too. I thought you had to use the suite because it wouldn't run more than one test at a time... maybe that was before the current version... I thought there was no harm in running the individual tests. It also makes it easy to just drop in a test... I've had no problem so far adding tests. There is value in having multiple suites (which we have only eluded to so far on the list). Sure - but that would be for developer testing, right? Meaning we'd want to organize into sensible suites for subareas of the library? The thing that we lose is individual test information in reporting... that's why I changed the ant script to just run the tests, and ignore the suites, as I thought of that as a crutch... Regards, Tim [EMAIL PROTECTED] wrote: Author: tellison Date: Tue Mar 7 10:08:47 2006 New Revision: 383950 URL: http://svn.apache.org/viewcvs?rev=383950&view=rev Log: Use the test suite, and put the results in the reporting dir Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff == --- incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Tue Mar 7 10:08:47 2006 @@ -1,111 +1,99 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Re: jira messages redirected to commits mailing list
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Is there some way to teach JIRA not to send so much mail? Stop using it as a chat room. :) So what is the right way to use JIRA? - people open an issue, - maybe comment with a test case - maybe attach a patch or two So far, I think these are important. - I may comment on the issue, with comments that are relevant to that specific issue Also good to know, since it's equivalent to technical discussion on the dev list. - when I work on it I assign it to me, and say progress started That's good to know too, since people can get an event driven picture of what's going on. However, this may be something we could reduce distro of... - when I'm done I resolve it - when the reporter has verified it they comment to say so - I close it as verified ALl of these are important too :/ What steps should I stop doing? It was a joke, referring to my continual plea to get some of the conversations out and into -dev@ Every state change produces mail to the world - even though it is likely only of interest to the reporter, assignee, and watchers. i.e. any way to solve the problem rather than move it ;-) Every change should be visible to everyone for maximum transparency, or so I believe. It would be a pain in the rear if one had to explicitly sign up for each jira one was interested in. Some people say every JIRA state change / comment is too much 'spam' -- you want to see them all ... Yes, because mail is easy to delete, filter, ignore. More importantly, I think a model that requires the community to individually add themselves to each JIRA as a watcher is one prone to failure of oversight. I know that I'd forget, and I believe that full flows like this sometimes catch the attention of a new person to participate. There also is the issue of archiving that mail stream... It could be that isn't as important because JIRA has the info, but OTOH someone might want to prove something was done with full exposure to the community. I guess my answer right now is that given how we are currently using JIRA, I can't think of anything to cut out... Now that it doesn't go to -dev@, it's easier for those that want to participate less? Maybe we have a separate list for the jira flow that we ask every committer to sub to, but then people can just watch -dev@ and/or -commit@ and not have to deal with it? That said, once the VM activity gets really honking, we'll probably need a second stream for those... Not sure why the VM is special here. Not special, but different. It will be a separate group of people working on different things, so we may want to start segmenting the mail streams. People may really not care about VM stuff if the work on classlib stuff, or classlib stuff if they are focused on the JIT or something. We'll have to see. geir Regards, Tim Leo Simons wrote: Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie
Re: luni test script tweaks
Geir Magnusson Jr wrote:
>
>
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>>> do you want to discuss what you are undoing?
>>
>> I assume the monster diff is due to EOL differences or something...
>>
>> 1. I've make the test report location a variable
>
> I thought you pointed it back into luni?
Nope, see http://svn.apache.org/viewcvs?rev=383948&view=rev
>> 2. I've undone somebody else's undoing of the test suite invocation
>
> Right, because we didn't get the same info from doing the suite as we
> did form running individual tests, IIRC.
Such as...? Launching the VM for every individual test case is not
helpful here.
> Since the suite was only a set of tests (no extra setup)
what?
> and explicitly for Eclipse users because
> Eclipse's JUnit support is/was broken ;)
I use Eclipse all the time (and use the suite all the time from
Eclipse). This tweak makes the Ant script behave that way too.
> I thought there was no harm in
> running the individual tests. It also makes it easy to just drop in a
> test...
I've had no problem so far adding tests. There is value in having
multiple suites (which we have only eluded to so far on the list).
Regards,
Tim
>>> [EMAIL PROTECTED] wrote:
Author: tellison
Date: Tue Mar 7 10:08:47 2006
New Revision: 383950
URL: http://svn.apache.org/viewcvs?rev=383950&view=rev
Log:
Use the test suite, and put the results in the reporting dir
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
URL:
http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
Tue Mar 7 10:08:47 2006
@@ -1,111 +1,99 @@
-
-
-
-
- -
-
- -
-
->>> -srcdir="${hy.luni.src.main.java}"
-destdir="${hy.luni.bin.main}"
-source="${source.ver}"
-debug="${java.debug.option}">
-
-
-
-
-
-
-
-
- -
->>> manifest="${hy.luni}/META-INF/MANIFEST.MF">
-
-
-
-
- -
-
-
-
-
->>> - destdir="${hy.luni.bin.test}"
- sourcepath=""
- source="${source.ver}"
- debug="${java.debug.option}">
-
-
-
-
-
-
-
-
-
-
-
- ->>> value="../../../../target/test_report" />
-
-
->>> -forkmode="once"
-printsummary="withOutAndErr"
-errorproperty="test.error"
-showoutput="on"
-dir="${hy.luni.bin.test}"
-jvm="${hy.target}/jre/bin/java">
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
- -
- - -
-
-
-
-
+
+
+
+
+ +
+
+ +
+
+>>> +srcdir="${hy.luni.src.main.java}"
+destdir="${hy.luni.bin.main}"
+source="${source.ver}"
+debug="${java.debug.option}">
+
+
+
+
+
+
+
+
+ +
+>>> manifest="${hy.luni}/META-INF/MANIFEST.MF">
+
+
+
+
+ +
+
+
+
+
+>>> + destdir="${hy.luni.bin.test}"
+ sourcepath=""
+ source="${source.ver}"
+ debug="${java.debug.option}">
+
+
+
+
+
+
+
+
+
+
+
+ +
+
+>>> +forkmode="once"
>
Re: jira messages redirected to commits mailing list
Geir Magnusson Jr wrote: > > > Tim Ellison wrote: >> Is there some way to teach JIRA not to send so much mail? > > Stop using it as a chat room. :) So what is the right way to use JIRA? - people open an issue, - maybe comment with a test case - maybe attach a patch or two - I may comment on the issue, with comments that are relevant to that specific issue - when I work on it I assign it to me, and say progress started - when I'm done I resolve it - when the reporter has verified it they comment to say so - I close it as verified What steps should I stop doing? >> Every state change produces mail to the world - even though it is likely >> only of interest to the reporter, assignee, and watchers. i.e. any way >> to solve the problem rather than move it ;-) > > Every change should be visible to everyone for maximum transparency, or > so I believe. It would be a pain in the rear if one had to explicitly > sign up for each jira one was interested in. Some people say every JIRA state change / comment is too much 'spam' -- you want to see them all ... > That said, once the VM activity gets really honking, we'll probably need > a second stream for those... Not sure why the VM is special here. Regards, Tim >> Leo Simons wrote: >>> Taking care of this now... >>> >>> I will note that this makes it even more important for committers and >>> active contributors to subscribe to the commits mailing list - a lot of >>> important information is in those jira messages. >>> >>> I will also note that it *also* makes it even more important that Jira >>> is not used for discussion - that really needs to happen here on the >>> mailing list where everyone can track it. The ASF has had some bad >>> experience in the past with too much communication going via the issue >>> tracker; this isn't so much a guideline as it is a pretty hard >>> requirement. >>> >>> - Leo >>> >>> On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: > Geir, There are quite a lot of JIRA messages these days, perhaps it > is time to split the JIRA traffic to a separate list with a reply-to > set to harmony-dev. Or perhaps just have them sent to the commit > list? Yes, please... +1e6 -Archie >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
location for top-level scripts (was: Re: svn commit: r383946 - in /incubator/harmony/enhanced/classlib/trunk: ./ RUNNING-TESTS.txt build-test.xml make/build-test.xml)
Geir Magnusson Jr wrote: > can we rename the directory then? Its name follows the pattern set by modules/luni/make/ and modules/security/make/. What do you want to call them? > I really hate having the main build > script in a subdir (I'm used to them in root), and if we can't agree on > that, can we not call it "make"? This script is delegating to the scripts that do the 'real' work in each module make directory. Not sure why it creates such a strong reaction. Regards, Tim > [EMAIL PROTECTED] wrote: >> Author: tellison >> Date: Tue Mar 7 10:01:56 2006 >> New Revision: 383946 >> >> URL: http://svn.apache.org/viewcvs?rev=383946&view=rev >> Log: >> Move test script into make dir, update doc, ignore temporary build >> artifacts >> >> Added: >> incubator/harmony/enhanced/classlib/trunk/make/build-test.xml >> Removed: >> incubator/harmony/enhanced/classlib/trunk/build-test.xml >> Modified: >> incubator/harmony/enhanced/classlib/trunk/ (props changed) >> incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt >> >> Propchange: incubator/harmony/enhanced/classlib/trunk/ >> -- >> >> --- svn:ignore (original) >> +++ svn:ignore Tue Mar 7 10:01:56 2006 >> @@ -6,3 +6,4 @@ >> VME_COPYRIGHT.txt >> VME_README.txt >> VME_THIRD_PARTY_NOTICES.txt >> +build >> >> Modified: incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt >> URL: >> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt?rev=383946&r1=383945&r2=383946&view=diff >> >> == >> >> --- incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt >> (original) >> +++ incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt Tue >> Mar 7 10:01:56 2006 >> @@ -52,11 +52,11 @@ >> $ cd make >> $ ant >> -This should build and installl all java and native components >> +This should build and install all java and native components >>2) Test : -in project root : +in make dir : >> $ ant -f build-test.xml >> >> Added: incubator/harmony/enhanced/classlib/trunk/make/build-test.xml >> URL: >> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-test.xml?rev=383946&view=auto >> >> == >> >> --- incubator/harmony/enhanced/classlib/trunk/make/build-test.xml (added) >> +++ incubator/harmony/enhanced/classlib/trunk/make/build-test.xml Tue >> Mar 7 10:01:56 2006 >> @@ -0,0 +1,80 @@ >> + >> + >> + >> + >> + >> + >> + Tests for classlib package >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> +> target="test-run" /> >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> +> target="test.classlib"/> >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> + >> \ No newline at end of file >> >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: luni test script tweaks
Tim Ellison wrote: Geir Magnusson Jr wrote: do you want to discuss what you are undoing? I assume the monster diff is due to EOL differences or something... 1. I've make the test report location a variable I thought you pointed it back into luni? 2. I've undone somebody else's undoing of the test suite invocation Right, because we didn't get the same info from doing the suite as we did form running individual tests, IIRC. Since the suite was only a set of tests (no extra setup) and explicitly for Eclipse users because Eclipse's JUnit support is/was broken ;) I thought there was no harm in running the individual tests. It also makes it easy to just drop in a test... Regards, Tim [EMAIL PROTECTED] wrote: Author: tellison Date: Tue Mar 7 10:08:47 2006 New Revision: 383950 URL: http://svn.apache.org/viewcvs?rev=383950&view=rev Log: Use the test suite, and put the results in the reporting dir Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff == --- incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Tue Mar 7 10:08:47 2006 @@ -1,111 +1,99 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - value="../../../../target/test_report" /> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
luni test script tweaks (was: Re: svn commit: r383950 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml)
Geir Magnusson Jr wrote:
> do you want to discuss what you are undoing?
I assume the monster diff is due to EOL differences or something...
1. I've make the test report location a variable
2. I've undone somebody else's undoing of the test suite invocation
Regards,
Tim
> [EMAIL PROTECTED] wrote:
>> Author: tellison
>> Date: Tue Mar 7 10:08:47 2006
>> New Revision: 383950
>>
>> URL: http://svn.apache.org/viewcvs?rev=383950&view=rev
>> Log:
>> Use the test suite, and put the results in the reporting dir
>>
>> Modified:
>>
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>>
>>
>> Modified:
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>>
>> URL:
>> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff
>>
>> ==
>>
>> ---
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>> (original)
>> +++
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
>> Tue Mar 7 10:08:47 2006
>> @@ -1,111 +1,99 @@
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -> -srcdir="${hy.luni.src.main.java}"
>> -destdir="${hy.luni.bin.main}"
>> -source="${source.ver}"
>> -debug="${java.debug.option}">
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -> manifest="${hy.luni}/META-INF/MANIFEST.MF">
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -> - destdir="${hy.luni.bin.test}"
>> - sourcepath=""
>> - source="${source.ver}"
>> - debug="${java.debug.option}">
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -> value="../../../../target/test_report" />
>> -
>> -
>> -> -forkmode="once"
>> -printsummary="withOutAndErr"
>> -errorproperty="test.error"
>> -showoutput="on"
>> -dir="${hy.luni.bin.test}"
>> -jvm="${hy.target}/jre/bin/java">
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> +srcdir="${hy.luni.src.main.java}"
>> +destdir="${hy.luni.bin.main}"
>> +source="${source.ver}"
>> +debug="${java.debug.option}">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> manifest="${hy.luni}/META-INF/MANIFEST.MF">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> + destdir="${hy.luni.bin.test}"
>> + sourcepath=""
>> + source="${source.ver}"
>> + debug="${java.debug.option}">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> +forkmode="once"
>> +printsummary="withOutAndErr"
>> +errorproperty="test.error"
>> +showoutput="on"
>> +dir="${hy.luni.bin.test}"
>> +jvm="${hy.target}/jre/bin/java">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> +haltonfailure="no"
>> +todir="${hy.tests.reports}">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>>
>>
>>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: jira messages redirected to commits mailing list
Tim Ellison wrote: Is there some way to teach JIRA not to send so much mail? Stop using it as a chat room. :) Every state change produces mail to the world - even though it is likely only of interest to the reporter, assignee, and watchers. i.e. any way to solve the problem rather than move it ;-) Every change should be visible to everyone for maximum transparency, or so I believe. It would be a pain in the rear if one had to explicitly sign up for each jira one was interested in. That said, once the VM activity gets really honking, we'll probably need a second stream for those... geir Regards, Tim Leo Simons wrote: Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie
Re: jira messages redirected to commits mailing list
Is there some way to teach JIRA not to send so much mail? Every state change produces mail to the world - even though it is likely only of interest to the reporter, assignee, and watchers. i.e. any way to solve the problem rather than move it ;-) Regards, Tim Leo Simons wrote: > Taking care of this now... > > I will note that this makes it even more important for committers and > active contributors to subscribe to the commits mailing list - a lot of > important information is in those jira messages. > > I will also note that it *also* makes it even more important that Jira > is not used for discussion - that really needs to happen here on the > mailing list where everyone can track it. The ASF has had some bad > experience in the past with too much communication going via the issue > tracker; this isn't so much a guideline as it is a pretty hard > requirement. > > - Leo > > On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: >> Mark Hindess wrote: >>> Geir, There are quite a lot of JIRA messages these days, perhaps it >>> is time to split the JIRA traffic to a separate list with a reply-to >>> set to harmony-dev. Or perhaps just have them sent to the commit >>> list? >> Yes, please... +1e6 >> >> -Archie > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [jira] Resolved: (HARMONY-174) Change windows native clean to be less verbose/confusing
I'm not sure who you wrote to - I'm very good about unsubbing people who write directly. I just manually unsubscribed you. Adios. geir crispyalien wrote: how the hell can I get out of this list? I wrote the administrators and I got no respons..I hate this spaming..I registered myself only on normal discution list and now I get tons of spam emails. pls tell me how can I unsubscribe. best regards, Valentin On 3/7/06, Tim Ellison (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.apache.org/jira/browse/HARMONY-174?page=all ] Tim Ellison resolved HARMONY-174: - Resolution: Fixed Thanks Mark, Fixed in native-src/win.IA32/rules.mak at repo revision 383882. Please check that it was applied as you expected. Change windows native clean to be less verbose/confusing Key: HARMONY-174 URL: http://issues.apache.org/jira/browse/HARMONY-174 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Assignee: Tim Ellison Priority: Trivial Attachments: change.win.del.to.be.more.like.linux.rm.-f As discussed on the list. Change delete on windows to be more like "rm -f" on linux. Will attach the trivial patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r383946 - in /incubator/harmony/enhanced/classlib/trunk: ./ RUNNING-TESTS.txt build-test.xml make/build-test.xml
can we rename the directory then? I really hate having the main build script in a subdir (I'm used to them in root), and if we can't agree on that, can we not call it "make"? [EMAIL PROTECTED] wrote: Author: tellison Date: Tue Mar 7 10:01:56 2006 New Revision: 383946 URL: http://svn.apache.org/viewcvs?rev=383946&view=rev Log: Move test script into make dir, update doc, ignore temporary build artifacts Added: incubator/harmony/enhanced/classlib/trunk/make/build-test.xml Removed: incubator/harmony/enhanced/classlib/trunk/build-test.xml Modified: incubator/harmony/enhanced/classlib/trunk/ (props changed) incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt Propchange: incubator/harmony/enhanced/classlib/trunk/ -- --- svn:ignore (original) +++ svn:ignore Tue Mar 7 10:01:56 2006 @@ -6,3 +6,4 @@ VME_COPYRIGHT.txt VME_README.txt VME_THIRD_PARTY_NOTICES.txt +build Modified: incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt?rev=383946&r1=383945&r2=383946&view=diff == --- incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt (original) +++ incubator/harmony/enhanced/classlib/trunk/RUNNING-TESTS.txt Tue Mar 7 10:01:56 2006 @@ -52,11 +52,11 @@ $ cd make $ ant -This should build and installl all java and native components +This should build and install all java and native components 2) Test : -in project root : +in make dir : $ ant -f build-test.xml Added: incubator/harmony/enhanced/classlib/trunk/make/build-test.xml URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/make/build-test.xml?rev=383946&view=auto == --- incubator/harmony/enhanced/classlib/trunk/make/build-test.xml (added) +++ incubator/harmony/enhanced/classlib/trunk/make/build-test.xml Tue Mar 7 10:01:56 2006 @@ -0,0 +1,80 @@ + + + + + + + Tests for classlib package + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file
unsubscribing help (was: Re: [jira] Resolved: (HARMONY-174) Change windows native clean to be less verbose/confusing)
Valentin, JIRA certainly produces tons of e-mail (too much IMHO) and AIUI it is all sent to the dev list for everyone to see. It is easy to filter/delete if you only want to see the discussions, but if you want to get off the dev list altogether send mail to "[EMAIL PROTECTED]". Regards, Tim crispyalien wrote: > how the hell can I get out of this list? I wrote the administrators and I > got no respons..I hate this spaming..I registered myself only on normal > discution list and now I get tons of spam emails. pls tell me how can I > unsubscribe. > > best regards, > Valentin > > On 3/7/06, Tim Ellison (JIRA) <[EMAIL PROTECTED]> wrote: >> [ http://issues.apache.org/jira/browse/HARMONY-174?page=all ] >> >> Tim Ellison resolved HARMONY-174: >> - >> >> Resolution: Fixed >> >> Thanks Mark, >> >> Fixed in native-src/win.IA32/rules.mak at repo revision 383882. >> >> Please check that it was applied as you expected. >> >> >>> Change windows native clean to be less verbose/confusing >>> >>> >>> Key: HARMONY-174 >>> URL: http://issues.apache.org/jira/browse/HARMONY-174 >>> Project: Harmony >>> Type: Improvement >>> Components: Classlib >>> Reporter: Mark Hindess >>> Assignee: Tim Ellison >>> Priority: Trivial >>> Attachments: change.win.del.to.be.more.like.linux.rm.-f >>> >>> As discussed on the list. Change delete on windows to be more like "rm >> -f" on linux. Will attach the trivial patch. >> >> -- >> 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 >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: svn commit: r383950 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml
do you want to discuss what you are undoing? geir [EMAIL PROTECTED] wrote: Author: tellison Date: Tue Mar 7 10:08:47 2006 New Revision: 383950 URL: http://svn.apache.org/viewcvs?rev=383950&view=rev Log: Use the test suite, and put the results in the reporting dir Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml URL: http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml?rev=383950&r1=383949&r2=383950&view=diff == --- incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/luni/make/common/build.xml Tue Mar 7 10:08:47 2006 @@ -1,111 +1,99 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Re: [classlib] do we have any current instances where we've chosen to disagree with the spec or RI?
Tim Ellison wrote: Yes we do. I'm not convinced that logging them in JIRA is the right thing -- I'd like to see them a bit closer to the code. Having them in JIRA doesn't exclude doing anything else, just serves as an additional tracking system - a central directory of how we deviate so we can keep easy track of the status of any deviation. IMHO when we agree on a departure from the spec/RI then the differences should be embodied in an API test case. We should expect the test to pass on harmony code, and fail on the RI -- then add that test to the RI exclusion list so that all our remaining API tests pass on the RI. The exclusion list will become the repository of differences. We can address each exclusion if/when they are resolved in the RI. That works, but a set of test cases doesn't capture what I was hoping to find in the JIRA, such as a simple way to search, and english-language description. THe JIRA should point to the test case, and a mail archive of the discussion of the decision. geir Regards, Tim Geir Magnusson Jr wrote: If so, lets be sure to log them in JIRA - I created a category for this (I forget the name, but it will be obvious...) geir
Re: [classlib] do we have any current instances where we've chosen to disagree with the spec or RI?
Yes we do. I'm not convinced that logging them in JIRA is the right thing -- I'd like to see them a bit closer to the code. IMHO when we agree on a departure from the spec/RI then the differences should be embodied in an API test case. We should expect the test to pass on harmony code, and fail on the RI -- then add that test to the RI exclusion list so that all our remaining API tests pass on the RI. The exclusion list will become the repository of differences. We can address each exclusion if/when they are resolved in the RI. Regards, Tim Geir Magnusson Jr wrote: > If so, lets be sure to log them in JIRA - I created a category for this > (I forget the name, but it will be obvious...) > > geir > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: jira messages redirected to commits mailing list (was: [jira] Updated: (HARMONY-188) ...)
On Tue, Mar 07, 2006 at 09:19:54AM -0800, Craig Blake wrote: > Sweet, many thanks. +1, I wasn't being flooded but it's nice to be able to separate these flows without client-side filters. Steph -- Stephane Meslin-Weber Email: [EMAIL PROTECTED] Senior Software Engineer Web: http://odonata.tangency.co.uk signature.asc Description: Digital signature
Re: jira messages redirected to commits mailing list (was: [jira] Updated: (HARMONY-188) ...)
Sweet, many thanks. Craig On Mar 7, 2006, at 9:14 AM, Leo Simons wrote: Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie
jira messages redirected to commits mailing list (was: [jira] Updated: (HARMONY-188) ...)
Taking care of this now... I will note that this makes it even more important for committers and active contributors to subscribe to the commits mailing list - a lot of important information is in those jira messages. I will also note that it *also* makes it even more important that Jira is not used for discussion - that really needs to happen here on the mailing list where everyone can track it. The ASF has had some bad experience in the past with too much communication going via the issue tracker; this isn't so much a guideline as it is a pretty hard requirement. - Leo On Tue, Mar 07, 2006 at 08:17:45AM -0600, Archie Cobbs wrote: > Mark Hindess wrote: > >Geir, There are quite a lot of JIRA messages these days, perhaps it > >is time to split the JIRA traffic to a separate list with a reply-to > >set to harmony-dev. Or perhaps just have them sent to the commit > >list? > > Yes, please... +1e6 > > -Archie
Re: unsubscribing WAS (inappropriately) [jira] Updated: (HARMONY-188) ObjectOutputStream.useProtocolVersion(version) should check a parameter value.
--- crispyalien <[EMAIL PROTECTED]> wrote: > PLS HELP ME UNSUBSCRIBE TO THAT JIRA list!!! HELP.. > I HATE harmony already > because of all that spam!! [SNIP] The way to unsubscribe is probably sending an empty email to: [EMAIL PROTECTED] at a guess. It is unfortunate that you feel that you have been "spammed" (you haven't); you chose to join the list and JIRA notifications hardly qualify as spam. When you joined the list you received instructions on how to unsubscribe from it (strike two for you for having ignored or lost them). All-cap "screaming" at everyone on this list and replying to emails with unrelated content is disruptive and rude to everyone else on the list. So if that's what it takes to evoke your manners, by all means unsubscribe. These are the opinions of a "bystander" on the list and do not represent those of the Harmony project as a whole or any other entity. br, Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: How to deal with this kind of serialization compatibility issue?
I see it as an opportunity. :) We should ask Sun what to do they are the "go to" people for compatibility questions, right? geir George Harley wrote: Thanks Chris, your experience on this matter is very welcome. Even if it does make me feel a little depressed ;-) Best regards, George Chris Gray wrote: Hi George, I wonder what lessons other class library development teams have learned in this area ? I guess that our experience from Wonka can be summed up as "serialization is a PITA". Most of the time the problem can be solved, you just never know where the next one will pop up. We advise our cutomers against using serialization as a way to exchange data between VMs - use XML, use Hessian, use anything except serialization. That goes for RMI too. I guess it's easier for us to take this line in an embedded environment than in the context of, say, J2EE. Good luck, Chris
[jira] Commented: (HARMONY-171) Move more shared code from win/linux natives.
[ http://issues.apache.org/jira/browse/HARMONY-171?page=comments#action_12369238 ] Mark Hindess commented on HARMONY-171: -- Oops. There is a typo in the 01 script: svn remove native-src/win.IA32/archive/zip.c should read: svn remove native-src/linux.IA32/archive/zip.c > Move more shared code from win/linux natives. > - > > Key: HARMONY-171 > URL: http://issues.apache.org/jira/browse/HARMONY-171 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Priority: Minor > Attachments: 01.shared.moves.sh, 02.shared.diff > > Thanks to Oliver's changes (HARMONY-155) there are now more identical files > in the win/linux native trees. I'll attach a patch to move them to the > shared tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to deal with this kind of serialization compatibility issue?
Thanks Chris, your experience on this matter is very welcome. Even if it does make me feel a little depressed ;-) Best regards, George Chris Gray wrote: Hi George, I wonder what lessons other class library development teams have learned in this area ? I guess that our experience from Wonka can be summed up as "serialization is a PITA". Most of the time the problem can be solved, you just never know where the next one will pop up. We advise our cutomers against using serialization as a way to exchange data between VMs - use XML, use Hessian, use anything except serialization. That goes for RMI too. I guess it's easier for us to take this line in an embedded environment than in the context of, say, J2EE. Good luck, Chris
Re: How to deal with this kind of serialization compatibility issue?
Mikhail Loenko wrote:
The problem is serial form contains class name "sun.foo"
and if you deal with "o.a.h.foo" then serialization framework
will never know that you class's readObject() is to be invoked.
Yep, you're right : it really is a lot worse than I originally envisaged :-(
Another option is provide 'pairs' to ObjectInputStream.readObject():
for each 'foo' method it will know what is the corresponding harmony
class.
Sounds like keeping the list of pairs up to date could become a
never-ending task :-(
Given this plus the valuable insight from Chris Gray, I'm starting to
see "let it be" as a serious option.
Best regards,
George
Thanks,
Mikhail
2006/3/7, George Harley <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
George,
2006/3/7, George Harley <[EMAIL PROTECTED]>:
Paulex Yang wrote:
This kind of serialization compatibility issue may be found again
later, if only RI use some non-API class as default implementation of
serializable abstract class. So I think we need some discussion on
this issue for a principle.
I propose two choice:
1. just let it be
2. mimic a class as RI, in this TimeZone case, create a
sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
works but risky and ugly, it is risky because RI may change the
implementation class later(which will also break RI's serialization
compatibility of course)
comments?
Hi Paulex,
When such RI->Harmony serialization incompatibilities come to light we
can aim to deal with it in readObject() methods added to the affected
It is not quite clear, in which class you are going to deal with readObject() ?
Are you suggesting modification of IO framework that does serialization?
Thanks,
Mikhail
Hi Mikhail,
I mean the "private void readObject(ObjectInputStream os)" method that
every type implementing the Serializable interface can contain to
provide customised de-serialization.
Best regards,
George
types. This will have to be done on a case-by-case basis of course. In
this particular case I could imagine that we could catch that
ClassNotFoundException in the method and proceed on from there.
But what about Harmony->RI serialization incompatibilities ? That is,
what about Harmony applications serializing types to files and those
files being later read in by applications running on a RI JRE ? In some
cases we will probably "get away with it" as the differences in
implementation will not break compatibility. For instance, running your
test code so that Harmony produces the .ser file and the RI reads it in
seemed to work fine for me. But the risk of problems will always be
there. I am not certain that writing stubs of sun.* classes is a good
direction to set off in to counter those risks. It would be better to
try and work with the RI providers so that their classes can cope with
serialized Harmony types.
I wonder what lessons other class library development teams have learned
in this area ?
Best regards,
George
Paulex Yang (JIRA) wrote:
java.util.TimeZone's default implementation may cause many classes'
serialization non-compatible with RI
Key: HARMONY-184
URL: http://issues.apache.org/jira/browse/HARMONY-184
Project: Harmony
Type: Bug
Components: Classlib Reporter: Paulex Yang
Priority: Critical
Static factory methods, java.util.TimeZone.getInstance(String) and
getDefault(), are only ways to get a TimeZone instance, but Harmony
and RI uses different classes as default implementation, which cause
serialization non-compatible. Further, all classes whose
serialization form includes TimeZone won't compatible with RI, too,
for example, java.util.Calendar(with subclass),
java.text.DateFormat(with subclass), etc.
But the incompatiblity is hard to be imputed to Harmony, because
Harmony use API class SimpleTimeZone as default implementation, but
RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
The reproduce procedure:
1. To serialize TimeZone object to a file in RI, run codes below in RI
public void writeObject(){
TimeZone zone = TimeZone.getTimeZone("GMT");
ObjectOutputStream ooutput = null;
try {
ooutput = new ObjectOutputStream(new
FileOutputStream("TimeZone.ser"));
ooutput.writeObject(zone);
} finally {
try {
if (null != ooutput) {
ooutput.close();
}
} catch (Exception e) {
}
}
}
2. Trying to deserialize this object from file, run codes below
public void readObject(){
ObjectInputStream oinput = null;
try {
oinput = new ObjectInputStream(new
FileInputStream("TimeZone.ser"));
TimeZone newObj = (TimeZone)oinput.readObject();
} finally {
try {
Re: How to deal with this kind of serialization compatibility issue?
2006/3/7, Geir Magnusson Jr <[EMAIL PROTECTED]>: > This is somewhat terrifying, isn't it? Are there really references to > com.sun.* in serialized API objects? Yes, there are. For example, TimeZone.ser produced by the example from the JIRA issue that started this thread, refers to "sun.util.calendar.ZoneInfo" Can we list all the popular applications that exchange by serialized objects and identify which objects do they send/receive? Thanks, Mikhail
Re: [jira] Updated: (HARMONY-188) ObjectOutputStream.useProtocolVersion(version) should check a parameter value.
Mark Hindess wrote: Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Yes, please... +1e6 -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [jira] Updated: (HARMONY-188) ObjectOutputStream.useProtocolVersion(version) should check a parameter value.
On 3/7/06, crispyalien <[EMAIL PROTECTED]> wrote: > > PLS HELP ME UNSUBSCRIBE TO THAT JIRA list!!! HELP.. I HATE harmony > already because of all that spam!! JIRA messages are sent to the harmony-dev list. Currently the only way to avoid them is to unsubscribe from the harmony-dev list or filter them yourself. Geir, There are quite a lot of JIRA messages these days, perhaps it is time to split the JIRA traffic to a separate list with a reply-to set to harmony-dev. Or perhaps just have them sent to the commit list? Regards, Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
Component status pages (was:Re: any donations expected for awt and swing?)
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Probably best to put the 'concerted work in progress' description on the wiki, so anyone can join in; the website status page was intended to be more of a current state of the code overview. We should also start to set ourselves some goals, in terms of applications to run, etc. Why not have "started" on the webpage, and then a like to the wiki page if there is one? Or just encourage people to ask here on the dev list... Yes, that would be fine. If somebody wants to hack the wiki for module status pages, I'll volunteer to point to the website to them. To start with (because it is easier for people to update) I've replicated Tim's table on the Wiki (here:http://wiki.apache.org/harmony/component_development_status). I've linked one component (j.l.mangement) to a seperate page and marked it as "started". How about other people marking up the areas that they are working in? Regards, Tim If you want to make a start on the wiki page that would be good, or if anyone else has an idea for tracking intent... It's also worth mentioning that I don't believe we should be exclusive about areas of work within, and contribution to, Harmony. Absolutely. While I understand that the goal is to minimize redundant work, we may find ourselves in the situation of having more than one implementation of the same APIs (we already saw this happen with 'security' and 'security2' contributions). This is no bad thing as it allows us to evaluate the best technical option (quickly) and proceed with the combined group of experts collaborating on a single code base. I hope we can continue to do so 'harmoniously'. Choice and competition is good. This isn't "live or die" competition, but "we can choose best of breed" competition, and we all benefit. There are no losers. geir Regards, Tim karan malhi wrote: Hi, I am writing the interfaces for the javax.accessibility package. Some of the interfaces are dependent on classes from the awt package. Are we expecting any donations for awt, swing packages? If donations are not expected then what approach should I take? Should I start writing stuff for awt and swing (on which accessibility depends on) so that accessibility classes compile during a build in harmony? Please guide me here. Secondly, once a volunteer starts working on a "Missing" module as stated on http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html , should the status be changed to something else like "Work in progress" or something?
Re: [jira] Updated: (HARMONY-188) ObjectOutputStream.useProtocolVersion(version) should check a parameter value.
PLS HELP ME UNSUBSCRIBE TO THAT JIRA list!!! HELP.. I HATE harmony already because of all that spam!! On 3/7/06, Dmitry M. Kononov (JIRA) <[EMAIL PROTECTED]> wrote: > > [ http://issues.apache.org/jira/browse/HARMONY-188?page=all ] > > Dmitry M. Kononov updated HARMONY-188: > -- > > Attachment: Test17.java > > > ObjectOutputStream.useProtocolVersion(version) should check a parameter > value. > > > -- > > > > Key: HARMONY-188 > > URL: http://issues.apache.org/jira/browse/HARMONY-188 > > Project: Harmony > > Type: Bug > > Components: Classlib > > Reporter: Dmitry M. Kononov > > Priority: Minor > > Attachments: Test17.java > > > > ObjectOutputStream.useProtocolVersion(version) has to throw > IllegalArgumentException if the given version is invalid. There are only two > valid protocol versions: ObjectStreamConstants.PROTOCOL_VERSION_1 and > ObjectStreamConstants.PROTOCOL_VERSION_2. > > -- > 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 > >
[jira] Updated: (HARMONY-188) ObjectOutputStream.useProtocolVersion(version) should check a parameter value.
[ http://issues.apache.org/jira/browse/HARMONY-188?page=all ] Dmitry M. Kononov updated HARMONY-188: -- Attachment: Test17.java > ObjectOutputStream.useProtocolVersion(version) should check a parameter value. > -- > > Key: HARMONY-188 > URL: http://issues.apache.org/jira/browse/HARMONY-188 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Dmitry M. Kononov > Priority: Minor > Attachments: Test17.java > > ObjectOutputStream.useProtocolVersion(version) has to throw > IllegalArgumentException if the given version is invalid. There are only two > valid protocol versions: ObjectStreamConstants.PROTOCOL_VERSION_1 and > ObjectStreamConstants.PROTOCOL_VERSION_2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Resolved: (HARMONY-174) Change windows native clean to be less verbose/confusing
how the hell can I get out of this list? I wrote the administrators and I got no respons..I hate this spaming..I registered myself only on normal discution list and now I get tons of spam emails. pls tell me how can I unsubscribe. best regards, Valentin On 3/7/06, Tim Ellison (JIRA) <[EMAIL PROTECTED]> wrote: > > [ http://issues.apache.org/jira/browse/HARMONY-174?page=all ] > > Tim Ellison resolved HARMONY-174: > - > > Resolution: Fixed > > Thanks Mark, > > Fixed in native-src/win.IA32/rules.mak at repo revision 383882. > > Please check that it was applied as you expected. > > > > Change windows native clean to be less verbose/confusing > > > > > > Key: HARMONY-174 > > URL: http://issues.apache.org/jira/browse/HARMONY-174 > > Project: Harmony > > Type: Improvement > > Components: Classlib > > Reporter: Mark Hindess > > Assignee: Tim Ellison > > Priority: Trivial > > Attachments: change.win.del.to.be.more.like.linux.rm.-f > > > > As discussed on the list. Change delete on windows to be more like "rm > -f" on linux. Will attach the trivial patch. > > -- > 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 > >
[jira] Commented: (HARMONY-174) Change windows native clean to be less verbose/confusing
[ http://issues.apache.org/jira/browse/HARMONY-174?page=comments#action_12369230 ] Mark Hindess commented on HARMONY-174: -- Looks good. Thanks Tim. > Change windows native clean to be less verbose/confusing > > > Key: HARMONY-174 > URL: http://issues.apache.org/jira/browse/HARMONY-174 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Assignee: Tim Ellison > Priority: Trivial > Attachments: change.win.del.to.be.more.like.linux.rm.-f > > As discussed on the list. Change delete on windows to be more like "rm -f" > on linux. Will attach the trivial patch. -- 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
[classlib] do we have any current instances where we've chosen to disagree with the spec or RI?
If so, lets be sure to log them in JIRA - I created a category for this (I forget the name, but it will be obvious...) geir
Re: How to deal with this kind of serialization compatibility issue?
Hi George, > I wonder what lessons other class library development teams have learned > in this area ? I guess that our experience from Wonka can be summed up as "serialization is a PITA". Most of the time the problem can be solved, you just never know where the next one will pop up. We advise our cutomers against using serialization as a way to exchange data between VMs - use XML, use Hessian, use anything except serialization. That goes for RMI too. I guess it's easier for us to take this line in an embedded environment than in the context of, say, J2EE. Good luck, Chris -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: How to deal with this kind of serialization compatibility issue?
This is somewhat terrifying, isn't it? Are there really references to
com.sun.* in serialized API objects? This *has* to be a bug in the
whole spec if so...
Is serialization called out as being non-portable?
(I never thought of this before because I always worked in homogeneous
JRE environments...)
geir
Mikhail Loenko wrote:
The problem is serial form contains class name "sun.foo"
and if you deal with "o.a.h.foo" then serialization framework
will never know that you class's readObject() is to be invoked.
Another option is provide 'pairs' to ObjectInputStream.readObject():
for each 'foo' method it will know what is the corresponding harmony
class.
Thanks,
Mikhail
2006/3/7, George Harley <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
George,
2006/3/7, George Harley <[EMAIL PROTECTED]>:
Paulex Yang wrote:
This kind of serialization compatibility issue may be found again
later, if only RI use some non-API class as default implementation of
serializable abstract class. So I think we need some discussion on
this issue for a principle.
I propose two choice:
1. just let it be
2. mimic a class as RI, in this TimeZone case, create a
sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
works but risky and ugly, it is risky because RI may change the
implementation class later(which will also break RI's serialization
compatibility of course)
comments?
Hi Paulex,
When such RI->Harmony serialization incompatibilities come to light we
can aim to deal with it in readObject() methods added to the affected
It is not quite clear, in which class you are going to deal with readObject() ?
Are you suggesting modification of IO framework that does serialization?
Thanks,
Mikhail
Hi Mikhail,
I mean the "private void readObject(ObjectInputStream os)" method that
every type implementing the Serializable interface can contain to
provide customised de-serialization.
Best regards,
George
types. This will have to be done on a case-by-case basis of course. In
this particular case I could imagine that we could catch that
ClassNotFoundException in the method and proceed on from there.
But what about Harmony->RI serialization incompatibilities ? That is,
what about Harmony applications serializing types to files and those
files being later read in by applications running on a RI JRE ? In some
cases we will probably "get away with it" as the differences in
implementation will not break compatibility. For instance, running your
test code so that Harmony produces the .ser file and the RI reads it in
seemed to work fine for me. But the risk of problems will always be
there. I am not certain that writing stubs of sun.* classes is a good
direction to set off in to counter those risks. It would be better to
try and work with the RI providers so that their classes can cope with
serialized Harmony types.
I wonder what lessons other class library development teams have learned
in this area ?
Best regards,
George
Paulex Yang (JIRA) wrote:
java.util.TimeZone's default implementation may cause many classes'
serialization non-compatible with RI
Key: HARMONY-184
URL: http://issues.apache.org/jira/browse/HARMONY-184
Project: Harmony
Type: Bug
Components: Classlib Reporter: Paulex Yang
Priority: Critical
Static factory methods, java.util.TimeZone.getInstance(String) and
getDefault(), are only ways to get a TimeZone instance, but Harmony
and RI uses different classes as default implementation, which cause
serialization non-compatible. Further, all classes whose
serialization form includes TimeZone won't compatible with RI, too,
for example, java.util.Calendar(with subclass),
java.text.DateFormat(with subclass), etc.
But the incompatiblity is hard to be imputed to Harmony, because
Harmony use API class SimpleTimeZone as default implementation, but
RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
The reproduce procedure:
1. To serialize TimeZone object to a file in RI, run codes below in RI
public void writeObject(){
TimeZone zone = TimeZone.getTimeZone("GMT");
ObjectOutputStream ooutput = null;
try {
ooutput = new ObjectOutputStream(new
FileOutputStream("TimeZone.ser"));
ooutput.writeObject(zone);
} finally {
try {
if (null != ooutput) {
ooutput.close();
}
} catch (Exception e) {
}
}
}
2. Trying to deserialize this object from file, run codes below
public void readObject(){
ObjectInputStream oinput = null;
try {
oinput = new ObjectInputStream(new
FileInputStream("TimeZone.ser"));
TimeZone newObj = (TimeZone)oinput.readObject();
} finally {
try {
if (null != oinput) {
oinput.close();
[jira] Created: (HARMONY-188) ObjectOutputStream.useProtocolVersion(version) should check a parameter value.
ObjectOutputStream.useProtocolVersion(version) should check a parameter value. -- Key: HARMONY-188 URL: http://issues.apache.org/jira/browse/HARMONY-188 Project: Harmony Type: Bug Components: Classlib Reporter: Dmitry M. Kononov Priority: Minor ObjectOutputStream.useProtocolVersion(version) has to throw IllegalArgumentException if the given version is invalid. There are only two valid protocol versions: ObjectStreamConstants.PROTOCOL_VERSION_1 and ObjectStreamConstants.PROTOCOL_VERSION_2. -- 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
[jira] Resolved: (HARMONY-174) Change windows native clean to be less verbose/confusing
[ http://issues.apache.org/jira/browse/HARMONY-174?page=all ] Tim Ellison resolved HARMONY-174: - Resolution: Fixed Thanks Mark, Fixed in native-src/win.IA32/rules.mak at repo revision 383882. Please check that it was applied as you expected. > Change windows native clean to be less verbose/confusing > > > Key: HARMONY-174 > URL: http://issues.apache.org/jira/browse/HARMONY-174 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Assignee: Tim Ellison > Priority: Trivial > Attachments: change.win.del.to.be.more.like.linux.rm.-f > > As discussed on the list. Change delete on windows to be more like "rm -f" > on linux. Will attach the trivial patch. -- 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
[jira] Assigned: (HARMONY-174) Change windows native clean to be less verbose/confusing
[ http://issues.apache.org/jira/browse/HARMONY-174?page=all ] Tim Ellison reassigned HARMONY-174: --- Assign To: Tim Ellison > Change windows native clean to be less verbose/confusing > > > Key: HARMONY-174 > URL: http://issues.apache.org/jira/browse/HARMONY-174 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Assignee: Tim Ellison > Priority: Trivial > Attachments: change.win.del.to.be.more.like.linux.rm.-f > > As discussed on the list. Change delete on windows to be more like "rm -f" > on linux. Will attach the trivial patch. -- 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
[jira] Updated: (HARMONY-187) java.io.ObjectOutputStream.writeUnshared() works incorrectly.
[ http://issues.apache.org/jira/browse/HARMONY-187?page=all ]
Dmitry M. Kononov updated HARMONY-187:
--
Attachment: Test16.java
> java.io.ObjectOutputStream.writeUnshared() works incorrectly.
> -
>
> Key: HARMONY-187
> URL: http://issues.apache.org/jira/browse/HARMONY-187
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Dmitry M. Kononov
> Attachments: Test16.java
>
> Say, we write the same object by the following code:
> Object o = "foobar";
> oos.writeObject(o);
> oos.writeUnshared(o);
> oos.writeObject(o);
> And then, read the written data by the code as follows:
> Object[] oa = new Object[3];
> for (int i = 0; i < oa.length; i++) {
> oa[i] = ois.readObject();
> }
> We expect that:
> 1) the 0th and 1st elements of the array are not equal. That is, oa[0] !=
> oa[1].
> 2) the 1st and 2nd elements of the array are not equal. That is, oa[1] !=
> oa[2].
> 3) the 0th and 2nd elements of the array are equal. That is, oa[0] == oa[2].
> All the three conditions are true if we run a test case in RI:
> oa[0] != oa[1] - true
> oa[1] != oa[2] - true
> oa[0] == oa[2] - true
> When we run the test case in Harmony the first condition is true and the rest
> two are false.
> oa[0] != oa[1] - true
> oa[1] != oa[2] - false
> oa[0] == oa[2] - false
> Here is an excerpt from the spec which shows us that Harmony behaves
> incorrectly:
> "If writeObject is used to write an object that has been previously written
> with writeUnshared, the previous writeUnshared operation is treated as if it
> were a write of a separate object. In other words, ObjectOutputStream will
> never generate back-references to object data written by calls to
> writeUnshared"
> Please note also, that oa[2] should be back-referenced to oa[0].
> I will attach the test case.
--
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
[jira] Created: (HARMONY-187) java.io.ObjectOutputStream.writeUnshared() works incorrectly.
java.io.ObjectOutputStream.writeUnshared() works incorrectly.
-
Key: HARMONY-187
URL: http://issues.apache.org/jira/browse/HARMONY-187
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Dmitry M. Kononov
Say, we write the same object by the following code:
Object o = "foobar";
oos.writeObject(o);
oos.writeUnshared(o);
oos.writeObject(o);
And then, read the written data by the code as follows:
Object[] oa = new Object[3];
for (int i = 0; i < oa.length; i++) {
oa[i] = ois.readObject();
}
We expect that:
1) the 0th and 1st elements of the array are not equal. That is, oa[0] != oa[1].
2) the 1st and 2nd elements of the array are not equal. That is, oa[1] != oa[2].
3) the 0th and 2nd elements of the array are equal. That is, oa[0] == oa[2].
All the three conditions are true if we run a test case in RI:
oa[0] != oa[1] - true
oa[1] != oa[2] - true
oa[0] == oa[2] - true
When we run the test case in Harmony the first condition is true and the rest
two are false.
oa[0] != oa[1] - true
oa[1] != oa[2] - false
oa[0] == oa[2] - false
Here is an excerpt from the spec which shows us that Harmony behaves
incorrectly:
"If writeObject is used to write an object that has been previously written
with writeUnshared, the previous writeUnshared operation is treated as if it
were a write of a separate object. In other words, ObjectOutputStream will
never generate back-references to object data written by calls to writeUnshared"
Please note also, that oa[2] should be back-referenced to oa[0].
I will attach the test case.
--
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
[jira] Resolved: (HARMONY-178) java.text.DateFormat$Field's contructor may replace predefined consts with new value in cache
[ http://issues.apache.org/jira/browse/HARMONY-178?page=all ]
Tim Ellison resolved HARMONY-178:
-
Resolution: Fixed
Paulex,
Thanks for the patches. I added a copyright statement to the test and updated
the test suite.
Applied to TEXT module java.text.DateFormat at repo revision 383878.
Please check that the patch was applied as you expected.
> java.text.DateFormat$Field's contructor may replace predefined consts with
> new value in cache
> -
>
> Key: HARMONY-178
> URL: http://issues.apache.org/jira/browse/HARMONY-178
> Project: Harmony
> Type: Bug
> Reporter: Paulex Yang
> Assignee: Tim Ellison
> Attachments: java.text.DateFormat.patch, java.text.DateFormatFieldTest.patch
>
> DataFormat$Field will cache some constants to be searched by method
> ofCalendarField(int), but the predefined consts should not be replaced.
> the testcases is as below:
> import java.text.DateFormat;
> import java.util.Calendar;
> import junit.framework.TestCase;
> public class DataFormatFieldTest extends TestCase{
> public void test_Constructor2() {
> MyField field = new MyField("day of month", Calendar.ERA);
> DateFormat.Field realField = DateFormat.Field
> .ofCalendarField(Calendar.ERA);
> assertSame("Modified calendar field with the same field number",
> DateFormat.Field.ERA, realField);
> }
> static class MyField extends DateFormat.Field {
> protected MyField(String fieldName, int calendarField) {
> super(fieldName, calendarField);
> }
> protected String getName() {
> return super.getName();
> }
> }
> }
> Run on RI 5.0, test case passes.
> Run on Harmony, test case fail with message:
> junit.framework.AssertionFailedError: Modified calendar field with the same
> field number expected same: was
> not:
>
--
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
[jira] Assigned: (HARMONY-178) java.text.DateFormat$Field's contructor may replace predefined consts with new value in cache
[ http://issues.apache.org/jira/browse/HARMONY-178?page=all ]
Tim Ellison reassigned HARMONY-178:
---
Assign To: Tim Ellison
> java.text.DateFormat$Field's contructor may replace predefined consts with
> new value in cache
> -
>
> Key: HARMONY-178
> URL: http://issues.apache.org/jira/browse/HARMONY-178
> Project: Harmony
> Type: Bug
> Reporter: Paulex Yang
> Assignee: Tim Ellison
> Attachments: java.text.DateFormat.patch, java.text.DateFormatFieldTest.patch
>
> DataFormat$Field will cache some constants to be searched by method
> ofCalendarField(int), but the predefined consts should not be replaced.
> the testcases is as below:
> import java.text.DateFormat;
> import java.util.Calendar;
> import junit.framework.TestCase;
> public class DataFormatFieldTest extends TestCase{
> public void test_Constructor2() {
> MyField field = new MyField("day of month", Calendar.ERA);
> DateFormat.Field realField = DateFormat.Field
> .ofCalendarField(Calendar.ERA);
> assertSame("Modified calendar field with the same field number",
> DateFormat.Field.ERA, realField);
> }
> static class MyField extends DateFormat.Field {
> protected MyField(String fieldName, int calendarField) {
> super(fieldName, calendarField);
> }
> protected String getName() {
> return super.getName();
> }
> }
> }
> Run on RI 5.0, test case passes.
> Run on Harmony, test case fail with message:
> junit.framework.AssertionFailedError: Modified calendar field with the same
> field number expected same: was
> not:
>
--
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
[jira] Resolved: (HARMONY-170) java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception
[ http://issues.apache.org/jira/browse/HARMONY-170?page=all ] Tim Ellison resolved HARMONY-170: - Resolution: Fixed Thanks Richard, That was as exemplary JIRA report -- a patch for the code and test suite, and following the conventions! It made the task of checking and applying the patch very easy, thank you! Applied to NIO_CHAR module java.nio.charset.CharsetEncoder at repo revision 383871 . Please check that the patch was applied as you expected. > java.nio.charset.CharsetEncoder.encode method does not handle the unexpected > exception > -- > > Key: HARMONY-170 > URL: http://issues.apache.org/jira/browse/HARMONY-170 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Richard Liang > Assignee: Tim Ellison > Attachments: CharsetEncoderTest_patch.txt, CharsetEncoder_patch.txt > > public final CoderResult encode(CharBuffer in, ByteBuffer out, boolean > endOfInput) > As spec says, the method throws CoderMalfunctionError if an invocation of the > decodeLoop method threw an unexpected exception. > However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method > threw an unexpected exception. > The attached test cases pass on RI , but fail on Harmony. -- 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
[jira] Assigned: (HARMONY-170) java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception
[ http://issues.apache.org/jira/browse/HARMONY-170?page=all ] Tim Ellison reassigned HARMONY-170: --- Assign To: Tim Ellison > java.nio.charset.CharsetEncoder.encode method does not handle the unexpected > exception > -- > > Key: HARMONY-170 > URL: http://issues.apache.org/jira/browse/HARMONY-170 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Richard Liang > Assignee: Tim Ellison > Attachments: CharsetEncoderTest_patch.txt, CharsetEncoder_patch.txt > > public final CoderResult encode(CharBuffer in, ByteBuffer out, boolean > endOfInput) > As spec says, the method throws CoderMalfunctionError if an invocation of the > decodeLoop method threw an unexpected exception. > However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method > threw an unexpected exception. > The attached test cases pass on RI , but fail on Harmony. -- 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
[jira] Commented: (HARMONY-172) Harmony text component has some API difference with JSE 5 spec
[ http://issues.apache.org/jira/browse/HARMONY-172?page=comments#action_12369220 ] Tim Ellison commented on HARMONY-172: - Paulex, I thought the decision was to implement the BreakIterator methods to do the 'obvious' thing? I've put in the NotYetImplemented versions anyway to get the signature check. Please can you provide regression tests? Thanks > Harmony text component has some API difference with JSE 5 spec > -- > > Key: HARMONY-172 > URL: http://issues.apache.org/jira/browse/HARMONY-172 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Paulex Yang > Assignee: Tim Ellison > Priority: Minor > Attachments: java.text.BreakIterator.patch, java.text.NumberFormat.patch > > Three new methods added to java.text.BreakIterator > method java.text.BreakIterator.getInt(byte[], int) > method java.text.BreakIterator.getLong(byte[], int) > method java.text.BreakIterator.getShort(byte[], int) > One method signature difference in java.text.NumberFormat > java/text/NumberFormat format(Object, StringBuffer,FieldPosition) should not > be final -- 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
[jira] Resolved: (HARMONY-149) java.nio.charset.Charset.forName(name) return different reference value when requiring the same Charset.
[ http://issues.apache.org/jira/browse/HARMONY-149?page=all ]
Tim Ellison resolved HARMONY-149:
-
Resolution: Fixed
Richard,
Fixed in NIO_CHAR module java.nio.charset.Charset at repo revision 383867.
Take a look at how I changed the test case to fit in with the test naming
convention.
Please check that the patch was applied as you expected.
> java.nio.charset.Charset.forName(name) return different reference value when
> requiring the same Charset.
>
>
> Key: HARMONY-149
> URL: http://issues.apache.org/jira/browse/HARMONY-149
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: Charset_patch_149.txt
>
> java.nio.charset.Charset.forName(name) returns different reference value when
> requiring the same Charset.
> However, RI always returns the same reference for the same Charset, no matter
> using "alias" or "canonical" name as parameter.
> RI 5.0 passes the following test case, while Harmony fails.
> === Test case
> /*
>* test forName: invoke forName two times with the same canonical name,
>* it should return the same reference.
>*/
> public void testForName_TwoSameRef1(){
> Charset cs1 = Charset.forName("UTF-8");
> Charset cs2 = Charset.forName("UTF-8");
> assertSame(cs1,cs2);
> }
>
> /*
>* test forName: invoke forName two times for the same Charset using
> canonical name and alias,
>* it should return the same reference.
>*/
> public void testForName_TwoSameRef2(){
> Charset cs1 = Charset.forName("ASCII");
> Charset cs2 = Charset.forName("US-ASCII");
> assertSame(cs1,cs2);
> }
--
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
[jira] Assigned: (HARMONY-172) Harmony text component has some API difference with JSE 5 spec
[ http://issues.apache.org/jira/browse/HARMONY-172?page=all ] Tim Ellison reassigned HARMONY-172: --- Assign To: Tim Ellison > Harmony text component has some API difference with JSE 5 spec > -- > > Key: HARMONY-172 > URL: http://issues.apache.org/jira/browse/HARMONY-172 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Paulex Yang > Assignee: Tim Ellison > Priority: Minor > Attachments: java.text.BreakIterator.patch, java.text.NumberFormat.patch > > Three new methods added to java.text.BreakIterator > method java.text.BreakIterator.getInt(byte[], int) > method java.text.BreakIterator.getLong(byte[], int) > method java.text.BreakIterator.getShort(byte[], int) > One method signature difference in java.text.NumberFormat > java/text/NumberFormat format(Object, StringBuffer,FieldPosition) should not > be final -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ITC's Contribution
> Daniel Gandara wrote: > >>> c) Some still missing components... > >>> we have checked some pre-conditions before making this announcement and > >>> we found that there are some components we need (i.e.: concurrent) > >>> which > >>> are not on Harmony yet. Is someone working on those missing > >>> components? > > > >> I'm not sure. We were thinking about using Doug Lea's to start. > >> > >> Are you working on that now? > >> > > > > No, we are not working on concurrent component. We use concurrent at > > java.rmi package, so it is one of the missing requisite for our > > implementation to work; the other big one is 1.5 :) > > I expect that Geir meant, "does your code work with Doug Lea's > concurrent utils now" (and if he didn't I'll ask the question anyway!) ok. Geir: sorry if I missunderstood you :) > > i.e. have you tried running it with the original code (EDU.oswego.cs.dl) > from Doug's website or only the concurrent utils in 5.0 (JSR166)? > we have only tried with the concurrent utils in 5.0, but we will try with Doug's and see how it behaves, I'll let you know. Regards, Daniel
[jira] Assigned: (HARMONY-149) java.nio.charset.Charset.forName(name) return different reference value when requiring the same Charset.
[ http://issues.apache.org/jira/browse/HARMONY-149?page=all ]
Tim Ellison reassigned HARMONY-149:
---
Assign To: Tim Ellison
> java.nio.charset.Charset.forName(name) return different reference value when
> requiring the same Charset.
>
>
> Key: HARMONY-149
> URL: http://issues.apache.org/jira/browse/HARMONY-149
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: Charset_patch_149.txt
>
> java.nio.charset.Charset.forName(name) returns different reference value when
> requiring the same Charset.
> However, RI always returns the same reference for the same Charset, no matter
> using "alias" or "canonical" name as parameter.
> RI 5.0 passes the following test case, while Harmony fails.
> === Test case
> /*
>* test forName: invoke forName two times with the same canonical name,
>* it should return the same reference.
>*/
> public void testForName_TwoSameRef1(){
> Charset cs1 = Charset.forName("UTF-8");
> Charset cs2 = Charset.forName("UTF-8");
> assertSame(cs1,cs2);
> }
>
> /*
>* test forName: invoke forName two times for the same Charset using
> canonical name and alias,
>* it should return the same reference.
>*/
> public void testForName_TwoSameRef2(){
> Charset cs1 = Charset.forName("ASCII");
> Charset cs2 = Charset.forName("US-ASCII");
> assertSame(cs1,cs2);
> }
--
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
[jira] Commented: (HARMONY-148) java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't preserve replace string for successive decode invocation while "out" doesn't have engouh space
[
http://issues.apache.org/jira/browse/HARMONY-148?page=comments#action_12369217
]
Tim Ellison commented on HARMONY-148:
-
Richard,
Fix applied to NIO_CHAR module java.nio.charset.CharsetDecoder at repo revision
383862.
Please can you provide your tests as a patch? thanks.
> java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't
> preserve replace string for successive decode invocation while "out" doesn't
> have engouh space for replace string.
>
>
> Key: HARMONY-148
> URL: http://issues.apache.org/jira/browse/HARMONY-148
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Priority: Minor
> Attachments: CharsetDecoder_patch_148.txt
>
> Consider following senario:
> During the invocation of method
> java.nio.charset.CharsetDecoder.decode(in,out,false), method "decodeLoop"
> returns malformed CoderResult, and the action is set as
> "CodingErrorAction.REPLACE". So replace action should be taken, but "out"
> doesn't hold enough space for the replace string. Therefore,
> CoderResult.OVERFLOW should be returned. Harmony does return OVERFLOW
> currently, but the replace string won't put into new allocated output any
> more. In other words, the replace string is missing from the view of "stream
> decoding". Therefore, replace string should be preserved for successive
> decode(in,out,endOfInput) invacation.
> Both RI5.0 and Harmony fails on the following test case. However, according
> to the spec, we think it is a defect of RI5.0.
> == Test Case==
> /*
>* Test the method decode(ByteBuffer) .
>*/
> public void testDecode_ReplaceOverflow() throws Exception {
> String replaceString = "a";
> Charset cs = Charset.forName("UTF-8");
> MockMalformedDecoder decoder = new MockMalformedDecoder(cs);
> decoder.onMalformedInput(CodingErrorAction.REPLACE);
> decoder.replaceWith(replaceString);
> CharBuffer out = CharBuffer.allocate(1);
> // MockMalformedDecoder treats the second byte '0x38' as
> malformed,
> // but "out" doesn't have enough space for replace string.
> ByteBuffer in = ByteBuffer.wrap(new
> byte[]{0x45,0x38,0x45,0x45});
> CoderResult result = decoder.decode(in,out,false);
> assertTrue(result.isOverflow());
>
> // allocate enough space for "out"
> out = CharBuffer.allocate(10);
> // replace string should be put into "out" firstly,
> // and then decode "in".
> result =decoder.decode(in,out,true);
> out.flip();
> assertTrue(result.isUnderflow());
> assertEquals("abb",out.toString());
> }
> /*
>* Mock decoder. It treats byte whose value is less than "0x40" as
> malformed.
>*/
> static class MockMalformedDecoder extends
> java.nio.charset.CharsetDecoder {
> public MockMalformedDecoder(Charset cs) {
> super(cs, 1, 10);
> }
> /*
>* It treats byte whose value is less than "0x40" as malformed.
>* Otherwise, it's decoded as 'b'.
>*/
> protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
> {
> System.out.println("Using MockMalformedDecoder");
> while (in.hasRemaining()) {
> byte b = in.get();
> if(b < 0x40){
> return
> CoderResult.malformedForLength(1);
> }
> if(!out.hasRemaining()){
> return CoderResult.OVERFLOW;
> }
> out.put((char)'b');
> }
> return CoderResult.UNDERFLOW;
> }
> }
--
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
[jira] Assigned: (HARMONY-148) java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't preserve replace string for successive decode invocation while "out" doesn't have engouh space
[ http://issues.apache.org/jira/browse/HARMONY-148?page=all ]
Tim Ellison reassigned HARMONY-148:
---
Assign To: Tim Ellison
> java.nio.charset.CharsetDecoder: decode(in,out,endOfInput) method doesn't
> preserve replace string for successive decode invocation while "out" doesn't
> have engouh space for replace string.
>
>
> Key: HARMONY-148
> URL: http://issues.apache.org/jira/browse/HARMONY-148
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Priority: Minor
> Attachments: CharsetDecoder_patch_148.txt
>
> Consider following senario:
> During the invocation of method
> java.nio.charset.CharsetDecoder.decode(in,out,false), method "decodeLoop"
> returns malformed CoderResult, and the action is set as
> "CodingErrorAction.REPLACE". So replace action should be taken, but "out"
> doesn't hold enough space for the replace string. Therefore,
> CoderResult.OVERFLOW should be returned. Harmony does return OVERFLOW
> currently, but the replace string won't put into new allocated output any
> more. In other words, the replace string is missing from the view of "stream
> decoding". Therefore, replace string should be preserved for successive
> decode(in,out,endOfInput) invacation.
> Both RI5.0 and Harmony fails on the following test case. However, according
> to the spec, we think it is a defect of RI5.0.
> == Test Case==
> /*
>* Test the method decode(ByteBuffer) .
>*/
> public void testDecode_ReplaceOverflow() throws Exception {
> String replaceString = "a";
> Charset cs = Charset.forName("UTF-8");
> MockMalformedDecoder decoder = new MockMalformedDecoder(cs);
> decoder.onMalformedInput(CodingErrorAction.REPLACE);
> decoder.replaceWith(replaceString);
> CharBuffer out = CharBuffer.allocate(1);
> // MockMalformedDecoder treats the second byte '0x38' as
> malformed,
> // but "out" doesn't have enough space for replace string.
> ByteBuffer in = ByteBuffer.wrap(new
> byte[]{0x45,0x38,0x45,0x45});
> CoderResult result = decoder.decode(in,out,false);
> assertTrue(result.isOverflow());
>
> // allocate enough space for "out"
> out = CharBuffer.allocate(10);
> // replace string should be put into "out" firstly,
> // and then decode "in".
> result =decoder.decode(in,out,true);
> out.flip();
> assertTrue(result.isUnderflow());
> assertEquals("abb",out.toString());
> }
> /*
>* Mock decoder. It treats byte whose value is less than "0x40" as
> malformed.
>*/
> static class MockMalformedDecoder extends
> java.nio.charset.CharsetDecoder {
> public MockMalformedDecoder(Charset cs) {
> super(cs, 1, 10);
> }
> /*
>* It treats byte whose value is less than "0x40" as malformed.
>* Otherwise, it's decoded as 'b'.
>*/
> protected CoderResult decodeLoop(ByteBuffer in, CharBuffer out)
> {
> System.out.println("Using MockMalformedDecoder");
> while (in.hasRemaining()) {
> byte b = in.get();
> if(b < 0x40){
> return
> CoderResult.malformedForLength(1);
> }
> if(!out.hasRemaining()){
> return CoderResult.OVERFLOW;
> }
> out.put((char)'b');
> }
> return CoderResult.UNDERFLOW;
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: How to deal with this kind of serialization compatibility issue?
The problem is serial form contains class name "sun.foo"
and if you deal with "o.a.h.foo" then serialization framework
will never know that you class's readObject() is to be invoked.
Another option is provide 'pairs' to ObjectInputStream.readObject():
for each 'foo' method it will know what is the corresponding harmony
class.
Thanks,
Mikhail
2006/3/7, George Harley <[EMAIL PROTECTED]>:
> Mikhail Loenko wrote:
> > George,
> >
> > 2006/3/7, George Harley <[EMAIL PROTECTED]>:
> >
> >> Paulex Yang wrote:
> >>
> >>> This kind of serialization compatibility issue may be found again
> >>> later, if only RI use some non-API class as default implementation of
> >>> serializable abstract class. So I think we need some discussion on
> >>> this issue for a principle.
> >>>
> >>> I propose two choice:
> >>> 1. just let it be
> >>> 2. mimic a class as RI, in this TimeZone case, create a
> >>> sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
> >>> works but risky and ugly, it is risky because RI may change the
> >>> implementation class later(which will also break RI's serialization
> >>> compatibility of course)
> >>>
> >>> comments?
> >>>
> >> Hi Paulex,
> >>
> >> When such RI->Harmony serialization incompatibilities come to light we
> >> can aim to deal with it in readObject() methods added to the affected
> >>
> >
> > It is not quite clear, in which class you are going to deal with
> > readObject() ?
> >
> > Are you suggesting modification of IO framework that does serialization?
> >
> > Thanks,
> > Mikhail
> >
> >
>
> Hi Mikhail,
>
> I mean the "private void readObject(ObjectInputStream os)" method that
> every type implementing the Serializable interface can contain to
> provide customised de-serialization.
>
> Best regards,
> George
>
> >> types. This will have to be done on a case-by-case basis of course. In
> >> this particular case I could imagine that we could catch that
> >> ClassNotFoundException in the method and proceed on from there.
> >>
> >> But what about Harmony->RI serialization incompatibilities ? That is,
> >> what about Harmony applications serializing types to files and those
> >> files being later read in by applications running on a RI JRE ? In some
> >> cases we will probably "get away with it" as the differences in
> >> implementation will not break compatibility. For instance, running your
> >> test code so that Harmony produces the .ser file and the RI reads it in
> >> seemed to work fine for me. But the risk of problems will always be
> >> there. I am not certain that writing stubs of sun.* classes is a good
> >> direction to set off in to counter those risks. It would be better to
> >> try and work with the RI providers so that their classes can cope with
> >> serialized Harmony types.
> >>
> >> I wonder what lessons other class library development teams have learned
> >> in this area ?
> >>
> >> Best regards,
> >> George
> >>
> >>
> >>
> >>> Paulex Yang (JIRA) wrote:
> >>>
> java.util.TimeZone's default implementation may cause many classes'
> serialization non-compatible with RI
>
>
>
> Key: HARMONY-184
> URL: http://issues.apache.org/jira/browse/HARMONY-184
> Project: Harmony
> Type: Bug
> Components: Classlib Reporter: Paulex Yang
> Priority: Critical
>
>
> Static factory methods, java.util.TimeZone.getInstance(String) and
> getDefault(), are only ways to get a TimeZone instance, but Harmony
> and RI uses different classes as default implementation, which cause
> serialization non-compatible. Further, all classes whose
> serialization form includes TimeZone won't compatible with RI, too,
> for example, java.util.Calendar(with subclass),
> java.text.DateFormat(with subclass), etc.
>
> But the incompatiblity is hard to be imputed to Harmony, because
> Harmony use API class SimpleTimeZone as default implementation, but
> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
>
> The reproduce procedure:
> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> public void writeObject(){
> TimeZone zone = TimeZone.getTimeZone("GMT");
> ObjectOutputStream ooutput = null;
> try {
> ooutput = new ObjectOutputStream(new
> FileOutputStream("TimeZone.ser"));
> ooutput.writeObject(zone);
> } finally {
> try {
> if (null != ooutput) {
> ooutput.close();
> }
> } catch (Exception e) {
> }
> }
> }
>
> 2. Trying to deserialize this object from file, run codes below
> public void readObject(){
> ObjectInputStream
[jira] Commented: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=comments#action_12369215 ] Mark Hindess commented on HARMONY-92: - Looks good. Thanks Tim. > Suggestion: Move com.ibm.platform from NIO to LUNI > -- > > Key: HARMONY-92 > URL: http://issues.apache.org/jira/browse/HARMONY-92 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Richard Liang > Assignee: Tim Ellison > Attachments: 06.remove-obsolete.sh, new.refactor.tar.gz, > refactor_platform.zip > > Hello Tim, > As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages > com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As > these packages are used by java.net, as well as java.nio.channels. I will > post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to deal with this kind of serialization compatibility issue?
2006/3/7, George Harley <[EMAIL PROTECTED]>:
> I wonder what lessons other class library development teams have learned
> in this area ?
BTW, the problem with serialization of crypto keys (various implementations of
java.security.Key) was resolved in 1.5 by introducing a new class
java.security.KeyRep
I'd say
>> 1. just let it be
Thanks,
Mikhail
>
> Best regards,
> George
>
>
> >
> > Paulex Yang (JIRA) wrote:
> >> java.util.TimeZone's default implementation may cause many classes'
> >> serialization non-compatible with RI
> >>
> >>
> >>
> >> Key: HARMONY-184
> >> URL: http://issues.apache.org/jira/browse/HARMONY-184
> >> Project: Harmony
> >> Type: Bug
> >> Components: Classlib Reporter: Paulex Yang
> >> Priority: Critical
> >>
> >>
> >> Static factory methods, java.util.TimeZone.getInstance(String) and
> >> getDefault(), are only ways to get a TimeZone instance, but Harmony
> >> and RI uses different classes as default implementation, which cause
> >> serialization non-compatible. Further, all classes whose
> >> serialization form includes TimeZone won't compatible with RI, too,
> >> for example, java.util.Calendar(with subclass),
> >> java.text.DateFormat(with subclass), etc.
> >>
> >> But the incompatiblity is hard to be imputed to Harmony, because
> >> Harmony use API class SimpleTimeZone as default implementation, but
> >> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
> >>
> >> The reproduce procedure:
> >> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> >> public void writeObject(){
> >> TimeZone zone = TimeZone.getTimeZone("GMT");
> >> ObjectOutputStream ooutput = null;
> >> try {
> >> ooutput = new ObjectOutputStream(new
> >> FileOutputStream("TimeZone.ser"));
> >> ooutput.writeObject(zone);
> >> } finally {
> >> try {
> >> if (null != ooutput) {
> >> ooutput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> 2. Trying to deserialize this object from file, run codes below
> >> public void readObject(){
> >> ObjectInputStream oinput = null;
> >> try {
> >> oinput = new ObjectInputStream(new
> >> FileInputStream("TimeZone.ser"));
> >> TimeZone newObj = (TimeZone)oinput.readObject();
> >> } finally {
> >> try {
> >> if (null != oinput) {
> >> oinput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> Run in RI, passes without any failure
> >> Run in Harmony, exception throwed as below:
> >> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> >> at java.lang.Class.forName(Class.java:154)
> >> at
> >> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> >> ... ...
> >>
> >>
> >
> >
>
>
Re: How to deal with this kind of serialization compatibility issue?
Mikhail Loenko wrote:
George,
2006/3/7, George Harley <[EMAIL PROTECTED]>:
Paulex Yang wrote:
This kind of serialization compatibility issue may be found again
later, if only RI use some non-API class as default implementation of
serializable abstract class. So I think we need some discussion on
this issue for a principle.
I propose two choice:
1. just let it be
2. mimic a class as RI, in this TimeZone case, create a
sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
works but risky and ugly, it is risky because RI may change the
implementation class later(which will also break RI's serialization
compatibility of course)
comments?
Hi Paulex,
When such RI->Harmony serialization incompatibilities come to light we
can aim to deal with it in readObject() methods added to the affected
It is not quite clear, in which class you are going to deal with readObject() ?
Are you suggesting modification of IO framework that does serialization?
Thanks,
Mikhail
Hi Mikhail,
I mean the "private void readObject(ObjectInputStream os)" method that
every type implementing the Serializable interface can contain to
provide customised de-serialization.
Best regards,
George
types. This will have to be done on a case-by-case basis of course. In
this particular case I could imagine that we could catch that
ClassNotFoundException in the method and proceed on from there.
But what about Harmony->RI serialization incompatibilities ? That is,
what about Harmony applications serializing types to files and those
files being later read in by applications running on a RI JRE ? In some
cases we will probably "get away with it" as the differences in
implementation will not break compatibility. For instance, running your
test code so that Harmony produces the .ser file and the RI reads it in
seemed to work fine for me. But the risk of problems will always be
there. I am not certain that writing stubs of sun.* classes is a good
direction to set off in to counter those risks. It would be better to
try and work with the RI providers so that their classes can cope with
serialized Harmony types.
I wonder what lessons other class library development teams have learned
in this area ?
Best regards,
George
Paulex Yang (JIRA) wrote:
java.util.TimeZone's default implementation may cause many classes'
serialization non-compatible with RI
Key: HARMONY-184
URL: http://issues.apache.org/jira/browse/HARMONY-184
Project: Harmony
Type: Bug
Components: Classlib Reporter: Paulex Yang
Priority: Critical
Static factory methods, java.util.TimeZone.getInstance(String) and
getDefault(), are only ways to get a TimeZone instance, but Harmony
and RI uses different classes as default implementation, which cause
serialization non-compatible. Further, all classes whose
serialization form includes TimeZone won't compatible with RI, too,
for example, java.util.Calendar(with subclass),
java.text.DateFormat(with subclass), etc.
But the incompatiblity is hard to be imputed to Harmony, because
Harmony use API class SimpleTimeZone as default implementation, but
RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
The reproduce procedure:
1. To serialize TimeZone object to a file in RI, run codes below in RI
public void writeObject(){
TimeZone zone = TimeZone.getTimeZone("GMT");
ObjectOutputStream ooutput = null;
try {
ooutput = new ObjectOutputStream(new
FileOutputStream("TimeZone.ser"));
ooutput.writeObject(zone);
} finally {
try {
if (null != ooutput) {
ooutput.close();
}
} catch (Exception e) {
}
}
}
2. Trying to deserialize this object from file, run codes below
public void readObject(){
ObjectInputStream oinput = null;
try {
oinput = new ObjectInputStream(new
FileInputStream("TimeZone.ser"));
TimeZone newObj = (TimeZone)oinput.readObject();
} finally {
try {
if (null != oinput) {
oinput.close();
}
} catch (Exception e) {
}
}
}
Run in RI, passes without any failure
Run in Harmony, exception throwed as below:
java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
at java.lang.Class.forName(Class.java:154)
at
java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
... ...
[jira] Closed: (HARMONY-153) mark deprecated API
[ http://issues.apache.org/jira/browse/HARMONY-153?page=all ] Tim Ellison closed HARMONY-153: --- Verified by Mikhail > mark deprecated API > --- > > Key: HARMONY-153 > URL: http://issues.apache.org/jira/browse/HARMONY-153 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mikhail Loenko > Assignee: Tim Ellison > Priority: Minor > Attachments: deprecated.txt > > As agreed on the mailing list deprecated classes, methods, etc should be > marked > I'm going to provide a patch shortly -- 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
[jira] Resolved: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=all ] Tim Ellison resolved HARMONY-92: Resolution: Fixed Mark / Richard, Thanks for the patches & instructions. The 'platform' code has been moved from NIO to LUNI at repo revision 383849. Please check that the patches were applied as you expected. > Suggestion: Move com.ibm.platform from NIO to LUNI > -- > > Key: HARMONY-92 > URL: http://issues.apache.org/jira/browse/HARMONY-92 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Richard Liang > Assignee: Tim Ellison > Attachments: 06.remove-obsolete.sh, new.refactor.tar.gz, > refactor_platform.zip > > Hello Tim, > As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages > com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As > these packages are used by java.net, as well as java.nio.channels. I will > post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to deal with this kind of serialization compatibility issue?
George,
2006/3/7, George Harley <[EMAIL PROTECTED]>:
> Paulex Yang wrote:
> > This kind of serialization compatibility issue may be found again
> > later, if only RI use some non-API class as default implementation of
> > serializable abstract class. So I think we need some discussion on
> > this issue for a principle.
> >
> > I propose two choice:
> > 1. just let it be
> > 2. mimic a class as RI, in this TimeZone case, create a
> > sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
> > works but risky and ugly, it is risky because RI may change the
> > implementation class later(which will also break RI's serialization
> > compatibility of course)
> >
> > comments?
>
> Hi Paulex,
>
> When such RI->Harmony serialization incompatibilities come to light we
> can aim to deal with it in readObject() methods added to the affected
It is not quite clear, in which class you are going to deal with readObject() ?
Are you suggesting modification of IO framework that does serialization?
Thanks,
Mikhail
> types. This will have to be done on a case-by-case basis of course. In
> this particular case I could imagine that we could catch that
> ClassNotFoundException in the method and proceed on from there.
>
> But what about Harmony->RI serialization incompatibilities ? That is,
> what about Harmony applications serializing types to files and those
> files being later read in by applications running on a RI JRE ? In some
> cases we will probably "get away with it" as the differences in
> implementation will not break compatibility. For instance, running your
> test code so that Harmony produces the .ser file and the RI reads it in
> seemed to work fine for me. But the risk of problems will always be
> there. I am not certain that writing stubs of sun.* classes is a good
> direction to set off in to counter those risks. It would be better to
> try and work with the RI providers so that their classes can cope with
> serialized Harmony types.
>
> I wonder what lessons other class library development teams have learned
> in this area ?
>
> Best regards,
> George
>
>
> >
> > Paulex Yang (JIRA) wrote:
> >> java.util.TimeZone's default implementation may cause many classes'
> >> serialization non-compatible with RI
> >>
> >>
> >>
> >> Key: HARMONY-184
> >> URL: http://issues.apache.org/jira/browse/HARMONY-184
> >> Project: Harmony
> >> Type: Bug
> >> Components: Classlib Reporter: Paulex Yang
> >> Priority: Critical
> >>
> >>
> >> Static factory methods, java.util.TimeZone.getInstance(String) and
> >> getDefault(), are only ways to get a TimeZone instance, but Harmony
> >> and RI uses different classes as default implementation, which cause
> >> serialization non-compatible. Further, all classes whose
> >> serialization form includes TimeZone won't compatible with RI, too,
> >> for example, java.util.Calendar(with subclass),
> >> java.text.DateFormat(with subclass), etc.
> >>
> >> But the incompatiblity is hard to be imputed to Harmony, because
> >> Harmony use API class SimpleTimeZone as default implementation, but
> >> RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
> >>
> >> The reproduce procedure:
> >> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> >> public void writeObject(){
> >> TimeZone zone = TimeZone.getTimeZone("GMT");
> >> ObjectOutputStream ooutput = null;
> >> try {
> >> ooutput = new ObjectOutputStream(new
> >> FileOutputStream("TimeZone.ser"));
> >> ooutput.writeObject(zone);
> >> } finally {
> >> try {
> >> if (null != ooutput) {
> >> ooutput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> 2. Trying to deserialize this object from file, run codes below
> >> public void readObject(){
> >> ObjectInputStream oinput = null;
> >> try {
> >> oinput = new ObjectInputStream(new
> >> FileInputStream("TimeZone.ser"));
> >> TimeZone newObj = (TimeZone)oinput.readObject();
> >> } finally {
> >> try {
> >> if (null != oinput) {
> >> oinput.close();
> >> }
> >> } catch (Exception e) {
> >> }
> >> }
> >> }
> >>
> >> Run in RI, passes without any failure
> >> Run in Harmony, exception throwed as below:
> >> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> >> at java.lang.Class.forName(Class.java:154)
> >> at
> >> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> >> ... ...
> >>
> >>
> >
> >
>
>
Re: J2SE 5 Plan / Roadmap
On Mon, Mar 06, 2006 at 09:21:38PM -0600, Nathan Beyer wrote: > Alright, more specifically a char is no longer guaranteed to be a single > Unicode character, but rather two bytes of a UTF-16 sequence. That wasn't the case before either. Some character representations can only reasonably be converted to unicode using several code points, and in that case there is nothing Java can do to 'compress' the character to a single code point, since such a code point does not exist in unicode. cheers, dalibor topic > > -Original Message- > From: Richard Liang [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 8:10 PM > To: harmony-dev@incubator.apache.org > Subject: Re: J2SE 5 Plan / Roadmap > > Nathan Beyer wrote: > > Maybe I didn't read this article right, but my understanding is that in > Java > > 5, char or at least an array of char is considered a UTF-16 sequence: > > http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ > > > Yes, Nathan. Char sequence and char array are considered as UTF-16 > sequence. But as a data type, 'char' cannot be UTF-16. How can you > assign a char as a Unicode character U+10? > > Here's the important quote from this article: > > > > "In the end, the decision was for a tiered approach: > > * Use the primitive type int to represent code points in low-level > APIs, > > such as the static methods of the Character class. > > * Interpret char sequences in all forms as UTF-16 sequences, and > promote > > their use in higher-level APIs. > > * Provide APIs to easily convert between various char and code > > point-based representations." > > > > > > > > -Original Message- > > From: Richard Liang [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 06, 2006 7:34 PM > > To: harmony-dev@incubator.apache.org > > Subject: Re: J2SE 5 Plan / Roadmap > > > > Nathan Beyer wrote: > > > >> Here's a good link with a summary of some of the new features: > >> http://java.sun.com/developer/technicalArticles/releases/j2se15/ > >> > >> One of the major pieces that I missed is uplifting everything to support > >> > > the > > > >> Unicode 4.0 updates; char is now UTF-16 encoded value, etc. > >> > >> > > 'char' cannot be UTF-16 encoded value :-) As you know, char is 16-bit > > value in Java. However, UTF-16 encoding algorithm is: > > For characters in range U+ - U+ (excluding U+D800 - U+DFFF) just > > use the same unsigned 16-bit numeric value as their UTF-16 encoded > > value; For example, the UTF-16 encoded value for character '\u4E2D' is > > 0x4E2D. > > For characters in U+1 - U+10 use a surrogate pair as their > > UTF-16 encoded value. For example, the UTF-16 encoded value for > > character U+1 is a 32-bit value 0xD800 0xDC00. > > > > Please refer to "Glossary of Unicode Terms" > http://www.unicode.org/glossary/ > > > > Also please forgive my prolixity :-) > > > >> > >> > >>> -Original Message- > >>> From: Nathan Beyer [mailto:[EMAIL PROTECTED] > >>> Sent: Friday, March 03, 2006 6:19 PM > >>> To: harmony-dev@incubator.apache.org > >>> Subject: RE: J2SE 5 Plan / Roadmap > >>> > >>> This can probably be split up into a couple pieces; here are some of my > >>> thoughts. > >>> > >>> * JLS3 bytecode support - Can the current VM load JLS3 class files? If > >>> not, > >>> what's missing (besides the major.minor version header)? Can some > >>> > > features > > > >>> be enabled/uplifted to allow APIs to move forward? Since generics are a > >>> compile-time feature, can code begin using generics by just allowing the > >>> JLS3 major.minor version? In any case, this probably breaks down into a > >>> couple topics: generics, annotations, enums, return-value-covariance and > >>> others. > >>> > >>> * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified > >>> (java.lang.management, etc) and some are already being checked in. It > >>> seems > >>> like there's already a undocumented process here, which is to uplift and > >>> build any APIs to the Java 5 specification and leaving out any Java > >>> 5-specific language features, like generification, enums and > annotations. > >>> > >>> * Java 5 APIs [Generfication] - Once we can allow code with generics to > >>> > > be > > > >>> compiled and loaded, then we could begin a phase of uplifting all of the > >>> newly generified APIs (Collections, etc). > >>> > >>> * Java 5 APIs [Annotations] - I suspect, but could be wrong, that > >>> Annotations support will be more difficult to implement in the VM, as > >>> there > >>> is some runtime support. When this is available, another phase can be > >>> initiated to uplift all of the APIs with the appropriate Annotations > >>> (@deprecated, @override, etc). > >>> > >>> I'm not too familiar with the JAPI tool, but if Stuart can get the > >>> > > Harmony > > > >>> reports to run against the Java 5 specifications, I this would provide > an > >>> enormous boost in the arena
[jira] Assigned: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=all ] Tim Ellison reassigned HARMONY-92: -- Assign To: Tim Ellison > Suggestion: Move com.ibm.platform from NIO to LUNI > -- > > Key: HARMONY-92 > URL: http://issues.apache.org/jira/browse/HARMONY-92 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Richard Liang > Assignee: Tim Ellison > Attachments: 06.remove-obsolete.sh, new.refactor.tar.gz, > refactor_platform.zip > > Hello Tim, > As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages > com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As > these packages are used by java.net, as well as java.nio.channels. I will > post the proposed fix soon :-) -- 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
[jira] Closed: (HARMONY-73) java.net.InetAddress.getLocalHost() returns wrong host name for loopback address
[ http://issues.apache.org/jira/browse/HARMONY-73?page=all ]
Tim Ellison closed HARMONY-73:
--
Verified by Svetlana
> java.net.InetAddress.getLocalHost() returns wrong host name for loopback
> address
> -
>
> Key: HARMONY-73
> URL: http://issues.apache.org/jira/browse/HARMONY-73
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Priority: Minor
> Attachments: InetAddress.patch
>
> J2se 1.4.2 and 5.0 specifications for java.net.InetAddress.getLocalHost()
> read, that if there is a security manager, its checkConnect method is called
> with the local host name and -1 as its arguments to see if the operation is
> allowed.
> If the operation is not allowed, an InetAddress representing the loopback
> address is returned as hostname/hostaddress (as followed from toString()
> specification).
> The test listed below shows that the returned loopback address has wrong
> hostname, "127.0.0.1" instead of "loopback".
> Inet_SecurityManager class is called twice and therefore host name is
> substituted with hostaddress address.
> Code to reproduce:
> import java.net.*;
> public class test2 {
> public static void main(String[] args) {
> try {
> System.setSecurityManager(new Inet_SecurityManager());
> System.out.println("Loopback address = " +
> InetAddress.getLocalHost());
> } catch (Exception e){
> System.out.println("Unexpected exception = " + e);
> };
> }
> }
> class Inet_SecurityManager extends SecurityManager {
> public void checkConnect(String host, int port) {
> super.checkConnect(host,port);
> throw new SecurityException();
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> 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)
> Inet_SecurityManager :host= nswssamoil1
> Inet_SecurityManager :port= -1
> Loopback address = localhost/127.0.0.1
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> Inet_SecurityManager :host= nswssamoil1
> Inet_SecurityManager :port= -1
> Inet_SecurityManager :host= localhost
> Inet_SecurityManager :port= -1
> Loopback address = 127.0.0.1/127.0.0.1
> Suggested junit test case:
> InetAddressTest.java
> -
> import java.net.*;
> import junit.framework.*;
> public class InetAddressTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(InetAddress.class);
> }
> public void test_getLocalHost() {
> try{
> System.setSecurityManager(new Inet_SecurityManager());
> String hostname=InetAddress.getLocalHost().getHostName();
>
> assertEquals("localhost", hostname);
> } catch (Exception e){
> fail("Unexpected exception = " + e);
> };
>}
> }
> class Inet_SecurityManager extends SecurityManager {
> public void checkConnect(String host, int port) {
> super.checkConnect(host,port);
> throw new SecurityException();
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: How to deal with this kind of serialization compatibility issue?
Paulex Yang wrote:
This kind of serialization compatibility issue may be found again
later, if only RI use some non-API class as default implementation of
serializable abstract class. So I think we need some discussion on
this issue for a principle.
I propose two choice:
1. just let it be
2. mimic a class as RI, in this TimeZone case, create a
sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
works but risky and ugly, it is risky because RI may change the
implementation class later(which will also break RI's serialization
compatibility of course)
comments?
Hi Paulex,
When such RI->Harmony serialization incompatibilities come to light we
can aim to deal with it in readObject() methods added to the affected
types. This will have to be done on a case-by-case basis of course. In
this particular case I could imagine that we could catch that
ClassNotFoundException in the method and proceed on from there.
But what about Harmony->RI serialization incompatibilities ? That is,
what about Harmony applications serializing types to files and those
files being later read in by applications running on a RI JRE ? In some
cases we will probably "get away with it" as the differences in
implementation will not break compatibility. For instance, running your
test code so that Harmony produces the .ser file and the RI reads it in
seemed to work fine for me. But the risk of problems will always be
there. I am not certain that writing stubs of sun.* classes is a good
direction to set off in to counter those risks. It would be better to
try and work with the RI providers so that their classes can cope with
serialized Harmony types.
I wonder what lessons other class library development teams have learned
in this area ?
Best regards,
George
Paulex Yang (JIRA) wrote:
java.util.TimeZone's default implementation may cause many classes'
serialization non-compatible with RI
Key: HARMONY-184
URL: http://issues.apache.org/jira/browse/HARMONY-184
Project: Harmony
Type: Bug
Components: Classlib Reporter: Paulex Yang
Priority: Critical
Static factory methods, java.util.TimeZone.getInstance(String) and
getDefault(), are only ways to get a TimeZone instance, but Harmony
and RI uses different classes as default implementation, which cause
serialization non-compatible. Further, all classes whose
serialization form includes TimeZone won't compatible with RI, too,
for example, java.util.Calendar(with subclass),
java.text.DateFormat(with subclass), etc.
But the incompatiblity is hard to be imputed to Harmony, because
Harmony use API class SimpleTimeZone as default implementation, but
RI use a non-API class, whose full name is sun.util.calendar.ZoneInfo.
The reproduce procedure:
1. To serialize TimeZone object to a file in RI, run codes below in RI
public void writeObject(){
TimeZone zone = TimeZone.getTimeZone("GMT");
ObjectOutputStream ooutput = null;
try {
ooutput = new ObjectOutputStream(new
FileOutputStream("TimeZone.ser"));
ooutput.writeObject(zone);
} finally {
try {
if (null != ooutput) {
ooutput.close();
}
} catch (Exception e) {
}
}
}
2. Trying to deserialize this object from file, run codes below
public void readObject(){
ObjectInputStream oinput = null;
try {
oinput = new ObjectInputStream(new
FileInputStream("TimeZone.ser"));
TimeZone newObj = (TimeZone)oinput.readObject();
} finally {
try {
if (null != oinput) {
oinput.close();
}
} catch (Exception e) {
}
}
}
Run in RI, passes without any failure
Run in Harmony, exception throwed as below:
java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
at java.lang.Class.forName(Class.java:154)
at
java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
... ...
[jira] Closed: (HARMONY-93) some methods in java.util.Collections don't throw NPE when the parameter is null
[ http://issues.apache.org/jira/browse/HARMONY-93?page=all ]
Tim Ellison closed HARMONY-93:
--
Verified by Svetlana
> some methods in java.util.Collections don't throw NPE when the parameter is
> null
> -
>
> Key: HARMONY-93
> URL: http://issues.apache.org/jira/browse/HARMONY-93
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Attachments: CollectionsTest.java, fix.txt
>
> According to j2se 1.4.2 and 1.5 specification for the Collections class "The
> methods of this class all throw a NullPointerException if the collections
> provided to them are null".
> Harmony does not throw NPE for some methods.
> Code to reproduce:
> import java.util.*;
> public class test2 {
> public static void main(String [] args) {
>SortedMap m = null;
>Map map=null;
>Set set=null;
>SortedSet sortedset=null;
>SortedMap sortedmap =null;
>Collection col=null;
>try {
>Collections.synchronizedCollection(col);
>System.out.println("synchronizedCollection(null) must throw
> NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
>Collections.synchronizedSortedMap(sortedmap);
>System.out.println("synchronizedSortedMap(null) must throw
> NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
>Collections.synchronizedMap(map);
>System.out.println("synchronizedMap(map) must throw NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
>Collections.synchronizedSet(set);
>System.out.println("synchronizedSet(set) must throw NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
> Collections.synchronizedSortedSet(sortedset);
> System.out.println("synchronizedSortedSet(null) must throw
> NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
> Collections.unmodifiableCollection(col);
> System.out.println("unmodifiableCollection(null) must throw
> NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
>Collections.unmodifiableMap(map);
>System.out.println("unmodifiableMap(null) must throw NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
>Collections.unmodifiableSet(set);
>System.out.println("unmodifiableSet(null) must throw NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
> Collections.unmodifiableSortedMap(sortedmap);
> System.out.println("unmodifiableSortedMap(null) must throw
> NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
>try {
> Collections.unmodifiableSortedSet(sortedset);
> System.out.println("unmodifiableSortedSet(null) must throw
> NPE");
>} catch (NullPointerException e) {
>System.out.println("PASSED");
>}
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> 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)
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> PASSED
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> synchronizedCollection(null) must throw NPE
> synchronizedSortedMap(null) must throw NPE
> synchronizedMap(map) must throw NPE
> synchronizedSet(set) must throw NPE
> synchronizedSortedSet(null) must throw NPE
> unmodifiableCollection(null) must throw NPE
> unmodifiableMap(null) must throw NPE
> unmo
[jira] Closed: (HARMONY-94) java.util.Collections.binarySearch(List, Object, Comparator c) throws NPE when c is null
[ http://issues.apache.org/jira/browse/HARMONY-94?page=all ]
Tim Ellison closed HARMONY-94:
--
Verified by Svetlana
> java.util.Collections.binarySearch(List, Object, Comparator c) throws NPE
> when c is null
>
>
> Key: HARMONY-94
> URL: http://issues.apache.org/jira/browse/HARMONY-94
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
>
> According to j2se 1.4.2 and 1.5 specification for
> java.util.Collections.binarySearch(List, Object, Comparator c) method null
> value of Comparator c indicates, that the elements' natural ordering should
> be used.
> Harmony throws NPE in this case that contradicts specification.
> Code to reproduce:
> import java.util.*;
> public class test2 {
> public static void main(String args[]){
> LinkedList lst = new LinkedList();
> lst.add(new Integer(30));
> Collections.sort(lst, null);
> int i = Collections.binarySearch(lst, new Integer(2), null);
> System.out.println("Index of search key =" + i);
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> 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)
> Index of search key =-1
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.lang.NullPointerException
> at java.util.Collections.binarySearch(Collections.java:1347)
> at test2.main(test2.java:8)
> Suggected fix:
> Index: trunk/modules/luni/src/main/java/java/util/Collections.java
> ===
> --- trunk/modules/luni/src/main/java/java/util/Collections.java
> (revision 377385)
> +++ trunk/modules/luni/src/main/java/java/util/Collections.java (working
> copy)
> @@ -1340,6 +1340,9 @@
> */
> public static int binarySearch(List list, Object object,
> Comparator comparator) {
> +if ( comparator== null) {
> +return Collections.binarySearch(list, object);
> +}
> if (!(list instanceof RandomAccess)) {
> ListIterator it = list.listIterator();
> while (it.hasNext()) {
>
> Suggested junit test case:
> CollectionsTest.java
> -
> import junit.framework.*;
> import java.util.*;
> public class CollectionsTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(CollectionsTest.class);
> }
> public void test_binarySearch () {
> LinkedList lst = new LinkedList();
> lst.add(new Integer(30));
> Collections.sort(lst, null);
> assertEquals(-1, Collections.binarySearch(lst, new Integer(2), null));
> }
> }
--
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
[jira] Closed: (HARMONY-98) java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected IndexOutOfBoundsException when toIndex=fromIndex
[ http://issues.apache.org/jira/browse/HARMONY-98?page=all ]
Tim Ellison closed HARMONY-98:
--
Verified by Svetlana
> java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected
> IndexOutOfBoundsException when toIndex=fromIndex
>
>
> Key: HARMONY-98
> URL: http://issues.apache.org/jira/browse/HARMONY-98
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Attachments: fix.txt, fix_hrm-98.txt
>
> According to 1.4.2 and 1.5 specification java.util.BitSet.clear(int,int)
> throws IndexOutOfBoundsException - if fromIndex is negative, or toIndex is
> negative, or fromIndex is larger than toIndex.
> Harmony throws IndexOutOfBoundsException if toIndex=fromIndex.
> Code to reproduce:
> import java.util.BitSet;
> public class test2 {
> public static void main(String[] args) {
> BitSet set = new BitSet();
> for(int i=0; i < 20; i++) {
> set.set(i);
> }
>set.clear(10,10);
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> 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)
> PASSED
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.lang.IndexOutOfBoundsException: Negative index specified
> at java.util.BitSet.clear(BitSet.java:423)
> at test2.main(test2.java:16)
> Suggested fix in attachment.
> Suggested junit test case:
> BitSetTest.java
> -
> import junit.framework.*;
> import java.util.BitSet;
> public class BitSetTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(BitSetTest.class);
> }
> public void test_clear() {
>BitSet set = new BitSet();
>for(int i=0; i < 20; i++) {
>set.set(i);
>}
>set.clear(10,10);
> }
> }
--
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
[jira] Closed: (HARMONY-102) java.util.Date.parse(String) throws java.lang.IllegalArgumentException for legal string
[ http://issues.apache.org/jira/browse/HARMONY-102?page=all ]
Tim Ellison closed HARMONY-102:
---
Verified by Svetlana
> java.util.Date.parse(String) throws java.lang.IllegalArgumentException for
> legal string
>
>
> Key: HARMONY-102
> URL: http://issues.apache.org/jira/browse/HARMONY-102
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Attachments: fix102.txt
>
> According to 1.4.2 and 1.5 specifications for java.util.Date(String s)
> IllegalArgumentException is thrown if attempt to interpret the string s as a
> representation of a date and time is fails.
> Harmony throws IllegalArgumentException on legal string: "Sat, 1 Jan 1970
> +0130 00:00:00".
> Code to reproduce:
> import java.util.Date;
> public class test2 {
> public static void main(String[] args) {
> long date = Date.parse("Sat, 1 Jan 1970 +0130 00:00:00");
> System.out.println("date =" + date);
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> 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)
> date =-540
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> java.lang.IllegalArgumentException
> at java.util.Date.parse(Date.java:404)
> at test2.main(test2.java:4)
> Suggested junit test case:
> DateTest.java
> -
> import junit.framework.*;
> import java.util.Date;
> public class DateTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(DateTest.class);
> }
> public void test_parse () {
> assertEquals(-540, Date.parse("Sat, 1 Jan 1970 +0130
> 00:00:00"));
> }
> }
--
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
[jira] Closed: (HARMONY-99) java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw MalformedInputException when buffer's current position is not legal
[ http://issues.apache.org/jira/browse/HARMONY-99?page=all ]
Tim Ellison closed HARMONY-99:
--
Verified by Svetlana
> java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw
> MalformedInputException when buffer's current position is not legal
>
>
> Key: HARMONY-99
> URL: http://issues.apache.org/jira/browse/HARMONY-99
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Svetlana Samoilenko
> Assignee: Tim Ellison
> Attachments: CharsetDecoder_patch.txt
>
> According to 1.4.2 and 1.5 java.nio.charset.CharsetDecoder.decode(ByteBuffer
> in) throws
> MalformedInputException - If the byte sequence starting at the input buffer's
> current position is not legal for this charset and the current
> malformed-input action is CodingErrorAction.REPORT.
> Harmony does not throw MalformedInputException in this case as test listed
> below shows.
> Code to reproduce:
> import java.nio.*;
> import java.nio.charset.*;
> public class test2 {
> public static void main(String[] args) throws Exception {
> Charset cs =Charset.forName("utf-16");
> CharsetDecoder decoder = cs.newDecoder();
> decoder.onMalformedInput(CodingErrorAction.REPORT);
> decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
>
> CharBuffer out = CharBuffer.allocate(10);
> ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
> CharBuffer res1 = decoder.decode(in);
> //output
> System.out.println("CharBuffer=="+res1);
> System.out.println("CharBuffer.position =="+res1.position());
>
> System.out.println("toHexString=="+Integer.toHexString(res1.charAt(0)));
> System.out.println("ByteBuffer.position()=="+in.position());
> System.out.println("ByteBuffer.remaining()=="+in.remaining());
> }
> }
> Steps to Reproduce:
> 1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
> README.txt.
> 2. Compile test2.java using BEA 1.4 javac
> > javac -d . test2.java
> 3. Run java using compatible VM (J9)
> > java -showversion test2
> Output:
> C:\tmp>C:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
> 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)
> java.nio.charset.MalformedInputException: Input length = 1
> at
> java.nio.charset.CoderResult.throwException()V(CoderResult.java:260)
> at
> java.nio.charset.CharsetDecoder.decode(Ljava.nio.ByteBuffer;)Ljava.nio.CharBuffer;(CharsetDecoder.java:763)
> at test2.main([Ljava.lang.String;)V(test2.java:34)
> C:\tmp>C:\harmony\trunk\deploy\jre\bin\java -showversion test2
> (c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
> applicable.
> res1==
> res1==0
> toHexString==6d61
> ByteBuffer.position()==3
> ByteBuffer.remaining()==0
> Suggested junit test case:
> CharsetDecoderTest.java
> -
> import junit.framework.*;
> import java.nio.*;
> import java.nio.charset.*;
> public class CharsetDecoderTest extends TestCase {
> public static void main(String[] args) {
> junit.textui.TestRunner.run(CharsetDecoderTest.class);
> }
> public void test_decode() {
> try {
> Charset cs =Charset.forName("utf-16");
> CharsetDecoder decoder = cs.newDecoder();
> decoder.onMalformedInput(CodingErrorAction.REPORT);
> decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
> CharBuffer out = CharBuffer.allocate(10);
> ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
> CharBuffer res1 = decoder.decode(in);
> fail("MalformedInputException should have thrown");
>} catch (MalformedInputException e) {
>//expected
>} catch (CharacterCodingException e) {
>fail("unexpected CharacterCodingException");
>}
> }
> }
--
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
[jira] Updated: (HARMONY-186) X509CertSelector.match throws ArrayIndexOutOfBoundsException when checks keyUsage criterion
[ http://issues.apache.org/jira/browse/HARMONY-186?page=all ] Stepan Mishura updated HARMONY-186: --- Attachment: fixHarmony186.txt Patch includes bug fix and regression test > X509CertSelector.match throws ArrayIndexOutOfBoundsException when checks > keyUsage criterion > --- > > Key: HARMONY-186 > URL: http://issues.apache.org/jira/browse/HARMONY-186 > Project: Harmony > Type: Bug > Components: Classlib > Reporter: Stepan Mishura > Attachments: fixHarmony186.txt > > According to the spec. of X509Certificate and X509CertSelector classes > KeyUsage extension is represented by array of boolean values. > But the spec. doesn't specify any restrictions on the array so instances of > X509Certificate and X509CertSelector classes may have arrays of different > length to be matched. If a certificate's array is longer then a selector's > array then invocation of method > X509CertSelector.match(java.security.cert.Certificate) throws > ArrayIndexOutOfBoundsException. -- 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
[jira] Created: (HARMONY-186) X509CertSelector.match throws ArrayIndexOutOfBoundsException when checks keyUsage criterion
X509CertSelector.match throws ArrayIndexOutOfBoundsException when checks keyUsage criterion --- Key: HARMONY-186 URL: http://issues.apache.org/jira/browse/HARMONY-186 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura According to the spec. of X509Certificate and X509CertSelector classes KeyUsage extension is represented by array of boolean values. But the spec. doesn't specify any restrictions on the array so instances of X509Certificate and X509CertSelector classes may have arrays of different length to be matched. If a certificate's array is longer then a selector's array then invocation of method X509CertSelector.match(java.security.cert.Certificate) throws ArrayIndexOutOfBoundsException. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: J2SE 5 Plan / Roadmap
You might also want to mention the Memory Model changes that came as part of JSR 133. http://java.sun.com/docs/books/jls/third_edition/html/memory.html --Will Nathan Beyer wrote: Here's a good link with a summary of some of the new features: http://java.sun.com/developer/technicalArticles/releases/j2se15/ One of the major pieces that I missed is uplifting everything to support the Unicode 4.0 updates; char is now UTF-16 encoded value, etc. -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 6:19 PM To: harmony-dev@incubator.apache.org Subject: RE: J2SE 5 Plan / Roadmap This can probably be split up into a couple pieces; here are some of my thoughts. * JLS3 bytecode support - Can the current VM load JLS3 class files? If not, what's missing (besides the major.minor version header)? Can some features be enabled/uplifted to allow APIs to move forward? Since generics are a compile-time feature, can code begin using generics by just allowing the JLS3 major.minor version? In any case, this probably breaks down into a couple topics: generics, annotations, enums, return-value-covariance and others. * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified (java.lang.management, etc) and some are already being checked in. It seems like there's already a undocumented process here, which is to uplift and build any APIs to the Java 5 specification and leaving out any Java 5-specific language features, like generification, enums and annotations. * Java 5 APIs [Generfication] - Once we can allow code with generics to be compiled and loaded, then we could begin a phase of uplifting all of the newly generified APIs (Collections, etc). * Java 5 APIs [Annotations] - I suspect, but could be wrong, that Annotations support will be more difficult to implement in the VM, as there is some runtime support. When this is available, another phase can be initiated to uplift all of the APIs with the appropriate Annotations (@deprecated, @override, etc). I'm not too familiar with the JAPI tool, but if Stuart can get the Harmony reports to run against the Java 5 specifications, I this would provide an enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3 features, like generics, annotations and enum checking? Those are some of my thoughts at least. BTW: JLS3 == Java Language Specification, 3rd Edition -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 9:40 AM To: harmony-dev@incubator.apache.org Subject: J2SE 5 Plan / Roadmap We should probably start thinking about how we'll move forward. There have been a few casual conversations, but lets start getting some things down here.
How to deal with this kind of serialization compatibility issue?
This kind of serialization compatibility issue may be found again later,
if only RI use some non-API class as default implementation of
serializable abstract class. So I think we need some discussion on this
issue for a principle.
I propose two choice:
1. just let it be
2. mimic a class as RI, in this TimeZone case, create a
sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
works but risky and ugly, it is risky because RI may change the
implementation class later(which will also break RI's serialization
compatibility of course)
comments?
Paulex Yang (JIRA) wrote:
java.util.TimeZone's default implementation may cause many classes'
serialization non-compatible with RI
Key: HARMONY-184
URL: http://issues.apache.org/jira/browse/HARMONY-184
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Priority: Critical
Static factory methods, java.util.TimeZone.getInstance(String) and
getDefault(), are only ways to get a TimeZone instance, but Harmony and RI uses
different classes as default implementation, which cause serialization
non-compatible. Further, all classes whose serialization form includes TimeZone
won't compatible with RI, too, for example, java.util.Calendar(with subclass),
java.text.DateFormat(with subclass), etc.
But the incompatiblity is hard to be imputed to Harmony, because Harmony use
API class SimpleTimeZone as default implementation, but RI use a non-API class,
whose full name is sun.util.calendar.ZoneInfo.
The reproduce procedure:
1. To serialize TimeZone object to a file in RI, run codes below in RI
public void writeObject(){
TimeZone zone = TimeZone.getTimeZone("GMT");
ObjectOutputStream ooutput = null;
try {
ooutput = new ObjectOutputStream(new
FileOutputStream("TimeZone.ser"));
ooutput.writeObject(zone);
} finally {
try {
if (null != ooutput) {
ooutput.close();
}
} catch (Exception e) {
}
}
}
2. Trying to deserialize this object from file, run codes below
public void readObject(){
ObjectInputStream oinput = null;
try {
oinput = new ObjectInputStream(new
FileInputStream("TimeZone.ser"));
TimeZone newObj = (TimeZone)oinput.readObject();
} finally {
try {
if (null != oinput) {
oinput.close();
}
} catch (Exception e) {
}
}
}
Run in RI, passes without any failure
Run in Harmony, exception throwed as below:
java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
at java.lang.Class.forName(Class.java:154)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
... ...
--
Paulex Yang
China Software Development Lab
IBM
[jira] Updated: (HARMONY-185) linux native sources use uninitialized variables
[ http://issues.apache.org/jira/browse/HARMONY-185?page=all ] Mark Hindess updated HARMONY-185: - Attachment: avoid.uninitialized.variable.warnings > linux native sources use uninitialized variables > > > Key: HARMONY-185 > URL: http://issues.apache.org/jira/browse/HARMONY-185 > Project: Harmony > Type: Improvement > Components: Classlib > Reporter: Mark Hindess > Priority: Trivial > Attachments: avoid.uninitialized.variable.warnings > > I will attach a patch to fix some of these. (This is part of a broader > attempt to clean up the warnings generated when compiling with 'gcc -Wall'. > Some of them are trivial, some are false positives and some are arguably real > bugs.) -- 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
[jira] Created: (HARMONY-185) linux native sources use uninitialized variables
linux native sources use uninitialized variables Key: HARMONY-185 URL: http://issues.apache.org/jira/browse/HARMONY-185 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Trivial Attachments: avoid.uninitialized.variable.warnings I will attach a patch to fix some of these. (This is part of a broader attempt to clean up the warnings generated when compiling with 'gcc -Wall'. Some of them are trivial, some are false positives and some are arguably real bugs.) -- 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
[jira] Updated: (HARMONY-184) java.util.TimeZone's default implementation may cause many classes' serialization non-compatible with RI
[ http://issues.apache.org/jira/browse/HARMONY-184?page=all ]
Paulex Yang updated HARMONY-184:
Attachment: TimeZone.ser
the serialized file generated by RI is attached.
> java.util.TimeZone's default implementation may cause many classes'
> serialization non-compatible with RI
>
>
> Key: HARMONY-184
> URL: http://issues.apache.org/jira/browse/HARMONY-184
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Paulex Yang
> Priority: Critical
> Attachments: TimeZone.ser
>
> Static factory methods, java.util.TimeZone.getInstance(String) and
> getDefault(), are only ways to get a TimeZone instance, but Harmony and RI
> uses different classes as default implementation, which cause serialization
> non-compatible. Further, all classes whose serialization form includes
> TimeZone won't compatible with RI, too, for example, java.util.Calendar(with
> subclass), java.text.DateFormat(with subclass), etc.
> But the incompatiblity is hard to be imputed to Harmony, because Harmony use
> API class SimpleTimeZone as default implementation, but RI use a non-API
> class, whose full name is sun.util.calendar.ZoneInfo.
> The reproduce procedure:
> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> public void writeObject(){
> TimeZone zone = TimeZone.getTimeZone("GMT");
> ObjectOutputStream ooutput = null;
> try {
> ooutput = new ObjectOutputStream(new
> FileOutputStream("TimeZone.ser"));
> ooutput.writeObject(zone);
> } finally {
> try {
> if (null != ooutput) {
> ooutput.close();
> }
> } catch (Exception e) {
> }
> }
> }
> 2. Trying to deserialize this object from file, run codes below
> public void readObject(){
> ObjectInputStream oinput = null;
> try {
> oinput = new ObjectInputStream(new
> FileInputStream("TimeZone.ser"));
> TimeZone newObj = (TimeZone)oinput.readObject();
> } finally {
> try {
> if (null != oinput) {
> oinput.close();
> }
> } catch (Exception e) {
> }
> }
> }
> Run in RI, passes without any failure
> Run in Harmony, exception throwed as below:
> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> at java.lang.Class.forName(Class.java:154)
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> ... ...
--
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
