RE: [general] platform support
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 10:07 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] platform support (Your post had weird quoting, I've tried to fix it up in my reply) Rana Dasgupta wrote: On 8/9/06, Tim Ellison [EMAIL PROTECTED] wrote: Yes, it is the question you also pose elsewhere -- can we have a binary that either (a) uses the lowest common denominator of the different windows platforms API without incurring an undue penalty performance, or (b) performs runtime checks and picks the best available APIs. There are distinct approaches as I understand it. One option is a single binary image that contains code that supports multiple platforms seperately by doing a dynamic check for platform. Though less pernicious than a least common denominator approach, these runtime checks are not healthy for a binary image that targets performance. So if our ideal platform were XinXP, we would incur a penalty repeatedly when running with it to accomodate the fact that this binary could have also run on W2k. But there are degrees to which this is done too right? Somewhere along the spectrum from a start-up check that chooses between the winxp.dll and win2k.dll, to repeatedly choosing between any number of possible OS function calls. I also thought about the approach of using just separate DLLs with the same external API. At start-up the VM chooses one of them, and then forgets about platform-specific differences. This might be a rather good solution. Regards, Alexey. Oh, and I'm assuming that we are leaving the jitted code out of this. Of course the jit will know what platform it is targeting and can generate the code appropriately. So we are discussing the performance of the interpreter and the compiler itself. The second option is to use a least common denominator approach where we use code/functionality that is only available on the least platform. This is not a good idea for obvious reasons. For example it is not a good idea not to use the excellent vectored exception handling on WinXP and Win2003( which intentionally share the same debug and kernel codebases )If this were not, we would be writing code for DOS only. Again, there may be cases where you may well choose the least common denominator solution because it is 'good enough' and the overhead elsewhere (testing etc.) is not worth the gain found here. Is vectored exception handling a slam dunk case for making the binary winxp only? I don't know -- what would happen if we didn't use it? Where is the example in the current code that makes ensuring it runs on W2K unpalatable? The third is to have a single codebase with the right _WIN32_WINNT guards to distinguish platform specific code, and build seperate distributions for seperate platforms. This is the most performance friendly. It has a building cost, but the major overhead is not building, but testing. If we were to support a platform, we would need to test on it anyway. Agree, so there is a balance to be struck. But I'm guessing from you descriptions that you favour this approach of multiple distributions for different OS releases. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: BASE64Encoder class missing?
On 10/08/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Anthony Green wrote: On Wed, 2006-08-09 at 17:58 -0400, Geir Magnusson Jr wrote: Yes- the idea is to provide that suncompat.jar for that reason with those clases in the sun.* namespace that user apps depend on. This way lies madness. I urge you to take a strong stand against bad applications. Oh, don't get me wrong - we really want to. But we want adoption of the harmony codebase as well. We think that we have a reasonable balance - provide the functionality in an separable, modular way at first to make it easy for people to try and adopt harmony. May I suggest that we try and: 1) Make available a suncompat.jar, which re-writes calls to o.a.h or similar (or subclasses them ...) 2) Explicitly don't make it part of the default classpath ala 'tools.jar' in the standard Sun implementation when running HarmonyVM code 3) Put up a FAQ saying that 'If you depend on e.g. sun.*, stick the suncompat in the classpath' That way, out-of-the-box we don't have it, but there's an easy fix for people who trip up over it. However, if people just need to get it running, then they have a trivial workaround that doesn't involve changing their code. The same could also be provided for code that depends on sun.JavaC or whatever ... Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions found while running servlet...
Martin Cordova wrote:
Is it OK to send this type of feedback to the list? please let me know
if not, and what subject conventions should I use (is there a link
about this?). I am not a Harmony developer, just a new user, I can
only provide feedback from my tests.
Welcome! I think everyone here is eager to see Harmony works with some
real projects well :)
I am running a small webapp, using Winstone servlet engine and IBM JDK
1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4),
and found these exceptions:
1.- I see this error while using servlet includes and also at the end
of some pages:
java.lang.ArrayIndexOutOfBoundsException: 0..0 at
org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194)
at
org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647)
at
org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89)
at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152)
at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at
java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at
java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at
java.io.PrintWriter.doWrite(PrintWriter.java:640) at
java.io.PrintWriter.write(PrintWriter.java:622) at
winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45)
at java.io.PrintWriter.write(PrintWriter.java:607) at
java.io.PrintWriter.write(PrintWriter.java:657) at
java.io.PrintWriter.print(PrintWriter.java:455) at
I've looked into this, I feel puzzled, the stack trace shows that:
org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89)
but there are checks for overflow:
if (0 = offset offset = buffer.length 0 = count
count = buffer.length - offset){
...
}
So can you give more information? e.g, what are PrintWriter try to write
that time? :)
2.- Trying to generate charts using JFreeCharts (server-side):
java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface
at
java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659)
at java.awt.image.BufferedImage.init(BufferedImage.java:352)
at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211)
at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193)
at
org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)...
The JDBC related code is running fine, performance also looks very good.
I will contact Winstone developer to see if he can help in some way to
identify the problem. He already helped me a few months ago to help
identify a bug in GNU Classpath server socket API.
Regards,
Martin
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][pack200] Status update
Mikhail, I believe it is in HARMONY-634. You can read the history on that issue. Regards, Tim Mikhail Loenko wrote: The test still fails. I have not found any file named JustResources* in SVN. The only pack file I've found is HelloWorld.pack Do you remember who has added a JustResources there? Was it a JIRA issue reported by you? Thanks, Mikhail 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Bizzare. I moved it, but it didn't get added. Or at least, I think so. I did discover why the file wasn't included though at my end ... it wasn't part of the change set, so wasn't included in the patch. I've re-generated the patch with it in this time and attached to Harmony-1019 ... is that any better? Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: I believe that the JustResources.pack file was moved to a different location, and so the test was updated to reflect that new location. I saw the same problem myself ... can you confirm that there is a file in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I think that's where the segment ended up. I didn't actually move the file ... someone else did IIRC. Alex. On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: One more problem caused by the patch: java.lang.NullPointerException at org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Thanks, Mikhail 2006/8/10, Mikhail Loenko [EMAIL PROTECTED]: PopulationCodecTest is missing, but there are other new files in the patch. You can see all of them if open the patch with a text editor and seek for (revision 0) substring Thanks, Mikhail 2006/8/9, Alex Blewitt [EMAIL PROTECTED]: Weird. I don't know what happened. I've attached PopulationCodec (a new file) separately to the bug report. There's also BHSDCodec, which is new in the patch, as well as PopulationCodecTest. Are they there too? Alex. On 08/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Alex Thanks for the patch! I have a problem with integration: this classes org.apache.harmony.archive.internal.pack200.CodecEncoding refers to the PopulationCodec class that seems to be missing I'm trying to apply 'patch' [1]. Am I doing anything wrong? Thanks, Mikhail [1] http://issues.apache.org/jira/secure/attachment/12338321/patch 2006/8/8, Alex Blewitt [EMAIL PROTECTED]: I've been getting further towards the Pack200 implementation with finishing off the codecs that are used to decode values from the file. Although most of the default codecs were in place, the pack200 spec allows for dynamic switching to arbitrary codecs should the compressor warrant it, including a population-based encoding for (in)frequent values. I've submitted Harmony 1019 with the patch; if someone could apply that, I'd be grateful. At present, the pack200 algorithm gets as far as the inner class definitions, but I've still got to decode the annotations and bytecode. I'm thinking that as a first-cut, I will ignore any pack files with annotations in and plough through the bytecode so that we can at least start using it for simple pack files. I've got a bit of work left to integrate the dynamic switching of band encodings (but that's OK since most of the simple pack files only use the default) that will involve a bit of refactoring, and essentially then just the bytecode (as long as there are no annotations). I don't think it will be too long before we can unpack simple files on some of the lower-quality settings :-) Also, when I get around to implementing some of the coding (as opposed to decoding), I'm pretty sure that some of the techniques might be useful for compressing arbitrary data streams. It would be interesting to see what other uses there are for the codecs. Onwards, upwards, and/or sideways, Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use :
Re: Re: Re: Re: Re: [classlib][pack200] Status update
Finally it's in! :) 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Don't you just hate it when that happens? :-) On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've found this file in http://issues.apache.org/jira/browse/HARMONY-634 Tim decisded not to commit it as it was not used at the moment I'll check if it solves the problem Thanks, Mikhail 2006/8/10, Mikhail Loenko [EMAIL PROTECTED]: The test still fails. I have not found any file named JustResources* in SVN. The only pack file I've found is HelloWorld.pack Do you remember who has added a JustResources there? Was it a JIRA issue reported by you? Thanks, Mikhail 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Bizzare. I moved it, but it didn't get added. Or at least, I think so. I did discover why the file wasn't included though at my end ... it wasn't part of the change set, so wasn't included in the patch. I've re-generated the patch with it in this time and attached to Harmony-1019 ... is that any better? Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: I believe that the JustResources.pack file was moved to a different location, and so the test was updated to reflect that new location. I saw the same problem myself ... can you confirm that there is a file in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I think that's where the segment ended up. I didn't actually move the file ... someone else did IIRC. Alex. On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: One more problem caused by the patch: java.lang.NullPointerException at org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Thanks, Mikhail 2006/8/10, Mikhail Loenko [EMAIL PROTECTED]: PopulationCodecTest is missing, but there are other new files in the patch. You can see all of them if open the patch with a text editor and seek for (revision 0) substring Thanks, Mikhail 2006/8/9, Alex Blewitt [EMAIL PROTECTED]: Weird. I don't know what happened. I've attached PopulationCodec (a new file) separately to the bug report. There's also BHSDCodec, which is new in the patch, as well as PopulationCodecTest. Are they there too? Alex. On 08/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Alex Thanks for the patch! I have a problem with integration: this classes org.apache.harmony.archive.internal.pack200.CodecEncoding refers to the PopulationCodec class that seems to be missing I'm trying to apply 'patch' [1]. Am I doing anything wrong? Thanks, Mikhail [1] http://issues.apache.org/jira/secure/attachment/12338321/patch 2006/8/8, Alex Blewitt [EMAIL PROTECTED]: I've been getting further towards the Pack200 implementation with finishing off the codecs that are used to decode values from the file. Although most of the default codecs were in place, the pack200 spec allows for dynamic switching to arbitrary codecs should the compressor warrant it, including a population-based encoding for (in)frequent values. I've submitted Harmony 1019 with the patch; if someone could apply that, I'd be grateful. At present, the pack200 algorithm gets as far as the inner class definitions, but I've still got to decode the annotations and bytecode. I'm thinking that as a first-cut, I will ignore any pack files with annotations in and plough through the bytecode so that we can at least start using it for simple pack files. I've got a bit of work left to integrate the dynamic switching of band encodings (but that's OK since most of the simple pack files only use the default) that will involve a bit of refactoring, and essentially then just the bytecode (as long as there are no annotations). I don't think it will be too long before we can unpack simple files on some of the lower-quality settings :-) Also, when I get around to implementing some of the coding (as opposed to decoding), I'm pretty sure that some of the techniques might be useful for compressing arbitrary data streams. It would be interesting to see what other uses there are for the codecs.
Re: [classlib][support] Using new framework for testing serialization (was: Re: [jira] Updated: (HARMONY-1098) [classlib][instrument]Add tests for UnmodifiableClassException and IllegalClassFormatExce
Stepan Mishura wrote:
snip
BufferOverflowException());
But then you have to move generated file to the appropriate place by
hands.
Is this convenient?
Hi Stepan,
IMO, most ser file should be put into a certain directory, so the
the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated file is placed in
'bin' (i.e. module_root/bin/test). folder. Am I right? So you have to
move it by hands anyway to module_root/src/test/resources/serialization
folder.
Ah sorry, I only test it on eclipse. Yes, if run on ant, it would
properly be module_root/bin/test.
IMO, mostly, people write code and create file once (for me, on
eclipse), so it is still a convenience if the framework offer such method.
And for people who use ant to run test, still can offer a method for
that, e.g.
public static void createGoldenFileUsingAnt(TestCase test,Object object)
throws IOException {
createGoldenFile(../../src/test/resources/serialization,test,object);
}
Am I right? Thanks! :)
Thanks,
Stepan.
I have tried the new method, and it works well :)
Can I or would you please make a patch for it? Thanks! :)
snip
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: BASE64Encoder class missing?
The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Alternative to suncompat is separating all similar functionality into a separate redistributable module that would be runnable on RI, so that people could use it in their apps. Thanks, Mikhail 2006/8/10, Tim Ellison [EMAIL PROTECTED]: I'll create a suncompat component and see where we go from there... Tim Alex Blewitt wrote: On 10/08/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Anthony Green wrote: On Wed, 2006-08-09 at 17:58 -0400, Geir Magnusson Jr wrote: Yes- the idea is to provide that suncompat.jar for that reason with those clases in the sun.* namespace that user apps depend on. This way lies madness. I urge you to take a strong stand against bad applications. Oh, don't get me wrong - we really want to. But we want adoption of the harmony codebase as well. We think that we have a reasonable balance - provide the functionality in an separable, modular way at first to make it easy for people to try and adopt harmony. May I suggest that we try and: 1) Make available a suncompat.jar, which re-writes calls to o.a.h or similar (or subclasses them ...) 2) Explicitly don't make it part of the default classpath ala 'tools.jar' in the standard Sun implementation when running HarmonyVM code 3) Put up a FAQ saying that 'If you depend on e.g. sun.*, stick the suncompat in the classpath' That way, out-of-the-box we don't have it, but there's an easy fix for people who trip up over it. However, if people just need to get it running, then they have a trivial workaround that doesn't involve changing their code. The same could also be provided for code that depends on sun.JavaC or whatever ... Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Our locale data is incomplete, and Locale(, CD).getDisplayCountry() return different string compared with ISO3166-1
2006/8/10, Richard Liang [EMAIL PROTECTED]:
Spark Shen wrote:
Hi All:
Construct a locale like this:
Locale l = new Locale(, CD);
On RI, l.getDisplayCountry() will return The Democratic Republic Of
Congo,
which is different from ISO 3166-1 standard.
(CONGO, THE DEMOCRATIC REPUBLIC OF THE or Congo, the Democratic
Republic
of the)
IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
think user applications would be broken because of the difference with RI.
I am not sure. But this may be a risk.
Best regards
Richard.
Mean while, on harmony, we do not have a country CD-CONGO, THE
DEMOCRATIC REPUBLIC OF THE data item or a
CD- Congo, the Democratic Republic of
thehttp://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
data item at all.
This test case will fail on Harmony since the returned displayCountry is
CD.
public void test_getDisplayCountry() {
Locale l_countryCD = new Locale(, CD);
assertEquals(CONGO, THE DEMOCRATIC REPUBLIC OF THE,
l_countryCD.getDisplayCountry());
}
I need to add a mapping into harmony locale data. But which?
CD-CONGO, THE DEMOCRATIC REPUBLIC OF THE
or
CD-Congo, the Democratic Republic of the
or
CD-The Democratic Republic Of Congo (RI)
Personally, I prefer RI, since there may be applications relies on the
returned displayCountry value. Your opinions?
Best regards
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Spark Shen
China Software Development Lab, IBM
[DRLVM] Thread manager component for DRLVM
A few hours ago I have submitted the Thread Manager component which is aimed to make an improvement over the infrastructure of threading-related code in the DRLVM. The thread manager code, documentation, tests and integration patch can be found in this issue: http://issues.apache.org/jira/browse/HARMONY-1125 With this improvement, DRLVM would have the dedicated threading module with a well-defined interface which may contribute into the concept of the modular JVM. There are open questions with respect to the suggested API and implementation, for example - what should be the relationship between DRLVM's threading subystem and the hythread introduced with the classlib (the suggested thread manager implements most of hythread API). But, whatever we decide it should be, this change still may be worth applied as an initial step toward modularization of the DRLVM. Please see the more details about this in the issue description, I'd be happy to provide more if needed. Thanks, Andrey. -- Andrey Chernyshev Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new files to SVN and subsequently trying to update
Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name already exists The normal answer/faq The case is wrong doesn't apply -- I've got a case sensitive file system. The problem is that the JustResources.pack doesn't exist on the SVN branch that I'm working on at the moment, but someone else has added it for me; and when I try update to their copy, I get this message. Surely SVN can't be dozy enough that it doesn't realise that the file's contents is exactly the same in this case, and/or offer to try and merge it? Is there some kind of --stop-being-anal flag that I need to pass to SVN to convince it to do the work properly? The wisdom of 'well, just delete the file and update' is all well and good, but (a) I want to check that the file's been added properly, and (b) see if any changes have been made between the patch that I sent up and what's currently in SVN. If I just delete it, I'm taking it on faith that it's the same as it was before (and, for that matter, that it's been added successfully). It's also a right pain when it's not just one or two, but perhaps a handful (7) of new files. Is there any way of configuring either the command-line update or subclipse to get it right, or am I doomed to this process every time I create a new file? Alex. On 10/08/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ] Mikhail Loenko resolved HARMONY-1019. - Resolution: Fixed Alex, the patch was applied in revision 430314 missing copyrights were added to the new files please let me know if it's OK for you Adding RunCodec and segment encoding tests -- Key: HARMONY-1019 URL: http://issues.apache.org/jira/browse/HARMONY-1019 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Alex Blewitt Assigned To: Mikhail Loenko Priority: Minor Attachments: patch, patch.txt, patch3.txt, PopulationCodec.java This adds some functionality to the pack200 implementation, albeit not used at present. The codec encoding allows multiple codecs to be specified by decompressing values from the header bytes; eventually, this will be needed by the segment decoding (currently, they all assume a default encoding for each band). Note to whoever applies this fix: please apply this fix as-is first (and commit) and then apply any typographical fixes/renames/spaces and commit a second time. It's a real nightmare trying to update-and-merge code after I've submitted it and minor changes have been made to this patch file prior to committing. At least if you commit it as is first, I can then easily update to that version and then merge upwards to take into account your changes automatically. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Adding new files to SVN and subsequently trying to update
OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like entry name=AddedFile.java kind=file schedule=add revision=0/ then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first (chmod +w entries or attrib -r entries) 2d) svn up AddedFile.java (which brings it in) 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the changes are 2f) Delete AddedFile.java.bak since it's no longer necessary. Repeat 2a-2f for as many new files as you've added. Swear, drink caffeinated/alchoholic beverage of your choice, and vow to add as few new files as possible in the future by writing humungous class files. Hope that's useful to anyone else in this position. Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name already exists The normal answer/faq The case is wrong doesn't apply -- I've got a case sensitive file system. The problem is that the JustResources.pack doesn't exist on the SVN branch that I'm working on at the moment, but someone else has added it for me; and when I try update to their copy, I get this message. Surely SVN can't be dozy enough that it doesn't realise that the file's contents is exactly the same in this case, and/or offer to try and merge it? Is there some kind of --stop-being-anal flag that I need to pass to SVN to convince it to do the work properly? The wisdom of 'well, just delete the file and update' is all well and good, but (a) I want to check that the file's been added properly, and (b) see if any changes have been made between the patch that I sent up and what's currently in SVN. If I just delete it, I'm taking it on faith that it's the same as it was before (and, for that matter, that it's been added successfully). It's also a right pain when it's not just one or two, but perhaps a handful (7) of new files. Is there any way of configuring either the command-line update or subclipse to get it right, or am I doomed to this process every time I create a new file? Alex. On 10/08/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ] Mikhail Loenko resolved HARMONY-1019. - Resolution: Fixed Alex, the patch was applied in revision 430314 missing copyrights were added to the new files please let me know if it's OK for you Adding RunCodec and segment encoding tests -- Key: HARMONY-1019 URL: http://issues.apache.org/jira/browse/HARMONY-1019 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Alex Blewitt Assigned To: Mikhail Loenko Priority: Minor Attachments: patch, patch.txt, patch3.txt, PopulationCodec.java This adds some functionality to the pack200 implementation, albeit not used at present. The codec encoding allows multiple codecs to be specified by decompressing values from the header bytes; eventually, this will be needed by the segment decoding (currently, they all assume a default encoding for each band). Note to whoever applies this fix: please apply this fix as-is first (and commit) and then apply any typographical fixes/renames/spaces and commit a second time. It's a real nightmare trying to update-and-merge code after I've submitted it and minor changes have been made to this patch file prior to committing. At least if you commit it as is first, I can then easily update to that version and then merge upwards to take into account your changes automatically. Thanks! -- This message is automatically
Re: BASE64Encoder class missing?
Mikhail Loenko wrote: The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. Alternative to suncompat is separating all similar functionality into a separate redistributable module that would be runnable on RI, so that people could use it in their apps. If we could get people to change their apps then I would agree. In fact I would expect that most of the non-API functionality in common usage is already available elsewhere there if apps wanted to change (well, maybe not Unsafe, but...). But we are trying to fix it on the Harmony side. I'll go ahead an put in the suncompat module, but don't let that be the end of the debate -- it is trivial to add it and I have no qualms about removing it later if that's what we choose to do. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][support] Using new framework for testing serialization (was: Re: [jira] Updated: (HARMONY-1098) [classlib][instrument]Add tests for UnmodifiableClassException and IllegalClassFormatExce
On 8/10/06, Jimmy, Jing Lv wrote:
Stepan Mishura wrote:
snip
BufferOverflowException());
But then you have to move generated file to the appropriate place by
hands.
Is this convenient?
Hi Stepan,
IMO, most ser file should be put into a certain directory, so the
the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated file is placed
in
'bin' (i.e. module_root/bin/test). folder. Am I right? So you have to
move it by hands anyway to
module_root/src/test/resources/serialization
folder.
Ah sorry, I only test it on eclipse. Yes, if run on ant, it would
properly be module_root/bin/test.
IMO, mostly, people write code and create file once (for me, on
eclipse), so it is still a convenience if the framework offer such method.
And for people who use ant to run test, still can offer a method for
that, e.g.
public static void createGoldenFileUsingAnt(TestCase test,Object object)
throws IOException {
createGoldenFile(../../src/test/resources/serialization,test,object);
}
Am I right? Thanks! :)
IMHO the framework shouldn't contain methods that work for selected tool
only.
Thanks,
Stepan.
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions found while running servlet...
Jimmy, Jing Lv wrote: Oops, this is certainly wrong: offset = buffer.length,count = buffer.length - offset, the equal mark should be omitted. I'll raise a JIRA for this. I'm not sure if this is the cause of the problem. So would you please try again if I correct it? :) If you raise a JIRA with regression test case I'll look out for it and fast-track it in for you. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new files to SVN and subsequently trying to update
Hi Alex, I think you can't just delete the file once youve done an svn add on it. I think svn stores some metadata (I believe in the .svn/entries file) about the files you've added, and so doing a plain delete of the file without telling svn will leave the metadata laying around. Normally if I want to remove a file I have added so I can update, I will revert the file add (so it is no longer revision controlled) and then delete it before updating. Now that you have deleted the file, you can still run an svn revert to remove the metadata related to the file addition - just revert the containing directory, and only pick the JustResources.pack file. Unfortunately I do not have a better solution to this problem - it is a pain, but I dont know of any better way to do it :( Regards, Oliver Alex Blewitt wrote: Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name already exists The normal answer/faq The case is wrong doesn't apply -- I've got a case sensitive file system. The problem is that the JustResources.pack doesn't exist on the SVN branch that I'm working on at the moment, but someone else has added it for me; and when I try update to their copy, I get this message. Surely SVN can't be dozy enough that it doesn't realise that the file's contents is exactly the same in this case, and/or offer to try and merge it? Is there some kind of --stop-being-anal flag that I need to pass to SVN to convince it to do the work properly? The wisdom of 'well, just delete the file and update' is all well and good, but (a) I want to check that the file's been added properly, and (b) see if any changes have been made between the patch that I sent up and what's currently in SVN. If I just delete it, I'm taking it on faith that it's the same as it was before (and, for that matter, that it's been added successfully). It's also a right pain when it's not just one or two, but perhaps a handful (7) of new files. Is there any way of configuring either the command-line update or subclipse to get it right, or am I doomed to this process every time I create a new file? Alex. On 10/08/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ] Mikhail Loenko resolved HARMONY-1019. - Resolution: Fixed Alex, the patch was applied in revision 430314 missing copyrights were added to the new files please let me know if it's OK for you Adding RunCodec and segment encoding tests -- Key: HARMONY-1019 URL: http://issues.apache.org/jira/browse/HARMONY-1019 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Alex Blewitt Assigned To: Mikhail Loenko Priority: Minor Attachments: patch, patch.txt, patch3.txt, PopulationCodec.java This adds some functionality to the pack200 implementation, albeit not used at present. The codec encoding allows multiple codecs to be specified by decompressing values from the header bytes; eventually, this will be needed by the segment decoding (currently, they all assume a default encoding for each band). Note to whoever applies this fix: please apply this fix as-is first (and commit) and then apply any typographical fixes/renames/spaces and commit a second time. It's a real nightmare trying to update-and-merge code after I've submitted it and minor changes have been made to this patch file prior to committing. At least if you commit it as is first, I can then easily update to that version and then merge upwards to take into account your changes automatically. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL
Re: Adding new files to SVN and subsequently trying to update
Just sent my other mail before seeing this one. Rather than manually editing the entries file you can, as I suggest in the other mail, still revert the original file name after you have moved it to a new file. So you could: - move the file to a new name AddedFile.java.bak - svn revert AddedFile.java (this should still work even tho the file is no longer there) - svn up - compare AddedFile.java and AddedFile.java.bak - swear etc. Hope this helps, Oliver Alex Blewitt wrote: OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like entry name=AddedFile.java kind=file schedule=add revision=0/ then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first (chmod +w entries or attrib -r entries) 2d) svn up AddedFile.java (which brings it in) 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the changes are 2f) Delete AddedFile.java.bak since it's no longer necessary. Repeat 2a-2f for as many new files as you've added. Swear, drink caffeinated/alchoholic beverage of your choice, and vow to add as few new files as possible in the future by writing humungous class files. Hope that's useful to anyone else in this position. Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name already exists The normal answer/faq The case is wrong doesn't apply -- I've got a case sensitive file system. The problem is that the JustResources.pack doesn't exist on the SVN branch that I'm working on at the moment, but someone else has added it for me; and when I try update to their copy, I get this message. Surely SVN can't be dozy enough that it doesn't realise that the file's contents is exactly the same in this case, and/or offer to try and merge it? Is there some kind of --stop-being-anal flag that I need to pass to SVN to convince it to do the work properly? The wisdom of 'well, just delete the file and update' is all well and good, but (a) I want to check that the file's been added properly, and (b) see if any changes have been made between the patch that I sent up and what's currently in SVN. If I just delete it, I'm taking it on faith that it's the same as it was before (and, for that matter, that it's been added successfully). It's also a right pain when it's not just one or two, but perhaps a handful (7) of new files. Is there any way of configuring either the command-line update or subclipse to get it right, or am I doomed to this process every time I create a new file? Alex. On 10/08/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1019?page=all ] Mikhail Loenko resolved HARMONY-1019. - Resolution: Fixed Alex, the patch was applied in revision 430314 missing copyrights were added to the new files please let me know if it's OK for you Adding RunCodec and segment encoding tests -- Key: HARMONY-1019 URL: http://issues.apache.org/jira/browse/HARMONY-1019 Project: Harmony Issue Type: Improvement Components: Classlib Reporter: Alex Blewitt Assigned To: Mikhail Loenko Priority: Minor Attachments: patch, patch.txt, patch3.txt, PopulationCodec.java This adds some functionality to the pack200 implementation, albeit not used at present. The codec encoding allows multiple codecs to be specified by decompressing values from the header bytes; eventually, this will be needed by the segment decoding (currently, they all assume a default encoding for each band). Note to whoever applies this
Re: Re: Re: Re: Re: Re: [classlib][pack200] Status update
Only one problem I've found so far (possibly because it was in an earlier patch but not subsequent ones) -- the src/test/java/org/apache/harmony/archive/tests/AllTests.java doesn't have a suite.addTest(org.apache.harmony.archive.tests.internal.pack200.AllTests.suite()); in it. Can you add that, or do you want me to send a patch? (Mind you, with my record of submitting patches, I'm not sure that's such a good idea ;-) Alex. On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Finally it's in! :) 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Don't you just hate it when that happens? :-) On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I've found this file in http://issues.apache.org/jira/browse/HARMONY-634 Tim decisded not to commit it as it was not used at the moment I'll check if it solves the problem Thanks, Mikhail 2006/8/10, Mikhail Loenko [EMAIL PROTECTED]: The test still fails. I have not found any file named JustResources* in SVN. The only pack file I've found is HelloWorld.pack Do you remember who has added a JustResources there? Was it a JIRA issue reported by you? Thanks, Mikhail 2006/8/10, Alex Blewitt [EMAIL PROTECTED]: Bizzare. I moved it, but it didn't get added. Or at least, I think so. I did discover why the file wasn't included though at my end ... it wasn't part of the change set, so wasn't included in the patch. I've re-generated the patch with it in this time and attached to Harmony-1019 ... is that any better? Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: I believe that the JustResources.pack file was moved to a different location, and so the test was updated to reflect that new location. I saw the same problem myself ... can you confirm that there is a file in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I think that's where the segment ended up. I didn't actually move the file ... someone else did IIRC. Alex. On 10/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: One more problem caused by the patch: java.lang.NullPointerException at org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) Thanks, Mikhail 2006/8/10, Mikhail Loenko [EMAIL PROTECTED]: PopulationCodecTest is missing, but there are other new files in the patch. You can see all of them if open the patch with a text editor and seek for (revision 0) substring Thanks, Mikhail 2006/8/9, Alex Blewitt [EMAIL PROTECTED]: Weird. I don't know what happened. I've attached PopulationCodec (a new file) separately to the bug report. There's also BHSDCodec, which is new in the patch, as well as PopulationCodecTest. Are they there too? Alex. On 08/08/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Alex Thanks for the patch! I have a problem with integration: this classes org.apache.harmony.archive.internal.pack200.CodecEncoding refers to the PopulationCodec class that seems to be missing I'm trying to apply 'patch' [1]. Am I doing anything wrong? Thanks, Mikhail [1] http://issues.apache.org/jira/secure/attachment/12338321/patch 2006/8/8, Alex Blewitt [EMAIL PROTECTED]: I've been getting further towards the Pack200 implementation with finishing off the codecs that are used to decode values from the file. Although most of the default codecs were in place, the pack200 spec allows for dynamic switching to arbitrary codecs should the compressor warrant it, including a population-based encoding for (in)frequent values. I've submitted Harmony 1019 with the patch; if someone could apply that, I'd be grateful. At present, the pack200 algorithm gets as far as the inner class definitions, but I've still got to decode the annotations and bytecode. I'm thinking that as a first-cut, I will ignore any pack files with annotations in and plough through the bytecode so that we can at least start using it for simple pack files. I've got a bit of work left to integrate the dynamic switching of band encodings (but that's OK since most of the simple pack files only use
Re: [classlib][summary] Exception throwing compatibility
Vladimir Ivanov wrote: On 8/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/8/9, Richard Liang [EMAIL PROTECTED]: If the spec does not specify which exception is thrown, I think RI *is* compliant with the specification. Am I wrong? I wanted to separate cases when the spec is not clear enough and RI's behavior either hard to reproduce or odd. For example if sqrt(-2) threw exception1, sqrt(-5) threw exception2 and sqrt(-187) threw exception3 The real example is issue 1114 :) Great catch ;-) I have updated the wiki page. Best regards, Richard Thanks, Vladimir Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r424890 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/io/BufferedInputStream.java test/java/tests/api/java/io/BufferedInputStreamTest.java
Vladimir Ivanov wrote:
No, this test will be fail if the issue 667 returns back :)
I see. Thanks a lot. I will try to provide a patch to fix this issue.
Richard
Thanks, Vladimir
On 8/10/06, Richard Liang [EMAIL PROTECTED] wrote:
Paulex Yang wrote:
Oops, it's my fault that missed to find this. Would you mind to
provide a patch for this? or I'll fix it myself.
let me fix it. But I'm not sure if Vladimir Ivanov has any concerns
about this issue.
Richard.
Richard Liang wrote:
Hello Paulex,
It seems that the test case is invalid, because the tests will always
pass whether buf.close() throws IOException or not.
+try {
+buf.close();
+} catch (IOException e) {
+//expected
+} }
Please have a look at the following tests which passes on RI, but
fails on Harmony.
public void test_close() throws IOException {//regression for
HARMONY-667
BufferedInputStream buf = new BufferedInputStream(null, 5);
buf.close();
}
Thanks a lot.
Best regards,
Richard.
[EMAIL PROTECTED] wrote:
Author: pyang
Date: Sun Jul 23 20:29:14 2006
New Revision: 424890
URL: http://svn.apache.org/viewvc?rev=424890view=rev
Log:
Fix for HARMONY-667 (
[classlib][io]java.io.BufferedInputStream.skip(int n) unexpected
NPE)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java?rev=424890r1=424889r2=424890view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/BufferedInputStream.java
Sun Jul 23 20:29:14 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors, as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its
licensors, as applicable
* * Licensed under the Apache License, Version 2.0 (the
License);
* you may not use this file except in compliance with the License.
@@ -109,6 +109,9 @@
* If an error occurs attempting to close this
stream.
*/
public synchronized void close() throws IOException {
+if(null == in){
+throw new
IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
+}
super.close();
buf = null;
}
@@ -311,6 +314,9 @@
* occurs.
*/
public synchronized long skip(long amount) throws IOException {
+if(null == in){
+throw new
IOException(org.apache.harmony.luni.util.Msg.getString(K0059));
+}
if (amount 1)
return 0;
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java?rev=424890r1=424889r2=424890view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/io/BufferedInputStreamTest.java
Sun Jul 23 20:29:14 2006
@@ -1,4 +1,4 @@
-/* Copyright 1998, 2005 The Apache Software Foundation or its
licensors, as applicable
+/* Copyright 1998, 2006 The Apache Software Foundation or its
licensors, as applicable
* * Licensed under the Apache License, Version 2.0 (the
License);
* you may not use this file except in compliance with the License.
@@ -120,6 +120,14 @@
// Test for method void java.io.BufferedInputStream.close()
new BufferedInputStream(isFile);
new BufferedInputStream(isFile);
+ +//regression for HARMONY-667
+BufferedInputStream buf = new BufferedInputStream(null, 5);
+try {
+buf.close();
+} catch (IOException e) {
+//expected
+} }
/**
@@ -310,6 +318,14 @@
} catch (java.io.IOException e) {
fail(Exception during skip test);
}
+
+//regression for HARMONY-667
+BufferedInputStream buf = new BufferedInputStream(null, 5);
+try {
+buf.skip(10);
+
Re: [classlib][summary] Exception throwing compatibility
Tim Ellison wrote: We don't have such a JIRA category: If we decide to follow RI, we will raise an Non-bug differences from Spec JIRA. Do you think we need this category to record Harmony's complying-with-RI behavior while breaking the spec? Thanks a lot. Best regards, Richard Do you really need the section starting: We consider RI is compliant with the Java Specification, if RI... Regards, Tim Richard Liang wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- Richard Liang China Software Development Lab, IBM
Re: [classlib][suncompat] created
OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Alex. On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Just FYI, I went ahead and created a suncompat.jar. As I wrote elsewhere it is trivial to create a new module, and trivial to remove it if we decide this is the wrong direction. By default it is unused in the JRE, to enable it you need to uncomment the lines at the end of jre/lib/boot/bootclasspath.properties Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Our locale data is incomplete, and Locale(, CD).getDisplayCountry() return different string compared with ISO3166-1
On 8/10/06, Spark Shen [EMAIL PROTECTED] wrote:
2006/8/10, Richard Liang [EMAIL PROTECTED]:
Spark Shen wrote:
Hi All:
Construct a locale like this:
Locale l = new Locale(, CD);
On RI, l.getDisplayCountry() will return The Democratic Republic Of
Congo,
which is different from ISO 3166-1 standard.
(CONGO, THE DEMOCRATIC REPUBLIC OF THE or Congo, the Democratic
Republic
of the)
IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
think user applications would be broken because of the difference with
RI.
I am not sure. But this may be a risk.
To follow ISO-3166 standard mentioned in the spec sounds better and
logical but...if you take a look on other several words country names you
can find that they are not the same on RI than in the ISO-3166. E.g.:
new Locale(, KP);
ISO-3166 expected value: Korea, Democratic People's Republic of
RI returns: North Korea
new Locale(, MK);
ISO-3166 expected value: Macedonia, the former Yugoslav Republic of
RI returns: Macedonia
..and so on.
IMO in this case to be compatible with RI we can use The Democratic
Republic Of Congo for CD country. To follow completely the ISO-3166
standard we have to make changes not only for CD country.
Thanks,
Ilya.
Best regards
Richard.
Mean while, on harmony, we do not have a country CD-CONGO, THE
DEMOCRATIC REPUBLIC OF THE data item or a
CD- Congo, the Democratic Republic of
the http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
data item at all.
This test case will fail on Harmony since the returned displayCountry
is
CD.
public void test_getDisplayCountry() {
Locale l_countryCD = new Locale(, CD);
assertEquals(CONGO, THE DEMOCRATIC REPUBLIC OF THE,
l_countryCD.getDisplayCountry());
}
I need to add a mapping into harmony locale data. But which?
CD-CONGO, THE DEMOCRATIC REPUBLIC OF THE
or
CD-Congo, the Democratic Republic of the
or
CD-The Democratic Republic Of Congo (RI)
Personally, I prefer RI, since there may be applications relies on the
returned displayCountry value. Your opinions?
Best regards
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Spark Shen
China Software Development Lab, IBM
--
--
Ilya Okomin
Intel Middleware Products Division
Re: BASE64Encoder class missing?
For this specific case, I found this code for Base64, which claims to be very fast and very compact: * http://migbase64.sourceforge.net/ Just a single class that I repackaged in my own namespaces, and changed one line of code to remove my dependency on sun.* - now I can run on Harmony. I think that providing some alerts about this dependency on Harmony website, explaining the problem (as the Sun article I posted before does) and suggesting some alternatives like migBase64, will help newcomers to understand how easy to overcome the dependency is, and motivate them to do so. Regards, Martin On 8/10/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. Alternative to suncompat is separating all similar functionality into a separate redistributable module that would be runnable on RI, so that people could use it in their apps. If we could get people to change their apps then I would agree. In fact I would expect that most of the non-API functionality in common usage is already available elsewhere there if apps wanted to change (well, maybe not Unsafe, but...). But we are trying to fix it on the Harmony side. I'll go ahead an put in the suncompat module, but don't let that be the end of the debate -- it is trivial to add it and I have no qualms about removing it later if that's what we choose to do. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions found while running servlet...
Hello,
Rick Knowles, the author of Winstone servlet engine, replied to my
email with this information:
Martin,
I think this is because winstone will sometimes do a
outputstream.write(arr, 0, 0), because the content length is actually
zero. It's likely that this is swallowed invisibly by IBM JRE, but not
by harmony. Probably something for both sides to fix - me, by removing
the call since it's not necessary, and harmony by allowing such writes.
Thanks, Rick
Hope it helps.
Regards,
Martin
On 8/10/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Jimmy, Jing Lv wrote:
snip
I do some further study and test then, and find the problem was not so
easy.
Alex and I are correct that offset = buffer.length here is wrong, but
the next count = buffer.length - offset seems has proved its
correctness.
I have a test[1], try to write(new byte[count],count, 0) to a
SocketOutputStream, the test passes quietly. I do this test on WinXp
Sp2, the latest Harmony workspace, with J9 VM5.
I believe the ArrayIndexOutOfBoundsException is throw out when it try to
get byte array in the native (GetByteArrayRegion), which is a JNI
method. I guess there may be some difference between VMs.
Martin, are you using DRLVM? Can someone using DRLVM (or other VMs) run
the test below on DRLVM for me? Thanks!
[1]
public void test_socketOutputStream() throws Exception {
ServerSocket ss = new ServerSocket(0);
Socket sock = new Socket();
sock.connect(new InetSocketAddress
(InetAddress.getLocalHost(),ss.getLocalPort()));
ss.accept();
OutputStream os = sock.getOutputStream();
os.write(new byte[0], 0, 0); // passes here
os.write(new byte[512], 512, 0); // passes here
}
Hi,
At last I have test[1] JNI method(GetByteArrayRegion) of RI (before
dinner, very hungry... :) )
The result is that, RI return successfully if the given offset
equals length of the byte array, and the given count is zero.
Thus IMHO it is better to improve DRLVM to follow RI, as JNI
methods are also API methods, users may use it.
Shall we raise a JIRA for DRLVM? Any comments/suggestions from
DRLVM guys? Thanks!
Time for dinner! :D
[1]
test.java
--
class test
{
static{
System.loadLibrary(testjni);
}
private native void testjni(byte[] bs);
public void usejni(){
testjni(new byte[512]);
}
public static void main(String args[]){
new test().usejni();
}
}
---
test.h
---
/* DO NOT EDIT THIS FILE - it is machine generated */
#include jni.h
/* Header for class test */
#ifndef _Included_test
#define _Included_test
#ifdef __cplusplus
extern C {
#endif
/*
* Class: test
* Method:testjni
* Signature: ([B)V
*/
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv *, jobject, jbyteArray);
#ifdef __cplusplus
}
#endif
#endif
--
test.c
--
#include test.h
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv * env, jobject obj,jbyteArray array){
jbyte* buf = (jbyte*)malloc(sizeof(jbyte)*512);
(*env)-GetByteArrayRegion(env,array,512, 0, buf);
}
(magic number 512 can be any integer, including zero)
snip
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dinamica - RADical J2EE framework
open source, easy and powerful
http://www.martincordova.com
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[general] compatibility packages (was: Re: BASE64Encoder class missing?)
Dalibor Topic wrote: On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. Hardly. Many replacements for Base64 exists, for example GNU Classpath recommends using Apache Commons Codec for projects compatible with the Apache license. Amateur developers use non-standard classes because they are too lazy to think for themselves, and accordingly copy broken code around projects. Alas, a language designed to appeal to the masses naturally attracts a lot of people who'd have trouble producing portable code in any programming language. :) I was being charitable. For sure many such usages can be easily avoided, but in other cases no so easily; like CharToByteConverter would require duplicating a wad of data, and I don't know of any third-party impl. of Unsafe. We should appeal to app developers to change implementation dependent code (even provide a recipe book of recommended solutions), but be pragmatic about the need to run the current version. In many cases it may be beyond the apps immediate sphere of influence (i.e. dependent libraries). If everyone responded as quickly and effectively as Martin we would have no worries. On a side note, I seem to recall reading on Sun's javac engineer's blog that javac won't allow access to sun internal classes sooner or later, so idiot-proofing class libraries may not be very useful, anyway, as people will have to rewrite such code, or preferrably, throw it away. It will be interesting to see what havoc is unleashed by attempts to reduce the visibility of sun internal packages by the compiler and at runtime. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions found while running servlet...
I am using the JRE snapshot (I did not build anything, just unpacked a ZIP): pre-alpha : not complete or compatible svn = r428649, (Aug 4 2006), Windows/ia32/msvc 1310, release build This is what I downloaded: * http://people.apache.org/dist/incubator/harmony/snapshots/latest-jre-windows.zip Yes I do have this class: org.apache.harmony.awt.gl.ImageSurface Should I set additional environment variable when starting my process? I am using: set path=c:\harmony\bin;%path% java -jar winstone-0.8.2-cvs.jar --config=./winstone.conf And seems to work fine for most cases, Harmony has only complained about that specific class. Should I include the /lib/boot to the %path%? Regards, Martin On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... Do you use harmony snapshot? I tried to run simple test which creates BufferedImage with aug 04 snapshot and got an UnsatisfiedLinkError instead of it. But absence of the gl.dll in that snapshot is a known issue and likely to be fixed in the next snapshot. Maybe you could try to look into your HARMONY_HOME/lib/boot/awt.jar and check if it includes org.apache.harmony.awt.gl.ImageSurface class? The snapshot has it and there shouldn't be any problems with loading this class. If you built harmony from sources, please consider refreshing awt module and rebuilding with -Dwith.awt.swing=true On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: Is it OK to send this type of feedback to the list? please let me know if not, and what subject conventions should I use (is there a link about this?). I am not a Harmony developer, just a new user, I can only provide feedback from my tests. I am running a small webapp, using Winstone servlet engine and IBM JDK 1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4), and found these exceptions: 1.- I see this error while using servlet includes and also at the end of some pages: java.lang.ArrayIndexOutOfBoundsException: 0..0 at org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java) at org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194) at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647) at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152) at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at java.io.PrintWriter.doWrite(PrintWriter.java:640) at java.io.PrintWriter.write(PrintWriter.java:622) at winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45) at java.io.PrintWriter.write(PrintWriter.java:607) at java.io.PrintWriter.write(PrintWriter.java:657) at java.io.PrintWriter.print(PrintWriter.java:455) at 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... The JDBC related code is running fine, performance also looks very good. I will contact Winstone developer to see if he can help in some way to identify the problem. He already helped me a few months ago to help identify a bug in GNU Classpath server socket API. Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dinamica - RADical J2EE framework open source, easy and powerful
Re: [testing] metadata approach
We now have this, so let the TestNG debate continue :) Unfortunately, we still need java.util.concurrent :-( Yeah, TestNG 5.0 still throws java.lang.NoClassDefFoundError : java.util.concurrent.LinkedBlockingQueue on Harmony+j9v4. I've also got an error while trying to compile TestNG 5.0 tests with Harmony+j9v4+ecj: The method getId() is undefined for the type Thread - If we go ahead with TestNG, we need to select a set of group names to use to indicate exclusion, platform specificness etc. Don't you like the names suggested by George? - Decide whether some physical separation of tests on disk is necessary, for instance to separate classpath and bootclasspath tests IMHO it is ok to separate classpath and bootclasspath tests because it will be easer to implement such solution technically. Regards, 2006/8/10, Richard Liang [EMAIL PROTECTED]: Oliver Deakin wrote: Richard Liang wrote: Alexei Zakharov wrote: Hi Richard, Not sure if we really want to involve another migration: TestNG javadoc - TestNG annotation. Any comments? Well, IMHO this depends on time constraints - when do we plan to have the support for anotations? If the answer is about a couple of weeks - no problem, we can wait. But if this is several months... About the migration - I don't think this will be a real painfull migration, all infrastructure will remain the same. We will only need to convert javadocs to annotations (one-one correspondence) and this task can be easily automated. Sounds reasonable. :-) Maybe drlvm guys or Oliver could tell us when we will have a VM with annotation support? We now have this, so let the TestNG debate continue :) Unfortunately, we still need java.util.concurrent :-( I guess we need to decide a few things before we go ahead with this: - Whether TestNG is generally accepted by the Harmony community as our test harness of choice for unit testing. I think this will probably require a vote of some kind before we could make the move. - If we go ahead with TestNG, we need to select a set of group names to use to indicate exclusion, platform specificness etc. - Decide whether some physical separation of tests on disk is necessary, for instance to separate classpath and bootclasspath tests. Comments/additions? Agree. And we could provide proposals for these questions case by case, and let community make decision. Best regards, Richard Regards, Oliver Thanks, 2006/8/1, Richard Liang [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi, I have created this new thread as a single place for discussions started in Re: [testing] Peace and [classlib] Testing conventions – a proposal threads. What did we have in the previous threads? * Test classification proposed by Vladimir * Test classification and group names proposed by George * Solution for Ant and TestNG scripting issues (still being discussed) Since a lot of people are asking about TestNG and wanting TestNG I decide to put some effort and take a closer look at this piece of software. Thus during the last few days I was playing with TestNG - I tried to run different kind of tests with it, to perform various workloads, generate reports in different ways and etc. The purpose of all this activity was to try TestNG in a real work, understand is TestNG really worth our credits and how expensive can be moving to TestNG from our currently implemented testing infrastructure. Now I have some thoughts and facts I'd like to share with the community. I've put it in the form of list for convenience. * TestNG works ok in normal conditions, no visible bugs * It is possible to define and use various (possibly intersecting) test groups with TestNG * TestNG-style metadata is more convenient than JUnit test suites (now I agree with this statement). IMHO this is the main TestNG benefit. * It is possible to run TestNG from command line * There is also the special ant task for running TestNG * Not everything can be configured with the ant task or command-line params, sometimes extra test suite definition file testng.xml is needed * It is possible to run jUnit tests with TestNG (testng.xml is needed in this case) * It is possible to run junit tests we currently have in Harmony with TestNG without any problems and modifications of the source code. However, we probably should write some number of TestNG test suite definition files testng.xml to be able to run all our junit tests (I have tried tests for bean module and some tests for luni) * We can mix jUnit tests and TestNG tests in the single test suite configuration – i.e. single testng.xml file. We can add TestNG metadata to some test classes and leave other test classes untouched * TestNG generates HTML reports in its own style, not a very convenient one IMHO * It is also possible to generate JUnitReports from the output generated by TestNG * Such reports will have a little
Re: Adding new files to SVN and subsequently trying to update
Alex Blewitt wrote: Yeah ... the problem is that unless you do an 'svn add', it doesn't show up when you have an 'svn patch' or similar (see other swearing, ranting etc. about missing files). So, I've got to add, patch, submit, wait, hack/revert, diff each new file I add ... Yeah, if you want the file to appear in the patch, then you've got to add it. Then once you do that you can't update, ugh! I guess you could not do the svn add and just attach the files to the JIRA along with the patch and describe where they should go, but this takes more effort on the part of the committer to put them in the right place and is open to mistakes when writing down the path locations of the files (which can be pretty long in Harmony!). The big problem (for me) is that it effectively means once I've added a new file, I really can't do any new work on it until it's been added, since otherwise any changes I make between filing the patch and having a clean 'svn up' (which I have just got to -- hooray!) are almost certain to be lost in the process. In turn, it means that there's much less of a benefit to me submitting code in smaller chunks, and I might as well just sit on it until I've developed a huge wodge of changes and send them in one go. If you are following the add, create patch, revert, delete, update, diff cycle, then at least you can transfer new changes to the svn versioned file during the diff stage, so you should be able to continue working on the newly added file (even if it is a hassle every time you have to update). I would be great if svn would recognise that the added file in the repo was the same as the one added on your disk and attempt to merge them. There must be someone out there who knows a better way to do this? Regards, Oliver Mind you, it's not like we're working against a deadline here, and I'm happy taking a few days off from thinking about it ... but I'll plan where my breaks are better in terms of functionalitiy in the future. (Any SVN developers on this list want to help figure out how to make this better?) Alex. On 10/08/06, Oliver Deakin [EMAIL PROTECTED] wrote: Just sent my other mail before seeing this one. Rather than manually editing the entries file you can, as I suggest in the other mail, still revert the original file name after you have moved it to a new file. So you could: - move the file to a new name AddedFile.java.bak - svn revert AddedFile.java (this should still work even tho the file is no longer there) - svn up - compare AddedFile.java and AddedFile.java.bak - swear etc. Hope this helps, Oliver Alex Blewitt wrote: OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like entry name=AddedFile.java kind=file schedule=add revision=0/ then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first (chmod +w entries or attrib -r entries) 2d) svn up AddedFile.java (which brings it in) 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the changes are 2f) Delete AddedFile.java.bak since it's no longer necessary. Repeat 2a-2f for as many new files as you've added. Swear, drink caffeinated/alchoholic beverage of your choice, and vow to add as few new files as possible in the future by writing humungous class files. Hope that's useful to anyone else in this position. Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name already exists The normal answer/faq The case is wrong doesn't apply -- I've got a case sensitive file system. The problem is that the JustResources.pack doesn't exist on the SVN branch that I'm working on at the moment, but someone else has added it for me; and when I
Re: svn commit: r430050 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml
Hopefully this fixes it for Alexei. If it doesn't cause more havoc I'll
promote it to make/property.xml and apply it to all modules.
Thanks Tim, everything is fine now.
With Best Regards,
2006/8/9, Tim Ellison [EMAIL PROTECTED]:
Just saw your note after committing a further tweak.
I thought the same thing, but did it in a slightly different way. We
could play like this for hours :-)
Hopefully this fixes it for Alexei. If it doesn't cause more havoc I'll
promote it to make/property.xml and apply it to all modules.
Regards,
Tim
Mark Hindess wrote:
On 9 August 2006 at 13:33, [EMAIL PROTECTED] wrote:
Author: tellison
Date: Wed Aug 9 06:33:00 2006
New Revision: 430050
URL: http://svn.apache.org/viewvc?rev=430050view=rev
Log:
Don't stop building if svn info is unavailable.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml
Modified: incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/m
odules/luni/build.xml?rev=430050r1=430049r2=430050view=diff
=
=
--- incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml (origina
l)
+++ incubator/harmony/enhanced/classlib/trunk/modules/luni/build.xml Wed Aug
9 06:33:00 2006
@@ -272,7 +272,7 @@
/target
target name=-svn-prop depends=-svn-detect if=svn.available
-exec executable=svn
+exec executable=svn failifexecutionfails=false
arg value=info /
redirector outputproperty=svn.info
outputfilterchain
Now you've changed this I wonder if we need the svn-detect/svn.available
check at all? We might just do:
target name=-svn-prop
exec executable=svn failifexecutionfails=false
resultproperty=svn.res
arg value=info /
redirector outputproperty=svn.info.tmp
outputfilterchain
linecontainsregexp
regexp pattern=Repository Root:|Revision: /
/linecontainsregexp
tokenfilter
replacestring from=Repository Root: to=/
replacestring from=Revision: to= /
/tokenfilter
striplinebreaks/
/outputfilterchain
/redirector
/exec
condition property=svn.info value=${svn.info.tmp}
equals arg1=${svn.res} arg2=0 /
/condition
property name=svn.info value=Unknown /
/target
This sets it to Unknown even in the case of .svn being there and the
executable being missing.
Incidentally, my svn info doesn't have a Repository Root: line?
Regards,
Mark.
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] metadata approach
Richard Liang wrote: Oliver Deakin wrote: Richard Liang wrote: Alexei Zakharov wrote: Hi Richard, Not sure if we really want to involve another migration: TestNG javadoc - TestNG annotation. Any comments? Well, IMHO this depends on time constraints - when do we plan to have the support for anotations? If the answer is about a couple of weeks - no problem, we can wait. But if this is several months... About the migration - I don't think this will be a real painfull migration, all infrastructure will remain the same. We will only need to convert javadocs to annotations (one-one correspondence) and this task can be easily automated. Sounds reasonable. :-) Maybe drlvm guys or Oliver could tell us when we will have a VM with annotation support? We now have this, so let the TestNG debate continue :) Unfortunately, we still need java.util.concurrent :-( Ah! I hadn't realised that that was a requirement of TestNG. I guess we need to decide a few things before we go ahead with this: - Whether TestNG is generally accepted by the Harmony community as our test harness of choice for unit testing. I think this will probably require a vote of some kind before we could make the move. - If we go ahead with TestNG, we need to select a set of group names to use to indicate exclusion, platform specificness etc. - Decide whether some physical separation of tests on disk is necessary, for instance to separate classpath and bootclasspath tests. Comments/additions? Agree. And we could provide proposals for these questions case by case, and let community make decision. Sounds good. Regards, Oliver Best regards, Richard Regards, Oliver Thanks, 2006/8/1, Richard Liang [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi, I have created this new thread as a single place for discussions started in Re: [testing] Peace and [classlib] Testing conventions – a proposal threads. What did we have in the previous threads? * Test classification proposed by Vladimir * Test classification and group names proposed by George * Solution for Ant and TestNG scripting issues (still being discussed) Since a lot of people are asking about TestNG and wanting TestNG I decide to put some effort and take a closer look at this piece of software. Thus during the last few days I was playing with TestNG - I tried to run different kind of tests with it, to perform various workloads, generate reports in different ways and etc. The purpose of all this activity was to try TestNG in a real work, understand is TestNG really worth our credits and how expensive can be moving to TestNG from our currently implemented testing infrastructure. Now I have some thoughts and facts I'd like to share with the community. I've put it in the form of list for convenience. * TestNG works ok in normal conditions, no visible bugs * It is possible to define and use various (possibly intersecting) test groups with TestNG * TestNG-style metadata is more convenient than JUnit test suites (now I agree with this statement). IMHO this is the main TestNG benefit. * It is possible to run TestNG from command line * There is also the special ant task for running TestNG * Not everything can be configured with the ant task or command-line params, sometimes extra test suite definition file testng.xml is needed * It is possible to run jUnit tests with TestNG (testng.xml is needed in this case) * It is possible to run junit tests we currently have in Harmony with TestNG without any problems and modifications of the source code. However, we probably should write some number of TestNG test suite definition files testng.xml to be able to run all our junit tests (I have tried tests for bean module and some tests for luni) * We can mix jUnit tests and TestNG tests in the single test suite configuration – i.e. single testng.xml file. We can add TestNG metadata to some test classes and leave other test classes untouched * TestNG generates HTML reports in its own style, not a very convenient one IMHO * It is also possible to generate JUnitReports from the output generated by TestNG * Such reports will have a little bit different structure since TestNG doesn't provider any information about enclosing type for test methods. Names for tests (replacement for JUnit test classes) and test suites should be externally configured in testng.xml * TestNG for Java 5 doesn't work on Harmony because some necessary classes from java.util.concurrent package are missing and it seems that jsr14 target (we are currently using) doesn't support annotations * TestNG for Java 1.4 (javadoc version) currently works on Harmony * I have half-way done script that converts TestNG 1.4 metadata (javadoc) tests to TestNG 1.5 (5.0 annotations) tests. Excellent summary! Thanks a lot The question I'd like to raise now is – aren't we ready for TestNG right now? I suppose we will use Java 5.0 annotations of TestNG,
Re: [general] compatibility packages (was: Re: BASE64Encoder class missing?)
On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: Dalibor Topic wrote: On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. Hardly. Many replacements for Base64 exists, for example GNU Classpath recommends using Apache Commons Codec for projects compatible with the Apache license. Amateur developers use non-standard classes because they are too lazy to think for themselves, and accordingly copy broken code around projects. Alas, a language designed to appeal to the masses naturally attracts a lot of people who'd have trouble producing portable code in any programming language. :) I was being charitable. For sure many such usages can be easily avoided, but in other cases no so easily; like CharToByteConverter would require duplicating a wad of data, and I don't know of any third-party impl. of Unsafe. Is there something that CharToByteConverter does that CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen code using CharToByteConverter in years. Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks to the JVM JSR not being ahead thinking enough to specify an API for low-level operations. It may or may not work depedending on how a VM interprets the non-existent spec for that class, so it is practically useless, unless it is running on the VM it was written on, i.e. Sun's. It may or may not work by chance, rather than by virtue. That holds in general for any code using implementation-specific interfaces. We should appeal to app developers to change implementation dependent code (even provide a recipe book of recommended solutions), but be pragmatic about the need to run the current version. In many cases it may be beyond the apps immediate sphere of influence (i.e. dependent libraries). If everyone responded as quickly and effectively as Martin we would have no worries. We've been doing that for years. See the GNU Classpath migration page in the Wiki that describes how to fix such broken code in many cases. Being 'pragmatic' solves nothing, it just encourages people to continue behaving in dumb ways, because their code still may run, somehow, even if there is no way for Harmony to ensure that it will behave as they expect from whatever buggy Sun JDK they are using to run it usually in the corner cases, because there is no spec, and there are no tests. Awarding incompetence doesn't solve the problem. That being said, kudos to Martin for fixing the bug in his code. Had we had a Base64 class, that bug wouldn't have showed up, and his code would have failed elsewhere, or behaved differently on another VM. With the fix, his code is portable, behaves in the same way on any VM, and may even be faster than a vm-specific 'just for compatibility' implementation. There is no downside to simply fixing the buggy code. On a side note, I seem to recall reading on Sun's javac engineer's blog that javac won't allow access to sun internal classes sooner or later, so idiot-proofing class libraries may not be very useful, anyway, as people will have to rewrite such code, or preferrably, throw it away. It will be interesting to see what havoc is unleashed by attempts to reduce the visibility of sun internal packages by the compiler and at runtime. I assume it will just cause unmaintained libraries to be substituted by maintained ones, as people trade up to higher quality implementations of functionality they need. Code that uses sun.* classes is a bad smell, to invoke Fowler. If it doesn't get fixed, just get rid of it, and use something else that doesn't stink. cheers, dalibor topic Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions found while running servlet...
Hmm, probably, you should try to set JAVA_HOME=c:\harmony\ On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: I am using the JRE snapshot (I did not build anything, just unpacked a ZIP): pre-alpha : not complete or compatible svn = r428649, (Aug 4 2006), Windows/ia32/msvc 1310, release build This is what I downloaded: * http://people.apache.org/dist/incubator/harmony/snapshots/latest-jre-windows.zip Yes I do have this class: org.apache.harmony.awt.gl.ImageSurface Should I set additional environment variable when starting my process? I am using: set path=c:\harmony\bin;%path% java -jar winstone-0.8.2-cvs.jar --config=./winstone.conf And seems to work fine for most cases, Harmony has only complained about that specific class. Should I include the /lib/boot to the %path%? Regards, Martin On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... Do you use harmony snapshot? I tried to run simple test which creates BufferedImage with aug 04 snapshot and got an UnsatisfiedLinkError instead of it. But absence of the gl.dll in that snapshot is a known issue and likely to be fixed in the next snapshot. Maybe you could try to look into your HARMONY_HOME/lib/boot/awt.jar and check if it includes org.apache.harmony.awt.gl.ImageSurface class? The snapshot has it and there shouldn't be any problems with loading this class. If you built harmony from sources, please consider refreshing awt module and rebuilding with -Dwith.awt.swing=true On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: Is it OK to send this type of feedback to the list? please let me know if not, and what subject conventions should I use (is there a link about this?). I am not a Harmony developer, just a new user, I can only provide feedback from my tests. I am running a small webapp, using Winstone servlet engine and IBM JDK 1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4), and found these exceptions: 1.- I see this error while using servlet includes and also at the end of some pages: java.lang.ArrayIndexOutOfBoundsException: 0..0 at org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java) at org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194) at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647) at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152) at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at java.io.PrintWriter.doWrite(PrintWriter.java:640) at java.io.PrintWriter.write(PrintWriter.java:622) at winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45) at java.io.PrintWriter.write(PrintWriter.java:607) at java.io.PrintWriter.write(PrintWriter.java:657) at java.io.PrintWriter.print(PrintWriter.java:455) at 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... The JDBC related code is running fine, performance also looks very good. I will contact Winstone developer to see if he can help in some way to identify the problem. He already helped me a few months ago to help identify a bug in GNU Classpath server socket API. Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use :
Re: Adding new files to SVN and subsequently trying to update
I use graphical TortoiseSVN client and do not remember much pain with file addition. It seems TortoiseSVN does some part of the stupid job by itself. I believe there should be something like it on *NIX too. Regards, 2006/8/10, Oliver Deakin [EMAIL PROTECTED]: Alex Blewitt wrote: Yeah ... the problem is that unless you do an 'svn add', it doesn't show up when you have an 'svn patch' or similar (see other swearing, ranting etc. about missing files). So, I've got to add, patch, submit, wait, hack/revert, diff each new file I add ... Yeah, if you want the file to appear in the patch, then you've got to add it. Then once you do that you can't update, ugh! I guess you could not do the svn add and just attach the files to the JIRA along with the patch and describe where they should go, but this takes more effort on the part of the committer to put them in the right place and is open to mistakes when writing down the path locations of the files (which can be pretty long in Harmony!). The big problem (for me) is that it effectively means once I've added a new file, I really can't do any new work on it until it's been added, since otherwise any changes I make between filing the patch and having a clean 'svn up' (which I have just got to -- hooray!) are almost certain to be lost in the process. In turn, it means that there's much less of a benefit to me submitting code in smaller chunks, and I might as well just sit on it until I've developed a huge wodge of changes and send them in one go. If you are following the add, create patch, revert, delete, update, diff cycle, then at least you can transfer new changes to the svn versioned file during the diff stage, so you should be able to continue working on the newly added file (even if it is a hassle every time you have to update). I would be great if svn would recognise that the added file in the repo was the same as the one added on your disk and attempt to merge them. There must be someone out there who knows a better way to do this? Regards, Oliver Mind you, it's not like we're working against a deadline here, and I'm happy taking a few days off from thinking about it ... but I'll plan where my breaks are better in terms of functionalitiy in the future. (Any SVN developers on this list want to help figure out how to make this better?) Alex. On 10/08/06, Oliver Deakin [EMAIL PROTECTED] wrote: Just sent my other mail before seeing this one. Rather than manually editing the entries file you can, as I suggest in the other mail, still revert the original file name after you have moved it to a new file. So you could: - move the file to a new name AddedFile.java.bak - svn revert AddedFile.java (this should still work even tho the file is no longer there) - svn up - compare AddedFile.java and AddedFile.java.bak - swear etc. Hope this helps, Oliver Alex Blewitt wrote: OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like entry name=AddedFile.java kind=file schedule=add revision=0/ then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first (chmod +w entries or attrib -r entries) 2d) svn up AddedFile.java (which brings it in) 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the changes are 2f) Delete AddedFile.java.bak since it's no longer necessary. Repeat 2a-2f for as many new files as you've added. Swear, drink caffeinated/alchoholic beverage of your choice, and vow to add as few new files as possible in the future by writing humungous class files. Hope that's useful to anyone else in this position. Alex. On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: Can't even friggin delete it ... apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1541: (apr_err=155000) svn: Failed to add file 'JustResources.pack': object of the same name is already scheduled for addition On 10/08/06, Alex Blewitt [EMAIL PROTECTED] wrote: One thing that annoys me is when I submit new files, and do an update, I get a message: apple[pack200] ls HelloWorld.pack JustResources.pack apple[pack200] svn up subversion/libsvn_wc/update_editor.c:1520: (apr_err=155000) svn: Failed to add
Re: Exceptions found while running servlet...
Unfortunately, imageio is not implemented yet. On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: Oleg: I added that line, but still cannot find the class, the JVM prints this log msg: Loading of javax/imageio/ImageIO class failed due to java/lang/ClassNotFoundException Which JAR should I check to see if this class is contained? Regards, Martin On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: Hmm, probably, you should try to set JAVA_HOME=c:\harmony\ On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: I am using the JRE snapshot (I did not build anything, just unpacked a ZIP): pre-alpha : not complete or compatible svn = r428649, (Aug 4 2006), Windows/ia32/msvc 1310, release build This is what I downloaded: * http://people.apache.org/dist/incubator/harmony/snapshots/latest-jre-windows.zip Yes I do have this class: org.apache.harmony.awt.gl.ImageSurface Should I set additional environment variable when starting my process? I am using: set path=c:\harmony\bin;%path% java -jar winstone-0.8.2-cvs.jar --config=./winstone.conf And seems to work fine for most cases, Harmony has only complained about that specific class. Should I include the /lib/boot to the %path%? Regards, Martin On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... Do you use harmony snapshot? I tried to run simple test which creates BufferedImage with aug 04 snapshot and got an UnsatisfiedLinkError instead of it. But absence of the gl.dll in that snapshot is a known issue and likely to be fixed in the next snapshot. Maybe you could try to look into your HARMONY_HOME/lib/boot/awt.jar and check if it includes org.apache.harmony.awt.gl.ImageSurface class? The snapshot has it and there shouldn't be any problems with loading this class. If you built harmony from sources, please consider refreshing awt module and rebuilding with -Dwith.awt.swing=true On 8/10/06, Martin Cordova [EMAIL PROTECTED] wrote: Is it OK to send this type of feedback to the list? please let me know if not, and what subject conventions should I use (is there a link about this?). I am not a Harmony developer, just a new user, I can only provide feedback from my tests. I am running a small webapp, using Winstone servlet engine and IBM JDK 1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4), and found these exceptions: 1.- I see this error while using servlet includes and also at the end of some pages: java.lang.ArrayIndexOutOfBoundsException: 0..0 at org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java) at org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194) at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647) at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152) at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at java.io.PrintWriter.doWrite(PrintWriter.java:640) at java.io.PrintWriter.write(PrintWriter.java:622) at winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45) at java.io.PrintWriter.write(PrintWriter.java:607) at java.io.PrintWriter.write(PrintWriter.java:657) at java.io.PrintWriter.print(PrintWriter.java:455) at 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... The JDBC related code is running fine, performance also looks very good. I will contact Winstone developer to see if he can help in some way to identify the problem.
Re: [classlib]strings externalization
On 8/10/06, Tim Ellison [EMAIL PROTECTED] wrote: Ilya Okomin wrote: Hi to all! Today I've started the next step of internationalization - to externalize messages using Eclipse externalization tool. Right away I was confronted with some questions to discuss: First of all, what should we do with strings that are not supposed to be internationalized (constants, initiated variables..)? Should we mark them //$NON-NLS-%id%$ comment (Eclipse tool skip such strings during externalization process)? IMHO there is a sence to do this, marked strings will not be taken into account next time externalization revision is required. Objections? No objection -- good idea. Reduces ECJ compiler warnings. Next point, there is a lot of manual work during messages processing (unite messages that are on the several lines of the source code, change messages with params to the proper formatted messages). When doing this work there are changes in source code and messages.properties files are made. Yep, but we can work through them a module at a time or parallel-ise the work depending on how much help we get. It is a good opportunity for people to contribute to Harmony. I would suggest to split this task into a set of jira sub-issues, one module - one issue. This kind of division would give us an opportunity this work to be done in a parallel mode. As it is manual work - some mistakes could be done, non-critical: usually wrong message if getString() takes wrong key as a parameter. Is there supposed a verification that everything is done well? May be any test cases (at the moment I have no idea how these test cases may look) or another revision? Probably the better strategy is to wait if someone who face with wrong message will inform about that:) Thoughts? We don't have any tests that would catch this at the moment. So unless there are any ideas we have to rely on steady working and peer reviews of the patches and commits. As you point out we would expect it to be noticeable at the point the message is displayed if it were incorrect. The easiest way;-) I'm sure, there will be not so many such exceptional cases. And the last one point. I think the process of internationalization support must be up-to-date, for this reason after adding new contributions all messages there are to be internationalized. Probably there is a sence to make rule to do this routinely after contribution is applied (or even before, people who are going to make contribution should be acquainted with internationalization in Harmony to use it in their development process). Yes, once you have figured out the APIs and a couple of examples it would be good to add it as a document to the coding practices. I'm not sure I would reject a patch for non-compliance, but the compiler warnings will remind us to go in and fix it. I'll prepare useful exapmles to support chosen way to internationalize messages. Tim, thank you for comments, no it is clear what to do next. Regards, Ilya. Waiting for comments and suggestions! Sorry they were so late! Regards, Tim On 8/2/06, Ilya Okomin [EMAIL PROTECTED] wrote: On 7/27/06, Tim Ellison [EMAIL PROTECTED] wrote: Ilya Okomin wrote: I share your point of view about Exceptions without description, it isn't user friendly. But I think it will be another sort of 'manual' scan :) There is a need to waste time to analyze surrounding code to provide appropriate message, a bit another sort of work, isn't it? I think the best way would be if all these Exceptions without info are being identified before externalization process is to be ran. For today I'd better postpone the task of initialization 'empty' exceptions until the externalization is finished. Sure, I agree that it is a different problem, so have no problem dealing with it separately. I've implemented a small tool that generates Message source and MsgHelp source into a desired module. Tool gets a list of modules names from property file (you can specify modules class sources to generate for), then we run over the list and special word 'module' in Message and MsgHelp source templates files replaced with the specified module name. Cool. You may find it easy to do this using Ant's replace task [1]. [1] http://ant.apache.org/manual/CoreTasks/replace.html Resulting sources are copied to the o/a/h/module/internal/ directory. At first I planned to use MsgHelp class from luni but after a while I've decided to avoid dependency on luni module and included generation source file of this class to every module. I agree, if you are going to do the template then you might as well duplicate the MsgHelp behavior across the modules. In fact, don't feel obliged to maintain the separation of Message and MsgHelp, you may find that it makes sense to combine them now. Your choice. Thus Message or MsgHelp source files can be easy regenerated for a
Re: [general] platform support
**Using SetUnhandledExceptionFilter API call we can handle hardware NPE for Win2k too. The only problem is debbuging of applications with exception filter installed. AFAIK debugger will catch all of these events. On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: The SWT FAQ mentions that the same issue, and recommends the following GDI+ redistributable from Microsoft: Good, so GDI+ is not a problem! -- Mikhail Fursov
Re: [general] platform support
+ This public document I've found with Google proves that SetUnhandledExceptionFilter is a real candidate for Win2k and production level VM http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: **Using SetUnhandledExceptionFilter API call we can handle hardware NPE for Win2k too. The only problem is debbuging of applications with exception filter installed. AFAIK debugger will catch all of these events. On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: The SWT FAQ mentions that the same issue, and recommends the following GDI+ redistributable from Microsoft: Good, so GDI+ is not a problem! -- Mikhail Fursov -- Mikhail Fursov
Re: [testing] metadata approach
Alexei Zakharov wrote: We now have this, so let the TestNG debate continue :) Unfortunately, we still need java.util.concurrent :-( Yeah, TestNG 5.0 still throws java.lang.NoClassDefFoundError : java.util.concurrent.LinkedBlockingQueue on Harmony+j9v4. So perhaps the build system should be changed temporarily so that we dont self host the test harness? i.e. until we get java.util.concurrent, run Ant and the subsequent TestNG process with RI or other non-Harmony VM, and launch the tests with Harmony VM using the jvm option. At least it will allow us to move forward with TestNG (if that's what we decide) without having to wait for java.util.concurrent. Then when we have j.u.c, start self-hosting again. Comments? I've also got an error while trying to compile TestNG 5.0 tests with Harmony+j9v4+ecj: The method getId() is undefined for the type Thread That's odd - Thread.class in luni-kernel (VME v4) definitely contains a getId() method. I don't know anything about the TestNG tests - how are they run? is luni-kernel.jar definitely at the front of the bootclasspath? - If we go ahead with TestNG, we need to select a set of group names to use to indicate exclusion, platform specificness etc. Don't you like the names suggested by George? I do like them - in fact I was going to link his mail after that point but couldn't find it. I really mean that we should make sure that everyone is happy with a certain set of group names before going ahead and applying them. Once they are decided upon, they should be added to the testing conventions webpage. - Decide whether some physical separation of tests on disk is necessary, for instance to separate classpath and bootclasspath tests IMHO it is ok to separate classpath and bootclasspath tests because it will be easer to implement such solution technically. I agree, although I don't feel strongly about it. Regards, Oliver Regards, 2006/8/10, Richard Liang [EMAIL PROTECTED]: Oliver Deakin wrote: Richard Liang wrote: Alexei Zakharov wrote: Hi Richard, Not sure if we really want to involve another migration: TestNG javadoc - TestNG annotation. Any comments? Well, IMHO this depends on time constraints - when do we plan to have the support for anotations? If the answer is about a couple of weeks - no problem, we can wait. But if this is several months... About the migration - I don't think this will be a real painfull migration, all infrastructure will remain the same. We will only need to convert javadocs to annotations (one-one correspondence) and this task can be easily automated. Sounds reasonable. :-) Maybe drlvm guys or Oliver could tell us when we will have a VM with annotation support? We now have this, so let the TestNG debate continue :) Unfortunately, we still need java.util.concurrent :-( I guess we need to decide a few things before we go ahead with this: - Whether TestNG is generally accepted by the Harmony community as our test harness of choice for unit testing. I think this will probably require a vote of some kind before we could make the move. - If we go ahead with TestNG, we need to select a set of group names to use to indicate exclusion, platform specificness etc. - Decide whether some physical separation of tests on disk is necessary, for instance to separate classpath and bootclasspath tests. Comments/additions? Agree. And we could provide proposals for these questions case by case, and let community make decision. Best regards, Richard Regards, Oliver Thanks, 2006/8/1, Richard Liang [EMAIL PROTECTED]: Alexei Zakharov wrote: Hi, I have created this new thread as a single place for discussions started in Re: [testing] Peace and [classlib] Testing conventions – a proposal threads. What did we have in the previous threads? * Test classification proposed by Vladimir * Test classification and group names proposed by George * Solution for Ant and TestNG scripting issues (still being discussed) Since a lot of people are asking about TestNG and wanting TestNG I decide to put some effort and take a closer look at this piece of software. Thus during the last few days I was playing with TestNG - I tried to run different kind of tests with it, to perform various workloads, generate reports in different ways and etc. The purpose of all this activity was to try TestNG in a real work, understand is TestNG really worth our credits and how expensive can be moving to TestNG from our currently implemented testing infrastructure. Now I have some thoughts and facts I'd like to share with the community. I've put it in the form of list for convenience. * TestNG works ok in normal conditions, no visible bugs * It is possible to define and use various (possibly intersecting) test groups with TestNG * TestNG-style metadata is more convenient than JUnit test suites (now I agree with this statement). IMHO this is the
Re: [general] platform support
This public document I've found with Google proves that SetUnhandledExceptionFilter is a real candidate for Win2k and production level VM It says also that VM would wrap all JNI and thread start calls into __try/__except. This is exactly what Gregory complained about. On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: + This public document I've found with Google proves that SetUnhandledExceptionFilter is a real candidate for Win2k and production level VM http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: **Using SetUnhandledExceptionFilter API call we can handle hardware NPE for Win2k too. The only problem is debbuging of applications with exception filter installed. AFAIK debugger will catch all of these events. On 8/10/06, Oleg Khaschansky [EMAIL PROTECTED] wrote: The SWT FAQ mentions that the same issue, and recommends the following GDI+ redistributable from Microsoft: Good, so GDI+ is not a problem! -- Mikhail Fursov -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plans to implement javax/imageio/ImageIO?
Is there a planned release for this class? It seems that I just can't use popular libraries like JFreeChart without it. Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new files to SVN and subsequently trying to update
I use TortoiseSVN also - I just tested it out by creating a dummy modules\tools\src\main\java\org\apache\harmony\tools\keytool\KeyCertGenerator.java file and trying to update to pick up Mikhails latest changes (which add this file to the repository). Unfortunately TortoiseSVN gives me an error stating object of the same name already exists. If I delete the file and then try to update, I get another error stating object of the same name is already scheduled for addition, so it looks like I still have to revert before the update, even with TortoiseSVN. Regards, Oliver Alexei Zakharov wrote: I use graphical TortoiseSVN client and do not remember much pain with file addition. It seems TortoiseSVN does some part of the stupid job by itself. I believe there should be something like it on *NIX too. Regards, 2006/8/10, Oliver Deakin [EMAIL PROTECTED]: Alex Blewitt wrote: Yeah ... the problem is that unless you do an 'svn add', it doesn't show up when you have an 'svn patch' or similar (see other swearing, ranting etc. about missing files). So, I've got to add, patch, submit, wait, hack/revert, diff each new file I add ... Yeah, if you want the file to appear in the patch, then you've got to add it. Then once you do that you can't update, ugh! I guess you could not do the svn add and just attach the files to the JIRA along with the patch and describe where they should go, but this takes more effort on the part of the committer to put them in the right place and is open to mistakes when writing down the path locations of the files (which can be pretty long in Harmony!). The big problem (for me) is that it effectively means once I've added a new file, I really can't do any new work on it until it's been added, since otherwise any changes I make between filing the patch and having a clean 'svn up' (which I have just got to -- hooray!) are almost certain to be lost in the process. In turn, it means that there's much less of a benefit to me submitting code in smaller chunks, and I might as well just sit on it until I've developed a huge wodge of changes and send them in one go. If you are following the add, create patch, revert, delete, update, diff cycle, then at least you can transfer new changes to the svn versioned file during the diff stage, so you should be able to continue working on the newly added file (even if it is a hassle every time you have to update). I would be great if svn would recognise that the added file in the repo was the same as the one added on your disk and attempt to merge them. There must be someone out there who knows a better way to do this? Regards, Oliver Mind you, it's not like we're working against a deadline here, and I'm happy taking a few days off from thinking about it ... but I'll plan where my breaks are better in terms of functionalitiy in the future. (Any SVN developers on this list want to help figure out how to make this better?) Alex. On 10/08/06, Oliver Deakin [EMAIL PROTECTED] wrote: Just sent my other mail before seeing this one. Rather than manually editing the entries file you can, as I suggest in the other mail, still revert the original file name after you have moved it to a new file. So you could: - move the file to a new name AddedFile.java.bak - svn revert AddedFile.java (this should still work even tho the file is no longer there) - svn up - compare AddedFile.java and AddedFile.java.bak - swear etc. Hope this helps, Oliver Alex Blewitt wrote: OK, so for anyone else reading this thread (or googling for 'object of the same name already exists'): 1) If it's a case insensitive filing system (e.g. Windows) then see the Subversion FAQ: http://subversion.tigris.org/faq.html 2) If it's a case senstive filing system, and the case is right, and you're adding a new file to an open-source project and someone's already committed that and you're trying to update to pretty much the same file: 2a) Move the old file to a new name (e.g. mv AddedFile.java AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) 2b) Go into the .svn directory, and open up the file 'entries' 2c) Where there is an entry like entry name=AddedFile.java kind=file schedule=add revision=0/ then delete it from the entries file. It may well be marked as read-only, so you'll either have to edit it on something that ignores the readonly flag or mark it r/w first (chmod +w entries or attrib -r entries) 2d) svn up AddedFile.java (which brings it in) 2e) Diff AddedFile.java AddedFile.java.bak if you want to see what the changes are 2f) Delete AddedFile.java.bak since it's no longer necessary. Repeat 2a-2f for as many new files as you've added. Swear, drink caffeinated/alchoholic beverage of your choice, and vow to add as few new files as possible in the future by writing humungous class files. Hope that's useful to anyone else in this position.
[classlib] [ldap] support for multiple VMs?
Hi all, We are working on the javax.naming.ldap and we are facing the following issue when thinking about supporting multiple VMs. Following the SPEC there is a method createExtendedResponse in the StartTlsRequest class which states that the returning object must be an instance of a concrete subclass of StartTlsResponse and must have a public zero-argument constructor. The concrete subclass is determined by reading the configuration file located in META-INF/services/javax.naming.ldap.StartTlsResponse (see http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) The search for this configuration file is done by looking in the classpath, java.home and user.dir; also the Xbootclasspath should be inspected, and that seems to be a problematic situation, since there is not a standard property to look for its value. Different VM implementations have different property names for the boot class path value. In the old Harmony VM implementation was com.ibm.oti.system.class.path; in the new one is org.apache.harmony.boot.class. The property name in the Sun's VM is sun.boot.class.path. We are wondering which property name to use in the code. At first sight the Harmony new VM implementation property seems to be the better option, but maybe looking for the other properties will be interesting for compatibility purposes. We would be very interested in opinions. Thanks, Daniel
Re: [testing] metadata approach
Hi Oliver,
So perhaps the build system should be changed temporarily so that
we dont self host the test harness? i.e. until we get java.util.concurrent,
run Ant and the subsequent TestNG process with RI or other non-Harmony
VM, and launch the tests with Harmony VM using the jvm option.
The bad news is that TestNG requires j.u.c stuff even for single test
execution (i.e. in any case if jvm=path to harmony). :( So if we
want to run annotated tests with TestNG (even from the command line)
we need j.u.c.
That's odd - Thread.class in luni-kernel (VME v4) definitely contains a
getId() method.
May be I did something wrong - I will check tomorrow.
I do like them - in fact I was going to link his mail after that point
but couldn't find it.
Here is the link:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
As far as I remember there was additions to the George's list like
using @Test (groups={os.any} ) rather than simple @Test for API
tests that run on any platform.
I really mean that we should make sure that everyone is happy with
a certain set of group names before going ahead and applying them.
Once they are decided upon, they should be added to the testing
conventions webpage.
Yes, agree.
With Best Regards,
2006/8/10, Oliver Deakin [EMAIL PROTECTED]:
Alexei Zakharov wrote:
We now have this, so let the TestNG debate continue :)
Unfortunately, we still need java.util.concurrent :-(
Yeah, TestNG 5.0 still throws java.lang.NoClassDefFoundError :
java.util.concurrent.LinkedBlockingQueue on Harmony+j9v4.
So perhaps the build system should be changed temporarily so that
we dont self host the test harness? i.e. until we get java.util.concurrent,
run Ant and the subsequent TestNG process with RI or other non-Harmony
VM, and launch the tests with Harmony VM using the jvm option.
At least it will allow us to move forward with TestNG (if that's what we
decide) without having to wait for java.util.concurrent. Then when
we have j.u.c, start self-hosting again.
Comments?
I've also got an error while trying to compile TestNG 5.0 tests with
Harmony+j9v4+ecj: The method getId() is undefined for the type Thread
That's odd - Thread.class in luni-kernel (VME v4) definitely contains a
getId() method. I don't know anything about the TestNG tests - how are
they run? is luni-kernel.jar definitely at the front of the bootclasspath?
- If we go ahead with TestNG, we need to select a set of group names
to use to indicate exclusion, platform specificness etc.
Don't you like the names suggested by George?
I do like them - in fact I was going to link his mail after that point
but couldn't
find it. I really mean that we should make sure that everyone is happy with
a certain set of group names before going ahead and applying them.
Once they are decided upon, they should be added to the testing
conventions webpage.
- Decide whether some physical separation of tests on disk is
necessary, for instance to separate classpath and bootclasspath tests
IMHO it is ok to separate classpath and bootclasspath tests because it
will be easer to implement such solution technically.
I agree, although I don't feel strongly about it.
Regards,
Oliver
Regards,
2006/8/10, Richard Liang [EMAIL PROTECTED]:
Oliver Deakin wrote:
Richard Liang wrote:
Alexei Zakharov wrote:
Hi Richard,
Not sure if we really want to involve another migration: TestNG
javadoc
- TestNG annotation. Any comments?
Well, IMHO this depends on time constraints - when do we plan to
have
the support for anotations? If the answer is about a couple of
weeks -
no problem, we can wait. But if this is several months...
About the migration - I don't think this will be a real painfull
migration, all infrastructure will remain the same. We will only
need
to convert javadocs to annotations (one-one correspondence) and this
task can be easily automated.
Sounds reasonable. :-) Maybe drlvm guys or Oliver could tell us when
we will have a VM with annotation support?
We now have this, so let the TestNG debate continue :)
Unfortunately, we still need java.util.concurrent :-(
I guess we need to decide a few things before we go ahead with this:
- Whether TestNG is generally accepted by the Harmony community
as our test harness of choice for unit testing. I think this will
probably
require a vote of some kind before we could make the move.
- If we go ahead with TestNG, we need to select a set of group names
to use
to indicate exclusion, platform specificness etc.
- Decide whether some physical separation of tests on disk is
necessary,
for instance to separate classpath and bootclasspath tests.
Comments/additions?
Agree. And we could provide proposals for these questions case by case,
and let community make decision.
Best regards,
Richard
Regards,
Oliver
Thanks,
2006/8/1, Richard Liang [EMAIL PROTECTED]:
Re: [general] platform support
Hi Mikhail, As far as I know, SetUnhandledExceptionFilter was introduced as a backdoor method in in Win2K SP4 to get around the problem that the SEH handlers are limited to the frame and not process wide. It does handle problems like NPE and AV, but as you point out, it works by hijacking the first and last chance debugger handlers. So, unlike VEH which are fully functional when debugging, these SetUnhandled...filters are not visible when debugging. I also believe that they execute in the context of the current thread, which means that they are not so good to handle stack corruption, SOE etc. which we are currently using VEH. Since one does not expect them to be used on the newer Windows boxes, the .Net framework overwrites them ...which means that any process that loads a Microsoft dll that has any Microsoft managed code in it ( and many do ), is at a risk that the SetUnhandled.. may or may not work. I think that SetUnhandled..was a great(probably only ) solution on the Win2K boxes, but VEH was put in place to solve some of its limitations. The bottom line is that one needs to experiment with this on several Windows boxes before we know how good or bad it is. I myself don't have a lot of experience with it. Thanks, Rana On 8/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: **Using SetUnhandledExceptionFilter API call we can handle hardware NPE for Win2k too. The only problem is debbuging of applications with exception filter installed. AFAIK debugger will catch all of these events.
Re: [classlib][drlvm] integrating j.u.c with drlvm
Nathan, I created ISSUE#*1144, https://issues.apache.org/jira/browse/HARMONY-1144* Please try the patches attached. --bwR
Re: BASE64Encoder class missing?
Alex Blewitt wrote: On 10/08/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Anthony Green wrote: On Wed, 2006-08-09 at 17:58 -0400, Geir Magnusson Jr wrote: Yes- the idea is to provide that suncompat.jar for that reason with those clases in the sun.* namespace that user apps depend on. This way lies madness. I urge you to take a strong stand against bad applications. Oh, don't get me wrong - we really want to. But we want adoption of the harmony codebase as well. We think that we have a reasonable balance - provide the functionality in an separable, modular way at first to make it easy for people to try and adopt harmony. May I suggest that we try and: 1) Make available a suncompat.jar, which re-writes calls to o.a.h or similar (or subclasses them ...) 2) Explicitly don't make it part of the default classpath ala 'tools.jar' in the standard Sun implementation when running HarmonyVM code 3) Put up a FAQ saying that 'If you depend on e.g. sun.*, stick the suncompat in the classpath' That way, out-of-the-box we don't have it, but there's an easy fix for people who trip up over it. However, if people just need to get it running, then they have a trivial workaround that doesn't involve changing their code. The same could also be provided for code that depends on sun.JavaC or whatever ... I still think we should - for now - include suncompat.jar by default, because we generally only get one first impression with people, and when people's programs break on harmony - *even if it's their fault* - there's reasonable chance that people will not look closely, decide it's our fault, and move on. I think that we need to take a 'soft' and supportive approach here... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BASE64Encoder class missing?
Agreed. That is what I meant when I asked what we could wrap... geir Paulex Yang wrote: FYI, Harmony has already a o.a.h.luni.util.Base64 utility in LUNI module, which is used by HttpURLConnection, IMO it would be nice to just choose one implementation to use across all the project. Geir Magnusson Jr wrote: I assume it's something we'd just want to copy, rather than add a dependency geir Matt Benson wrote: commons-codec and Ant both have base64 encoders AFAIK. -Matt --- Geir Magnusson Jr [EMAIL PROTECTED] wrote: Martin Cordova wrote: Hi, I am testing the latest Harmony JRE (Aug-4-06) with a servlet engine on Windows XP SP2. The first obstacle I hit was related to the use of sun/misc/BASE64Encoder I got a java.lang.NoClassDefFoundError exception. Is there a workaround? was this class located under a different package? Not yet. We were discussing this earlier. Problem obviously is that the code is using sun specific code. I think that we should probably do this as well as we've discussed, sooner rather than later : 1) add a new module suncompat to make it clear what it is 2) have it produce a suncompat.jar that we include by default. 3) make users happy Anyone want to take a stab at this? I assume we have a base64 encoder we can wrap? geir Thanks a lot. Martin Cordova - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions found while running servlet...
Martin Cordova wrote: Is it OK to send this type of feedback to the list? ABSOLUTELY! please let me know if not, and what subject conventions should I use (is there a link about this?). I am not a Harmony developer, just a new user, I can only provide feedback from my tests. This stuff is really valuable to us. Thanks for taking the time to dig down and give us this info. As for subject line... maybe [bug] ? geir I am running a small webapp, using Winstone servlet engine and IBM JDK 1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4), and found these exceptions: 1.- I see this error while using servlet includes and also at the end of some pages: java.lang.ArrayIndexOutOfBoundsException: 0..0 at org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java) at org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194) at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647) at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89) at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152) at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at java.io.PrintWriter.doWrite(PrintWriter.java:640) at java.io.PrintWriter.write(PrintWriter.java:622) at winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45) at java.io.PrintWriter.write(PrintWriter.java:607) at java.io.PrintWriter.write(PrintWriter.java:657) at java.io.PrintWriter.print(PrintWriter.java:455) at 2.- Trying to generate charts using JFreeCharts (server-side): java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface at java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659) at java.awt.image.BufferedImage.init(BufferedImage.java:352) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193) at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)... The JDBC related code is running fine, performance also looks very good. I will contact Winstone developer to see if he can help in some way to identify the problem. He already helped me a few months ago to help identify a bug in GNU Classpath server socket API. Regards, Martin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Dalibor Topic wrote: On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: Dalibor Topic wrote: On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. Hardly. Many replacements for Base64 exists, for example GNU Classpath recommends using Apache Commons Codec for projects compatible with the Apache license. Amateur developers use non-standard classes because they are too lazy to think for themselves, and accordingly copy broken code around projects. Alas, a language designed to appeal to the masses naturally attracts a lot of people who'd have trouble producing portable code in any programming language. :) I was being charitable. For sure many such usages can be easily avoided, but in other cases no so easily; like CharToByteConverter would require duplicating a wad of data, and I don't know of any third-party impl. of Unsafe. Is there something that CharToByteConverter does that CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen code using CharToByteConverter in years. Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks to the JVM JSR not being ahead thinking enough to specify an API for low-level operations. It may or may not work depedending on how a VM interprets the non-existent spec for that class, so it is practically useless, unless it is running on the VM it was written on, i.e. Sun's. It may or may not work by chance, rather than by virtue. I think you are being too harsh here, but that notwithstanding, one of the things we can do as open implementations is petition the EG to actually define these in the spec once we show that there's a good reason to do so, namely the independent implementations. That holds in general for any code using implementation-specific interfaces. We should appeal to app developers to change implementation dependent code (even provide a recipe book of recommended solutions), but be pragmatic about the need to run the current version. In many cases it may be beyond the apps immediate sphere of influence (i.e. dependent libraries). If everyone responded as quickly and effectively as Martin we would have no worries. We've been doing that for years. See the GNU Classpath migration page in the Wiki that describes how to fix such broken code in many cases. Being 'pragmatic' solves nothing, it just encourages people to continue behaving in dumb ways, because their code still may run, somehow, even if there is no way for Harmony to ensure that it will behave as they expect from whatever buggy Sun JDK they are using to run it usually in the corner cases, because there is no spec, and there are no tests. Awarding incompetence doesn't solve the problem. That being said, kudos to Martin for fixing the bug in his code. Had we had a Base64 class, that bug wouldn't have showed up, and his code would have failed elsewhere, or behaved differently on another VM. With the fix, his code is portable, behaves in the same way on any VM, and may even be faster than a vm-specific 'just for compatibility' implementation. There is no downside to simply fixing the buggy code. Sure, but again, not everyone will be as wise as Martin - they'll just bail on us. They may even realize that there's a problem with their code, but there may be nothing they can do about it. On a side note, I seem to recall reading on Sun's javac engineer's blog that javac won't allow access to sun internal classes sooner or later, so idiot-proofing class libraries may not be very useful, anyway, as people will have to rewrite such code, or preferrably, throw it away. It will be interesting to see what havoc is unleashed by attempts to reduce the visibility of sun internal packages by the compiler and at runtime. I assume it will just cause unmaintained libraries to be substituted by maintained ones, as people trade up to higher quality implementations of functionality they need. Code that uses sun.* classes is a bad smell, to invoke Fowler. If it doesn't get fixed, just get rid of it, and use something else that doesn't stink. Yah, but I think it's insane to enforce restrictions on one company's package namespace in the compiler. This should be a general feature :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Our locale data is incomplete, and Locale(, CD).getDisplayCountry() return different string compared with ISO3166-1
What does IBM and BEA do? Did they fix this?
geir
Ilya Okomin wrote:
On 8/10/06, Spark Shen [EMAIL PROTECTED] wrote:
2006/8/10, Richard Liang [EMAIL PROTECTED]:
Spark Shen wrote:
Hi All:
Construct a locale like this:
Locale l = new Locale(, CD);
On RI, l.getDisplayCountry() will return The Democratic Republic Of
Congo,
which is different from ISO 3166-1 standard.
(CONGO, THE DEMOCRATIC REPUBLIC OF THE or Congo, the Democratic
Republic
of the)
IMHO, we may follow the Java Specification, that is, ISO-3166. Do you
think user applications would be broken because of the difference with
RI.
I am not sure. But this may be a risk.
To follow ISO-3166 standard mentioned in the spec sounds better and
logical but...if you take a look on other several words country names you
can find that they are not the same on RI than in the ISO-3166. E.g.:
new Locale(, KP);
ISO-3166 expected value: Korea, Democratic People's Republic of
RI returns: North Korea
new Locale(, MK);
ISO-3166 expected value: Macedonia, the former Yugoslav Republic of
RI returns: Macedonia
..and so on.
IMO in this case to be compatible with RI we can use The Democratic
Republic Of Congo for CD country. To follow completely the ISO-3166
standard we have to make changes not only for CD country.
Thanks,
Ilya.
Best regards
Richard.
Mean while, on harmony, we do not have a country CD-CONGO, THE
DEMOCRATIC REPUBLIC OF THE data item or a
CD- Congo, the Democratic Republic of
the http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
data item at all.
This test case will fail on Harmony since the returned displayCountry
is
CD.
public void test_getDisplayCountry() {
Locale l_countryCD = new Locale(, CD);
assertEquals(CONGO, THE DEMOCRATIC REPUBLIC OF THE,
l_countryCD.getDisplayCountry());
}
I need to add a mapping into harmony locale data. But which?
CD-CONGO, THE DEMOCRATIC REPUBLIC OF THE
or
CD-Congo, the Democratic Republic of the
or
CD-The Democratic Republic Of Congo (RI)
Personally, I prefer RI, since there may be applications relies on
the
returned displayCountry value. Your opinions?
Best regards
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Spark Shen
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][suncompat] created
Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. geir Alex Blewitt wrote: Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Alex Blewitt wrote: OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Our locale data is incomplete, and Locale(, CD).getDisplayCountry() return different string compared with ISO3166-1
I'm for doing what we need to do to ensure that user apps don't break.
If IBM, BEA and Sun all do the 'broken' thing, and it isn't
unreasonable, then we should do as well and note it in our differences
from spec' list
geir
Spark Shen wrote:
2006/8/10, Alex Blewitt [EMAIL PROTECTED]:
I think we should follow the ISO-3166 standard for everything; after
all, that's the point of the standard :-) If the RI has bugs in, then
fair enough, but the point of the ISO codes is to have a standard way
of referencing it (CD) -- how it appears on displays shouldn't be
important, and you shouldn't have code that depends on the display
name when you've got the ISO code ...
It's much easier to be strict about it now (and fix bugs as they get
found in other apps) than to be lax now and try and add strictness
later. So I'd say, let's go with the ISO-3166 for everything.
Alex.
On 10/08/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 8/10/06, Spark Shen [EMAIL PROTECTED] wrote:
2006/8/10, Richard Liang [EMAIL PROTECTED]:
Spark Shen wrote:
Hi All:
Construct a locale like this:
Locale l = new Locale(, CD);
On RI, l.getDisplayCountry() will return The Democratic Republic
Of
Congo,
which is different from ISO 3166-1 standard.
(CONGO, THE DEMOCRATIC REPUBLIC OF THE or Congo, the
Democratic
Republic
of the)
IMHO, we may follow the Java Specification, that is, ISO-3166. Do
you
think user applications would be broken because of the difference
with
RI.
I am not sure. But this may be a risk.
To follow ISO-3166 standard mentioned in the spec sounds better and
logical but...if you take a look on other several words country names
you
can find that they are not the same on RI than in the ISO-3166. E.g.:
new Locale(, KP);
ISO-3166 expected value: Korea, Democratic People's Republic of
RI returns: North Korea
new Locale(, MK);
ISO-3166 expected value: Macedonia, the former Yugoslav Republic of
RI returns: Macedonia
..and so on.
IMO in this case to be compatible with RI we can use The Democratic
Republic Of Congo for CD country. To follow completely the ISO-3166
standard we have to make changes not only for CD country.
Thanks,
Ilya.
Emm, now two are for being compliance with RI, one for spec. :-)
There is a concern that we may eliminate all locale related information
maintained in Harmony itself,
but uses a third party component, say ICU4J to manage all these data. And I
guess if people get agreed on that
scheme, all these argument may shift to that component related threads.
Best regards
Best regards
Richard.
Mean while, on harmony, we do not have a country CD-CONGO,
THE
DEMOCRATIC REPUBLIC OF THE data item or a
CD- Congo, the Democratic Republic of
the
http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
data item at all.
This test case will fail on Harmony since the returned
displayCountry
is
CD.
public void test_getDisplayCountry() {
Locale l_countryCD = new Locale(, CD);
assertEquals(CONGO, THE DEMOCRATIC REPUBLIC OF THE,
l_countryCD.getDisplayCountry());
}
I need to add a mapping into harmony locale data. But which?
CD-CONGO, THE DEMOCRATIC REPUBLIC OF THE
or
CD-Congo, the Democratic Republic of the
or
CD-The Democratic Republic Of Congo (RI)
Personally, I prefer RI, since there may be applications
relies on
the
returned displayCountry value. Your opinions?
Best regards
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Spark Shen
China Software Development Lab, IBM
--
--
Ilya Okomin
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
Anton Luht wrote: Hello, DRLVM has an (undocumented?) option to switch off verifier -Dvm.use_verifier=false . With this option activemq starts without crash. Verifier seem to be the blocker. Aw... I was hoping you'd tell us what the problem was. Any clue? geir On 8/8/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Gregory Shimansky wrote: On Tuesday 08 August 2006 00:01 Geir Magnusson Jr wrote: Ok - I made that fix and still seem to have a problem, even after a clean rebuild. I guess I should figure out how to turn on the trace... The problem is that class loader does not chain VerifyError to NoClassDefFoundError so debugging such problems is diffucult without tracing. I think this is a place for improvement in drlvm. I tried to fix the problem and found out that verifier just doesn't understand exception handlers which point to the code length address (code end + 1). It is a surprise that this problem didn't appear earlier. App-oriented testing... :) My patch attached to JIRA attempts to fix the problem in verifier only, the application still fails to start. In default mode it exits silently, I didn't find any exception logs or something. When using interpreter -Xint it fails with ArrayStoreException still without any stack trace. I'll try to find out what is happening. Nice work. Thanks for doing this... geir Anton Luht wrote: Hello, The problem is with verifier. The code in Verifier.cpp: if( ( start_pc = len ) || ( end_pc = len ) || ( handler_pc = len ) ) ... result = VER_ErrorHandler; I've modified error logging a bit to log values of start_pc, end_pc, handler_pc and len and that's the output: Loading message broker from: xbean:activemq.xml vf_debug: VerifyError: (class: edu/emory/mathcs/backport/java/util/concurrent/lo cks/ReentrantLock$NonfairSync, method: lockInterruptibly()V, len: 103, start_pc: 87, end_pc: 103, handler_pc: 21) Handler pc is out of range vf_debug: verifying class edu/emory/mathcs/backport/java/util/concurrent/locks/R eentrantLock (method init()V) couldn't load class edu/emory/mathcs/backport/j ava/util/concurrent/locks/ReentrantLock$NonfairSync vf_debug: VerifyError: edu/emory/mathcs/backport/java/util/concurrent/locks/Reen trantLock$NonfairSync Failed to execute main task. Reason: java.lang.NoClassDefFoundError: edu/emory/m athcs/backport/java/util/concurrent/locks/ReentrantLock$NonfairSync I'm not an expert in verification but seems like end_pc = len should be replaced with end_pc len On 8/5/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Anyone interested? :) - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][summary] Exception throwing compatibility
Richard Liang wrote: Tim Ellison wrote: We don't have such a JIRA category: If we decide to follow RI, we will raise an Non-bug differences from Spec JIRA. Yes. Just thinking about whether we need this category :-) Yes. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote: Dalibor Topic wrote: On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: Dalibor Topic wrote: On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: The problem is Base64 functionality is unavailable through the standard API, so people have a choice either use unportable sun.*, o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. Hardly. Many replacements for Base64 exists, for example GNU Classpath recommends using Apache Commons Codec for projects compatible with the Apache license. Amateur developers use non-standard classes because they are too lazy to think for themselves, and accordingly copy broken code around projects. Alas, a language designed to appeal to the masses naturally attracts a lot of people who'd have trouble producing portable code in any programming language. :) I was being charitable. For sure many such usages can be easily avoided, but in other cases no so easily; like CharToByteConverter would require duplicating a wad of data, and I don't know of any third-party impl. of Unsafe. Is there something that CharToByteConverter does that CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen code using CharToByteConverter in years. Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks to the JVM JSR not being ahead thinking enough to specify an API for low-level operations. It may or may not work depedending on how a VM interprets the non-existent spec for that class, so it is practically useless, unless it is running on the VM it was written on, i.e. Sun's. It may or may not work by chance, rather than by virtue. I think you are being too harsh here, but that notwithstanding, one of the things we can do as open implementations is petition the EG to actually define these in the spec once we show that there's a good reason to do so, namely the independent implementations. The independant implementations are not using sun.misc.Unsafe. Why would anyone want to use an undocumented implementation-specific class from another implementation in their own? That makes no sense. There is no point in petitioning the EC to specify sun.misc.Unsafe since no one in their right mind uses it, except Sun, in the interna of their implementation. That's like asking the EC to specify org.kaffe.util.Ptr, or something equivalently pointless from DLRVM. What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, with a sane API that does not require computing field offsets manually, like sun.misc.Unsafe seems to do. ;) The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather simple bug in Doug Lea's java.util.concurrent implementation: using Sun-specific classes directly, rather than delegating to some java.util.concurrent.VMCompareAndSwap interface layer. That means anyone adopting the code needs to repeat the mistakes of Sun's implementation (which has, coincidentally, had a very straightforward remote execution exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. Yay. :/ Other than Doug's code, sun.misc.Unsafe does not matter at all, unless you want remote-execution-exploit-for-remote-execution-exploit compatibility. I believe that's too much to ask for. ;) That holds in general for any code using implementation-specific interfaces. We should appeal to app developers to change implementation dependent code (even provide a recipe book of recommended solutions), but be pragmatic about the need to run the current version. In many cases it may be beyond the apps immediate sphere of influence (i.e. dependent libraries). If everyone responded as quickly and effectively as Martin we would have no worries. We've been doing that for years. See the GNU Classpath migration page in the Wiki that describes how to fix such broken code in many cases. Being 'pragmatic' solves nothing, it just encourages people to continue behaving in dumb ways, because their code still may run, somehow, even if there is no way for Harmony to ensure that it will behave as they expect from whatever buggy Sun JDK they are using to run it usually in the corner cases, because there is no spec, and there are no tests. Awarding incompetence doesn't solve the problem. That being said, kudos to Martin for fixing the bug in his code. Had we had a Base64 class, that bug wouldn't have showed up, and his code would have failed elsewhere, or behaved differently on another VM. With the fix, his code is portable, behaves in the same way on any VM, and may even be faster than a vm-specific 'just for compatibility' implementation. There is no downside to simply fixing the buggy code. Sure, but
Re: [classlib][luni] Our locale data is incomplete, and Locale(, CD).getDisplayCountry() return different string compared with ISO3166-1
Geir Magnusson Jr 写道:
I'm for doing what we need to do to ensure that user apps don't break.
If IBM, BEA and Sun all do the 'broken' thing, and it isn't
unreasonable,
I tried the following statement on IBM JDK 1.4:
System.out.println(new Locale(, CD).getDisplayCountry());
And the displayed message is:
The Democratic Republic Of Congo
The same as SUN JDK 1.5, that is to say, IBM do the 'broken' thing. And
I think I agree with the point:
then we should do as well and note it in our differences
from spec' list
Best regards
geir
Spark Shen wrote:
2006/8/10, Alex Blewitt [EMAIL PROTECTED]:
I think we should follow the ISO-3166 standard for everything; after
all, that's the point of the standard :-) If the RI has bugs in, then
fair enough, but the point of the ISO codes is to have a standard way
of referencing it (CD) -- how it appears on displays shouldn't be
important, and you shouldn't have code that depends on the display
name when you've got the ISO code ...
It's much easier to be strict about it now (and fix bugs as they get
found in other apps) than to be lax now and try and add strictness
later. So I'd say, let's go with the ISO-3166 for everything.
Alex.
On 10/08/06, Ilya Okomin [EMAIL PROTECTED] wrote:
On 8/10/06, Spark Shen [EMAIL PROTECTED] wrote:
2006/8/10, Richard Liang [EMAIL PROTECTED]:
Spark Shen wrote:
Hi All:
Construct a locale like this:
Locale l = new Locale(, CD);
On RI, l.getDisplayCountry() will return The Democratic Republic
Of
Congo,
which is different from ISO 3166-1 standard.
(CONGO, THE DEMOCRATIC REPUBLIC OF THE or Congo, the
Democratic
Republic
of the)
IMHO, we may follow the Java Specification, that is, ISO-3166. Do
you
think user applications would be broken because of the difference
with
RI.
I am not sure. But this may be a risk.
To follow ISO-3166 standard mentioned in the spec sounds better and
logical but...if you take a look on other several words country names
you
can find that they are not the same on RI than in the ISO-3166. E.g.:
new Locale(, KP);
ISO-3166 expected value: Korea, Democratic People's Republic of
RI returns: North Korea
new Locale(, MK);
ISO-3166 expected value: Macedonia, the former Yugoslav Republic of
RI returns: Macedonia
..and so on.
IMO in this case to be compatible with RI we can use The Democratic
Republic Of Congo for CD country. To follow completely the ISO-3166
standard we have to make changes not only for CD country.
Thanks,
Ilya.
Emm, now two are for being compliance with RI, one for spec. :-)
There is a concern that we may eliminate all locale related information
maintained in Harmony itself,
but uses a third party component, say ICU4J to manage all these data. And I
guess if people get agreed on that
scheme, all these argument may shift to that component related threads.
Best regards
Best regards
Richard.
Mean while, on harmony, we do not have a country CD-CONGO,
THE
DEMOCRATIC REPUBLIC OF THE data item or a
CD- Congo, the Democratic Republic of
the
http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Congo
data item at all.
This test case will fail on Harmony since the returned
displayCountry
is
CD.
public void test_getDisplayCountry() {
Locale l_countryCD = new Locale(, CD);
assertEquals(CONGO, THE DEMOCRATIC REPUBLIC OF THE,
l_countryCD.getDisplayCountry());
}
I need to add a mapping into harmony locale data. But which?
CD-CONGO, THE DEMOCRATIC REPUBLIC OF THE
or
CD-Congo, the Democratic Republic of the
or
CD-The Democratic Republic Of Congo (RI)
Personally, I prefer RI, since there may be applications
relies on
the
returned displayCountry value. Your opinions?
Best regards
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Spark Shen
China Software Development Lab, IBM
--
--
Ilya Okomin
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: [classlib][instrument]Method to terminate VM.
Leo Li wrote: Hi, all During the implementaion of instrument, I encounter the choice about how to terminate the VM when some abnormal event occurs, for example, the expected jar file does not exist or the implementation class of Instrumentation cannot be found. The most simple and direct way is just to call exit(), and then the whole process will terminate. Hence OS will treat with all the release of resources. However, I propose to use FatalError of JNI instead, which notifies the VM to suicide, because it gives right to the implementation of VM to take charge of its own funeral affairs, which might include, for example, logging the cause of its crash. Any suggestion from VM guys? Thanks :) Hi, I agree that use VM FatalError is better than system exit(). If no objections, I will make code that way. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
Hi,
As discussed in the former thread, I find that a JNI of DRLVM
(GetByteArrayRegion) differs from RI in passing parameter
(byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM
throws an ArrayIndexOutOfBoundsException.
IMHO, it is better to improve here, make it follow RI, as JNI is
also a part of API, and users may use it. So if no objections, shall I
or someone raise a JIRA for this?
I don't know if Martin is urgent in using Harmony in Winstone
servlet engine (Martin, can you read this?), so shall I work around in
java code before we have conclusion?
Any comments/suggestions from DRLVM guys? Thanks!
Jimmy, Jing Lv wrote:
Jimmy, Jing Lv wrote:
snip
I do some further study and test then, and find the problem was not so
easy.
Alex and I are correct that offset = buffer.length here is wrong,
but the next count = buffer.length - offset seems has proved its
correctness.
I have a test[1], try to write(new byte[count],count, 0) to a
SocketOutputStream, the test passes quietly. I do this test on WinXp
Sp2, the latest Harmony workspace, with J9 VM5.
I believe the ArrayIndexOutOfBoundsException is throw out when it try
to get byte array in the native (GetByteArrayRegion), which is a JNI
method. I guess there may be some difference between VMs.
Martin, are you using DRLVM? Can someone using DRLVM (or other VMs)
run the test below on DRLVM for me? Thanks!
[1]
public void test_socketOutputStream() throws Exception {
ServerSocket ss = new ServerSocket(0);
Socket sock = new Socket();
sock.connect(new InetSocketAddress
(InetAddress.getLocalHost(),ss.getLocalPort()));
ss.accept();
OutputStream os = sock.getOutputStream();
os.write(new byte[0], 0, 0); // passes here
os.write(new byte[512], 512, 0); // passes here
}
Hi,
At last I have test[1] JNI method(GetByteArrayRegion) of RI (before
dinner, very hungry... :) )
The result is that, RI return successfully if the given offset
equals length of the byte array, and the given count is zero.
Thus IMHO it is better to improve DRLVM to follow RI, as JNI methods
are also API methods, users may use it.
Shall we raise a JIRA for DRLVM? Any comments/suggestions from DRLVM
guys? Thanks!
Time for dinner! :D
[1]
test.java
--
class test
{
static{
System.loadLibrary(testjni);
}
private native void testjni(byte[] bs);
public void usejni(){
testjni(new byte[512]);
}
public static void main(String args[]){
new test().usejni();
}
}
---
test.h
---
/* DO NOT EDIT THIS FILE - it is machine generated */
#include jni.h
/* Header for class test */
#ifndef _Included_test
#define _Included_test
#ifdef __cplusplus
extern C {
#endif
/*
* Class: test
* Method:testjni
* Signature: ([B)V
*/
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv *, jobject, jbyteArray);
#ifdef __cplusplus
}
#endif
#endif
--
test.c
--
#include test.h
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv * env, jobject obj,jbyteArray array){
jbyte* buf = (jbyte*)malloc(sizeof(jbyte)*512);
(*env)-GetByteArrayRegion(env,array,512, 0, buf);
}
(magic number 512 can be any integer, including zero)
snip
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib][suncompat] created
I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][suncompat] created Oh - definitely only add as needed, and yes, we need to have good documentation to assist users. And I'm very +1 about including this by default for now. See other threads as for why. geir Alex Blewitt wrote: Sounds like a FAQ in the making :-) On 10/08/06, Tim Ellison [EMAIL PROTECTED] wrote: Alex Blewitt wrote: OK. What's the plan with regards to adding items in here e.g. Base64 or tools like JavaC? Or do we just add them organically as we find problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][support] Using new framework for testing serialization (was: Re: [jira] Updated: (HARMONY-1098) [classlib][instrument]Add tests for UnmodifiableClassException and IllegalClassFormatExce
Stepan Mishura wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Stepan Mishura wrote:
snip
BufferOverflowException());
But then you have to move generated file to the appropriate place by
hands.
Is this convenient?
Hi Stepan,
IMO, most ser file should be put into a certain directory, so the
the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated file is placed
in
'bin' (i.e. module_root/bin/test). folder. Am I right? So you
have to
move it by hands anyway to
module_root/src/test/resources/serialization
folder.
Ah sorry, I only test it on eclipse. Yes, if run on ant, it would
properly be module_root/bin/test.
IMO, mostly, people write code and create file once (for me, on
eclipse), so it is still a convenience if the framework offer such
method.
And for people who use ant to run test, still can offer a method for
that, e.g.
public static void createGoldenFileUsingAnt(TestCase test,Object object)
throws IOException {
createGoldenFile(../../src/test/resources/serialization,test,object);
}
Am I right? Thanks! :)
IMHO the framework shouldn't contain methods that work for selected tool
only.
OK, I'm fine with it (I shall make one on my own workspace :) ).
So I'll make a new patch for Harmony-1098 according to new framework.
Thanks,
Stepan.
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
Seems, that drlvm rejects valid code when 'end_pc' value for exception handler is equal to code array length.
At least, when I updatevalue for 'end_pc' in my simple class it was rejected by drlvm and accepted by RI.
Thanks, Vladimir
More details:
2 class attached: test.class.ref - generated by javac,
test.class - updated (line 108 for file belove was updated: 8 - 10)
- test.code
/*** Generated ccode file* @author VMTT (Virtual Machine Testing Tools)* @version 1.0* @lastmod: Fri Aug 11 11:20:30 NOVST 2006*/
magic = xCAFEBABE
minor_version = 0
major_version = 48
constant_pool_count = 18
constant_pool { /* #1 */ Method = #5 #14 /* #2 */ Class = #15 /* #3 */ Method = #2 #14 /* #4 */ Class = #16 /* #5 */ Class = #17 /* #6 */ UTF8 = init /* #7 */ UTF8 = ()V
/* #8 */ UTF8 = Code /* #9 */ UTF8 = LineNumberTable /* #10 */ UTF8 = main /* #11 */ UTF8 = ([Ljava/lang/String;)V /* #12 */ UTF8 = SourceFile
/* #13 */ UTF8 = test.java /* #14 */ NameAndType = #6 #7 /* #15 */ UTF8 = java/lang/Exception /* #16 */ UTF8 = test /* #17 */ UTF8 = java/lang/Object
}
access_flags = PUBLIC SUPER // x21
this_class = #4 // test
super_class = #5 // java/lang/Object
interfaces_count = 0
interfaces {}
fields_count = 0
methods_count = 2
methods { method { access_flag = PUBLIC // x01 name_index = #6 // init descriptor_index = #7 // ()V attributes_count = 1 attributes { attribute Code {
attribute_name_index = #8 // Code attribute_length = 29 max_stack = 1 max_locals = 1 code_length = 5 code asm { 0:aload_0
1:invokespecial #1 // java/lang/Object init ()V 4:return } exception_table_length = 0 attributes_count = 1
attributes { attribute LineNumberTable { attribute_name_index = #9 // LineNumberTable attribute_length = 6 line_number_table_length = 1
line_number_table { // start_pc line_number 0 1 } } } } } } method { access_flag = PUBLIC STATIC // x09
name_index = #10 // main descriptor_index = #11 // ([Ljava/lang/String;)V attributes_count = 1 attributes { attribute Code { attribute_name_index = #8 // Code
attribute_length = 50 max_stack = 2 max_locals = 2 code_length = 10 code asm { 0:new #2 // java/lang/Exception 3:dup
4:invokespecial #3 // java/lang/Exception init ()V 7:athrow 8:astore_1 9:return } exception_table_length = 1
exception_table { // start_pc end_pc handler_pc catch_type 0 10 8 2 } attributes_count = 1 attributes { attribute LineNumberTable {
attribute_name_index = #9 // LineNumberTable attribute_length = 14 line_number_table_length = 3 line_number_table { // start_pc line_number
0 4 8 5 9 7 } } } } } }}
attributes_count = 1attributes { attribute SourceFile { attribute_name_index = #12 // SourceFile attribute_length = 2 sourcefile_index = #13 // test.java }
}---
Output:
C:\tmp\vm_tooljava -showversion testjava version 1.4.2_10Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)
C:\tmp\vm_toolC:\jdk1.5.0_06\bin\java -showversion testjava version 1.5.0_06Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)Java HotSpot(TM) Client VM (build 1.5.0_06-b05
, mixed mode)
C:\tmp\vm_toolC:\harmony\drlvm1.5\build\win_ia32_msvc_debug\deploy\jre\bin\java -Dvm.assert_dialog=false -cp . -showversion testjava version 1.5.0pre-alpha : not complete or compatiblesvn = r430643, (Aug 11 2006), Windows/ia32/msvc 1310, debug build
http://incubator.apache.org/harmonyvf_debug: VerifyError: (class: test, method: main([Ljava/lang/String;)V) Handler pc is out of rangejava.lang.VerifyError: (class: test, method: main([Ljava/lang/String;)V) Handler pc is out of range
at java.lang.VMClassRegistry.defineClass() at java.lang.ClassLoader.defineClass() at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:68) at java.net.URLClassLoader.findClassImpl
(URLClassLoader.java:1130) at java.net.URLClassLoader$4.run(URLClassLoader.java:617) at java.net.URLClassLoader$4.run(URLClassLoader.java:616) at java.security.AccessController.doPrivilegedImpl
() at java.security.AccessController.doPrivileged() at java.net.URLClassLoader.findClass(URLClassLoader.java:614) at java.lang.ClassLoader.loadClass() at java.net.URLClassLoader$SubURLClassLoader.loadClass
(URLClassLoader.java:116)
C:\tmp\vm_toolC:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp . -showversion testjava version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable.
C:\tmp\vm_tool
On 8/10/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Anton Luht wrote: Hello, DRLVM hasan (undocumented?) option to switch off verifier
-Dvm.use_verifier=false . With this option activemq starts without crash. Verifier seem to be the blocker.Aw... I was hoping you'd tell us what the problem was. Any clue?geir
On 8/8/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Gregory Shimansky wrote:
On Tuesday 08 August 2006 00:01 Geir Magnusson Jr wrote:
