'old' JIRA issues
Dear committers Can I somehow help with processing issues like [76] , [95], and [147]? These issues imply massive update and kind of block submitting further improvements for the related code... Thanks, Mikhail Intel Middleware Products Division [76] http://issues.apache.org/jira/browse/HARMONY-76 [95] http://issues.apache.org/jira/browse/HARMONY-95 [147] http://issues.apache.org/jira/browse/HARMONY-147
[jira] Updated: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=all ] Mark Hindess updated HARMONY-92: Attachment: new.refactor.tar.gz I've created a new version of these changes (from scratch to avoid provenance issues giving Geir headaches). There are scripts and patches numbered in order that they should be applied. It's broken down in to two stages - the nio to luni move and the rename. Check the README for details. Richard, let me know if I've missed anything. Thanks. Suggestion: Move com.ibm.platform from NIO to LUNI -- Key: HARMONY-92 URL: http://issues.apache.org/jira/browse/HARMONY-92 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Attachments: new.refactor.tar.gz, refactor_platform.zip Hello Tim, As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As these packages are used by java.net, as well as java.nio.channels. I will post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (HARMONY-168) Java 5.0 methods missing in java.lang.StringBuffer class
On 05/03/06, Nathan Beyer [EMAIL PROTECTED] wrote: I have a patch for this, as soon as I can get onto JIRA. Is the issues.apache.org box down? Seems to be. I'm waiting to upload some patches too. :-( -Mark. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK.
Garbage Collection
Hello, This is a slightly off topic post but I was wondering if anyone could point me in the right direction to obtaining research papers on Distributed Reference Counting and Garbage Collection either both of them or just Garbage Collection in Java. If anyone has any out of print or rare papers please feel free to reply with attachments or just reply to me directly. Thanks, - Vikram -- www.FaeLLe.com www.VikramMohan.com
[RESULT] Re: [VOTE] Accept HARMONY-57 : Contribution of unit test code for a number of components
+1 from geir, tim, richard, dims, stefano, karan, leo, nathan no dissenting. Geir Magnusson Jr wrote: All paperwork has been received. I'll be getting that into SVN today, but lets get the voting kicked off... Please vote on acceptance of the donation of ontribution of unit test code for a number of components : [ ] +1 Accept [ ] -1 Don't accept (provide reason) Vote will run 3 days or until all committers have voted.
[RESULT] Re: [VOTE] Accept HARMONY-88 : Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security
+1 from geir, tim, stefano, karan, nathan, dims, Geir Magnusson Jr wrote: All paperwork has been received. I'll be getting that into SVN today, but lest get the voting kicked off... Please vote on acceptance of the donation of Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security : [ ] +1 Accept [ ] -1 Don't accept (provide reason) Vote will run 3 days or until all committers have voted.
Re: local test server (Was: Re: [jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError)
Yes, Jetty is a good option :-) Richard Liang China Software Development Lab, IBM Geir Magnusson Jr wrote: Stepan Mishura wrote: Tim, George, I'd like to resume this topic Thanks for posting to the dev list :) There is no way to force a server to send you a chunked response using regular HTTP headers, so in this case the server and client have an understanding that when the client asks for a particular resource the server will send it back in chunks. I've created a small local server that just demonstrates common approach only. The idea is the next: a simple local server provides a way for a unit test to configure a server's response (also it may be improved to save a request message to be check by a unit test): ---invoke------request--- A unit teststested API a local server instance | ---result------response--- ^ | | ---configure server I believe this approach may be applied for most of cases and allow us to eliminate dependency on an external server. And give us tight control to be able to mimic misbehavior on the server side to be sure that the library behaves correctly. I've created JIRA (see Harmony-164) and attached a file with local server and 2 JUnit test cases (one of them sends a chunked response, please note there is no server's code specific for a selected test). Could you please review the code and let me know what you think? I took a quick look, and while I really am convinced that our own framework is necessary for all sorts of reasons I and others have listed already, I do wonder if we could simply do better via using jetty or tomcat in some way? geir
[jira] Updated: (HARMONY-168) Java 5.0 methods missing in java.lang.StringBuffer class
[ http://issues.apache.org/jira/browse/HARMONY-168?page=all ] Nathan Beyer updated HARMONY-168: - Attachment: StringBuffer_missing_methods.txt StringBuffer_missing_methods.txt is a patch for these missing methods and test methods for the respective test case class. Those methods that deal with Java 5/Unicode code points are implemented/not-implemented to be consistent with what's currently in StringBuilder and awaiting Java 5 code point support. Additionally, the Appendable interface isn't implemented yet, so I added a TODO for adding it once JLS3 bytecode support is enabled; in particular, support for covariant return types. Java 5.0 methods missing in java.lang.StringBuffer class Key: HARMONY-168 URL: http://issues.apache.org/jira/browse/HARMONY-168 Project: Harmony Type: Bug Components: Classlib Reporter: Vasily Zakharov Priority: Minor Attachments: StringBuffer_missing_methods.txt The following Java 5.0 methods are missing in java.lang.StringBuffer class: StringBuffer(CharSequence) append(CharSequence) append(CharSequence, int, int) insert(int, CharSequence) insert(int, CharSequence, int, int) trimToSize() appendCodePoint(int) codePointAt(int) codePointBefore(int) codePointCount(int, int) offsetByCodePoints(int, int) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-170) java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception
java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception -- Key: HARMONY-170 URL: http://issues.apache.org/jira/browse/HARMONY-170 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang public final CoderResult encode(CharBuffer in, ByteBuffer out, boolean endOfInput) As spec says, the method throws CoderMalfunctionError if an invocation of the decodeLoop method threw an unexpected exception. However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method threw an unexpected exception. The attached test cases pass on RI , but fail on Harmony. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-92) Suggestion: Move com.ibm.platform from NIO to LUNI
[ http://issues.apache.org/jira/browse/HARMONY-92?page=all ] Mark Hindess updated HARMONY-92: Attachment: 06.remove-obsolete.sh If you apply my changes then a number of files are no longer required. The 06 script removes them. Suggestion: Move com.ibm.platform from NIO to LUNI -- Key: HARMONY-92 URL: http://issues.apache.org/jira/browse/HARMONY-92 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Attachments: 06.remove-obsolete.sh, new.refactor.tar.gz, refactor_platform.zip Hello Tim, As we discussed in JIRA 27 and JIRA 42, I suggest we move the packages com.ibm.platform and com.ibm.platform.struct from NIO to LUNI component. As these packages are used by java.net, as well as java.nio.channels. I will post the proposed fix soon :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-170) java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception
[ http://issues.apache.org/jira/browse/HARMONY-170?page=all ] Richard Liang updated HARMONY-170: -- Attachment: CharsetEncoder_patch.txt CharsetEncoderTest_patch.txt Hello Tim, Please try my patch and the proposed test cases. Thanks a lot. java.nio.charset.CharsetEncoder.encode method does not handle the unexpected exception -- Key: HARMONY-170 URL: http://issues.apache.org/jira/browse/HARMONY-170 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Attachments: CharsetEncoderTest_patch.txt, CharsetEncoder_patch.txt public final CoderResult encode(CharBuffer in, ByteBuffer out, boolean endOfInput) As spec says, the method throws CoderMalfunctionError if an invocation of the decodeLoop method threw an unexpected exception. However, Harmony doesn't throws CoderMalfunctionError when decodeLoop method threw an unexpected exception. The attached test cases pass on RI , but fail on Harmony. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Understanding JAPI tools
Stuart, Stuart Ballard wrote: Tim Ellison t.p.ellison at gmail.com writes: Stuart: is there some way to avoid JAPI taking inherited API signatures into account when doing the diff? kinda like the javadoc tool. This is something of a Japi FAQ (I should probably put together a Japi FAQ page somewhere now that it's no longer the case that pretty much everyone using Japi is on the Classpath list ;) ). The answer is no, it doesn't do this, and I'm not going to implement it. The reason is that whether a method is overridden or not is *not* part of the public API. Javadoc documents it, sure, but that's not really sufficient to say whether it's part of the API or not - it's quite likely it was simply easier to write Javadoc that way (so it didn't have to go and find the doc comments in the superclass's source file, etc). The rules of binary compatibility say that moving a method up or down the class hierarchy is a completely compatible change. A method may be overridden, or not, purely for performance reasons and the behavior could be completely identical. For example, LinkedList.subList is not documented as being overridden, but if it's not, that guarantees that the iterator() method will always be at least O(N) where N is the startIndex that the sublist was created with. An overridden LinkedList.subList method could hang on to the start and end nodes of the list and provide an O(1) implementation of iterator(). As long as some effort was taken to ensure that serialization stayed compatible, there's no reason why a Free runtime shouldn't do that optimization even if Sun doesn't. I've also heard of cases where Sun documents a method as being overridden even though as far as any testing can determine, all it does is call super. There should be no obligation for any Free runtime to duplicate this inefficiency. It's also possible to implement a method that needs changed behavior in a subclass by making the superclass delegate some parts of its behavior to non-public methods, so the superclass method is unchanged but the subclass just overrides the non-public methods (obviously, this only works if the subclass is in the same package, but that's pretty common). Finally, it's possible (albeit unlikely) that even if there *was* an apparent need to override a method in a subclass because it has different behavior, there might be some weird optimization-related reason why somebody might want to actually write it as if (this instanceof Whatever) in the superclass. I can't see why that would happen, but if someone did that and got all the behavior right, they shouldn't be penalized for it in Japi. Most of above is true and has good reason, but as a practicer trying to implement a RI compatible class library, I still feel strongly that the method override information has its value, maybe a most common example is equals(Object), most classes don't override this method and only call j.l.Object's, but others DO has their own criteria, it's very reasonable to just remind programmer to implement this method, otherwise it will introduce serious compatibility issue. Just as a proposal, if you still feel that override difference is another story with common difference, how about to separate them into another category, similar with Compiler's warning, which at least can be as reference to programmer, and this information even can be switched on only if some user want to check the difference more *strictly*. Basically, Japi's business is to test the coverage of the API, and it's a fundamental design decision that Japi will *not* be testing implementation details. I've done quite a lot of work fixing bugs where implementation details inadvertently get exposed in the Japi results and if I find any more I'll fix them too. I think this is *extremely* important because, among other things, it's the *only* reason I feel legally secure in distributing Japi files for the JDK. As long as they only contain functional information necessary for interoperability, they're uncopyrightable. If they start exposing copyrightable implementation details, they become derived works of the JDK, and illegal to distribute (or, technically, to even create in the first place). And potentially so do the results of the comparisons. And if you then use those comparisons to make decisions on what to implement in Harmony, it jeopardizes Harmony's cleanroom status too. (IANAL; the people who actually decide whether legal risks are acceptable might think this isn't actually a problem for Harmony, but *I* don't want to be responsible for it ;) ) The right way to ensure that you've overridden all the right methods is to test the *behavior* of those methods. Obviously this is a lot more work than a simple automated run via Japi or equivalent, but it's the only way to get meaningful results. It is definitely the right way, but maybe not the most practical one. Still the example of equals(), do we need a testEquals for every
Re: J2SE 5 Plan / Roadmap
Nathan Beyer wrote: Excellent document! This can probably be split up into a couple pieces; here are some of my thoughts. * JLS3 bytecode support - Can the current VM load JLS3 class files? If not, what's missing (besides the major.minor version header)? Can some features be enabled/uplifted to allow APIs to move forward? Since generics are a compile-time feature, can code begin using generics by just allowing the JLS3 major.minor version? In any case, this probably breaks down into a couple topics: generics, annotations, enums, return-value-covariance and others. So far, I am using the VM provided by IBM developerworks as test environment, which seems don't support classes produced by 5.0 compatible compiler, which will throw UnsupportedClassVersionError. Personally I don't know how much part is missing. * Java 5 APIs [NEW] - Most of the brand-new APIs have been identified (java.lang.management, etc) and some are already being checked in. It seems like there's already a undocumented process here, which is to uplift and build any APIs to the Java 5 specification and leaving out any Java 5-specific language features, like generification, enums and annotations. I think so, using of generics, enums, etc., can be avoid temporarily before we get VM support, and very similar binaries can be produced. * Java 5 APIs [Generfication] - Once we can allow code with generics to be compiled and loaded, then we could begin a phase of uplifting all of the newly generified APIs (Collections, etc). Not sure if it is too risky just to mimic JLS3 class file support in VM by loosening the version check, because it may encourage the JSE 5 feature overusing, and some of which(annotation, for example) will produce different class binaries which may make the poor VM mad. * Java 5 APIs [Annotations] - I suspect, but could be wrong, that Annotations support will be more difficult to implement in the VM, as there is some runtime support. When this is available, another phase can be initiated to uplift all of the APIs with the appropriate Annotations (@deprecated, @override, etc). The class data structure has been modified to contain the annotation information, so I agree with you, this is more a VM issue, another significant part may be the tool(APT). I'm not too familiar with the JAPI tool, but if Stuart can get the Harmony reports to run against the Java 5 specifications, I this would provide an enormous boost in the arena of new Java 5 APIs. Does JAPI support JLS3 features, like generics, annotations and enum checking? From my experience by checking the JAPI result, at least the generics is supported pretty well. Those are some of my thoughts at least. BTW: JLS3 == Java Language Specification, 3rd Edition -Nathan There are maybe some other class library new features which requiring VM support, the one I can bring to mind immediately is Instrumentation, which needs VM's support of JVMTI(another big new interface!) -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 9:40 AM To: harmony-dev@incubator.apache.org Subject: J2SE 5 Plan / Roadmap We should probably start thinking about how we'll move forward. There have been a few casual conversations, but lets start getting some things down here. -- Paulex Yang China Software Development Lab IBM
[jira] Created: (HARMONY-171) Move more shared code from win/linux natives.
Move more shared code from win/linux natives. - Key: HARMONY-171 URL: http://issues.apache.org/jira/browse/HARMONY-171 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Minor Thanks to Oliver's changes (HARMONY-155) there are now more identical files in the win/linux native trees. I'll attach a patch to move them to the shared tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-171) Move more shared code from win/linux natives.
[ http://issues.apache.org/jira/browse/HARMONY-171?page=all ] Mark Hindess updated HARMONY-171: - Attachment: 01.shared.moves.sh 02.shared.diff The 01 script moves the files and the 02 diff will then fix up the makefiles to pick up the files from the shared tree. (Note this patch assumes that my changes in HARMONY-92 have been applied - otherwise there are rejects in the luni makefile.) Move more shared code from win/linux natives. - Key: HARMONY-171 URL: http://issues.apache.org/jira/browse/HARMONY-171 Project: Harmony Type: Improvement Components: Classlib Reporter: Mark Hindess Priority: Minor Attachments: 01.shared.moves.sh, 02.shared.diff Thanks to Oliver's changes (HARMONY-155) there are now more identical files in the win/linux native trees. I'll attach a patch to move them to the shared tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: local test server (Was: Re: [jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError)
On 3/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: ...snip... I believe this approach may be applied for most of cases and allow us to eliminate dependency on an external server. And give us tight control to be able to mimic misbehavior on the server side to be sure that the library behaves correctly. Sure, it is quite important to verify that the implementation functions properly in case of incorrect server's respond. And this can not be tested with a 'real' server because as was noted previously there is no way to force a server to send you a chunked response using regular HTTP headers. I can add that there is no way to force a server to send you a corrupted respond. ...snip... I took a quick look, and while I really am convinced that our own framework is necessary for all sorts of reasons I and others have listed already, I do wonder if we could simply do better via using jetty or tomcat in some way? Sorry, I didn't catch your suggestion with using jetty or tomcat. I don't understand the next: why we should introduce external dependency when there is simple solution? When I see that a complicated way is invented instead of using simple and obvious (from my point of view) solution I always assume two options here: - I missed something important and someone should point me out where I'm wrong. - A person tends to create sophisticated solutions due to some reasons, for example, she/he worked with some http server for years and now believes that it should be used everywhere. Returning back to our case, I do believe that there must be strong arguments for using external server for unit testing. Arguments like a server is free and easy configurable don't work against 40 lines of code and absence of special configuration. Thanks, Stepan On 3/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Stepan Mishura wrote: Tim, George, I'd like to resume this topic Thanks for posting to the dev list :) There is no way to force a server to send you a chunked response using regular HTTP headers, so in this case the server and client have an understanding that when the client asks for a particular resource the server will send it back in chunks. I've created a small local server that just demonstrates common approach only. The idea is the next: a simple local server provides a way for a unit test to configure a server's response (also it may be improved to save a request message to be check by a unit test): ---invoke------request--- A unit teststested API a local server instance | ---result------response--- ^ | | ---configure server I believe this approach may be applied for most of cases and allow us to eliminate dependency on an external server. And give us tight control to be able to mimic misbehavior on the server side to be sure that the library behaves correctly. I've created JIRA (see Harmony-164) and attached a file with local server and 2 JUnit test cases (one of them sends a chunked response, please note there is no server's code specific for a selected test). Could you please review the code and let me know what you think? I took a quick look, and while I really am convinced that our own framework is necessary for all sorts of reasons I and others have listed already, I do wonder if we could simply do better via using jetty or tomcat in some way? geir -- Thanks, Stepan Mishura Intel Middleware Products Division
[jira] Updated: (HARMONY-160) Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream
[ http://issues.apache.org/jira/browse/HARMONY-160?page=all ] Paulex Yang updated HARMONY-160: Attachment: java.util.zip.InflaterStreamTests.patch The prior fix is fine, thx. Here goes the patch for tests. Three JSE 5 methods are not implemented in java.util.zip.InflaterInputStream Key: HARMONY-160 URL: http://issues.apache.org/jira/browse/HARMONY-160 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: java.util.zip.InflaterStreamTests.patch, java.util.zip.inflaterinputStream.patch Three methods: java/util/zip/InflaterInputStream public markSupported()Z, java/util/zip/InflaterInputStream public mark(I)V, java/util/zip/InflaterInputStream public reset()V, are overridden in JSE 5, but they not implemented in Harmony -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-158) Two JSE 5 methods are not implemented in java.util.zip.Deflator
[ http://issues.apache.org/jira/browse/HARMONY-158?page=all ] Paulex Yang updated HARMONY-158: Attachment: java.util.zip.Deflater.patch java.util.zip.DeflaterTests.patch 158-native-patch.txt The patches are attached, one for java implementation, one for test, and the last for native codes. Pls. note that the native patches include both win.IA32 and linux.IA32, so pls. apply them on level of native-src directory. Two JSE 5 methods are not implemented in java.util.zip.Deflator --- Key: HARMONY-158 URL: http://issues.apache.org/jira/browse/HARMONY-158 Project: Harmony Type: Bug Reporter: Paulex Yang Attachments: 158-native-patch.txt, java.util.zip.Deflater.patch, java.util.zip.DeflaterTests.patch Two methods: java/util/zip/Deflater public getBytesRead()J java/util/zip/Deflater public getBytesWritten()J are introduced by JSE 5, but they are not been implemented by Harmony yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Resolved: (HARMONY-153) mark deprecated API
Verified 2006/3/3, Tim Ellison [EMAIL PROTECTED]: Mikhail Loenko wrote: One fix was applied to a wrong file, it was applied to java.security.Policy instead of javaX.security.Policy javax.security.auth.Policy, right? I've moved it -- thanks. (My patch program wouldn'd read your diff for some reason, so I did it by hand, wrongly). Thanks for catching that. Please take a look at the correction at repo revision 382802. Regards, Tim Remaining fixes and comments are OK Thanks, Mikhail 2006/3/2, Tim Ellison (JIRA) [EMAIL PROTECTED]: [ http://issues.apache.org/jira/browse/HARMONY-153?page=all ] Tim Ellison resolved HARMONY-153: - Resolution: Fixed Mikhail, I've fixed the problem at repo revision 382400, but to fit in with common convention I have added some explanations to the deprecation tag. Please review and check that they are reasonable. Thanks, Tim mark deprecated API --- Key: HARMONY-153 URL: http://issues.apache.org/jira/browse/HARMONY-153 Project: Harmony Type: Improvement Components: Classlib Reporter: Mikhail Loenko Assignee: Tim Ellison Priority: Minor Attachments: deprecated.txt As agreed on the mailing list deprecated classes, methods, etc should be marked I'm going to provide a patch shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
