Request for review: 7022370 Launcher ergonomics doesn't need per-architecture implementations
Hopefully all interested parties are addressed in the cc lists. webrev at: http://cr.openjdk.java.net/~dholmes/7022370/webrev/ The launcher ergonomics (ergo.c) currently relies on per-architecture, eg ergo_sparc.c, ergo_i586.c, files to define the actual ergonomics operations. Only x86 is actually CPU specific, both sparc and zero share the same platform independent implementation. It will simplify things if we provide a platform independent default in ergo.c that is conditionally compiled, and modify the build system to cause that compilation if a platform specific ergo file is not found. We can potentially delete all the ergo_*.c files except for ergo_i586.c, and we no longer require that there be a per-architecture file, which makes additional porting easier. Gary: do you mind seeing ergo_zero.c go away, or would you prefer to leave it in case someone is doing a local customization? I suppose the some consideration could be given to ergo_sparc.c too. Is anybody aware of downstream distros that modify these files to change the default ergonomics policies? Thanks, David Holmes
Re: 7023963 : Simple fixes to anon diamond in the jdk.
On 03/03/2011 20:43, David Holmes wrote: Kumar Srinivasan said the following on 03/04/11 05:40: Please review, corrections to the diamond operator on anonymous classes as suggested by langtools team. http://cr.openjdk.java.net/~ksrini/7023963/webrev.0/ Looks fine of course, but it is sad that it is necessary. I wonder what percentage of potential diamond usages this kills? :( Pity we couldn't just detect the non-denotable types and give a compilation error. David Changes look ok - thanks Kumar. Maurizio
Re: 7023963 : Simple fixes to anon diamond in the jdk.
Kumar Srinivasan said the following on 03/04/11 05:40: Please review, corrections to the diamond operator on anonymous classes as suggested by langtools team. http://cr.openjdk.java.net/~ksrini/7023963/webrev.0/ Looks fine of course, but it is sad that it is necessary. I wonder what percentage of potential diamond usages this kills? :( Pity we couldn't just detect the non-denotable types and give a compilation error. David
Re: 7023963 : Simple fixes to anon diamond in the jdk.
Looks fine with me. Mandy On 03/03/11 11:40, Kumar Srinivasan wrote: Please review, corrections to the diamond operator on anonymous classes as suggested by langtools team. http://cr.openjdk.java.net/~ksrini/7023963/webrev.0/ Thanks Kumar
Re: 7023963 : Simple fixes to anon diamond in the jdk.
Kumar Srinivasan wrote: Please review, corrections to the diamond operator on anonymous classes as suggested by langtools team. http://cr.openjdk.java.net/~ksrini/7023963/webrev.0/ Thanks Kumar Looks fine to me. -Alan
7023963 : Simple fixes to anon diamond in the jdk.
Please review, corrections to the diamond operator on anonymous classes as suggested by langtools team. http://cr.openjdk.java.net/~ksrini/7023963/webrev.0/ Thanks Kumar
hg: jdk7/tl/langtools: 7024212: TestWarnErrorCount fails
Changeset: 8fb48a9ac9ec Author:mcimadamore Date: 2011-03-03 18:05 + URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8fb48a9ac9ec 7024212: TestWarnErrorCount fails Summary: TestWarnErrorCount should be executed with -Xlint:all,-path to avoid spurious failures Reviewed-by: jjg ! test/tools/javac/processing/TestWarnErrorCount.java
hg: jdk7/tl/langtools: 2 new changesets
Changeset: c15d788cb381 Author:mcimadamore Date: 2011-03-03 17:32 + URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c15d788cb381 7023703: Valid code doesn't compile Summary: leftovers cause problems when analyzing loops in Flow.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/7023703/T7023703neg.java + test/tools/javac/7023703/T7023703neg.out + test/tools/javac/7023703/T7023703pos.java Changeset: 32565546784b Author:mcimadamore Date: 2011-03-03 17:34 + URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/32565546784b 7022054: Invalid compiler error on covariant overriding methods with the same erasure Summary: Rules for method clash use notion of subsignature, which is sometimes too strict and incompatible with JDK 6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/7022054/T7022054neg1.java + test/tools/javac/generics/7022054/T7022054neg1.out + test/tools/javac/generics/7022054/T7022054neg2.java + test/tools/javac/generics/7022054/T7022054neg2.out + test/tools/javac/generics/7022054/T7022054pos1.java + test/tools/javac/generics/7022054/T7022054pos2.java
hg: jdk7/tl/jdk: 2 new changesets
Changeset: b645b5bc460b Author:michaelm Date: 2011-03-03 17:14 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b645b5bc460b 7024264: HttpURLConnection/NetPermission doc issue Reviewed-by: chegar ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/NetPermission.java Changeset: 6e596210bf01 Author:michaelm Date: 2011-03-03 17:16 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e596210bf01 Merge
hg: jdk7/tl/jdk: 2 new changesets
Changeset: 732faed56eb0 Author:coffeys Date: 2011-03-03 16:51 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/732faed56eb0 6750362: Very large LDAP requests throw a OOM on LDAP servers which aren't aware of Paged Results Controls 6748156: add an new JNDI property to control the boolean flag WaitForReply Reviewed-by: vinnie, robm ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapRequest.java + test/com/sun/jndi/ldap/NoWaitForReplyTest.java Changeset: 0bd32f96187d Author:coffeys Date: 2011-03-03 17:00 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0bd32f96187d Merge
hg: jdk7/tl/jdk: 6721694: java/lang/Thread/StartOOMTest.java fails with timeout or with crash
Changeset: 9b99a14375bc Author:chegar Date: 2011-03-03 16:48 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b99a14375bc 6721694: java/lang/Thread/StartOOMTest.java fails with timeout or with crash Summary: the test is not suitable to be run automatically Reviewed-by: alanb ! test/java/lang/Thread/StartOOMTest.java
hg: jdk7/tl/jdk: 7018137: HTML4 compliance issues
Changeset: 7cfb0693eb33 Author:chegar Date: 2011-03-03 16:44 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7cfb0693eb33 7018137: HTML4 compliance issues Summary: move end list items tags to after nested list Reviewed-by: alanb ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/package.html
Re: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient
On 3 March 2011 15:06, Alan Bateman wrote: > I think the main thing with this proposal is getting agreement that it is > the right thing to do. On one hand it avoids the set getting corrupted. On > the other hand it's masking a problem and really part of a bigger issue. > This isn't really my area but it kinda feels like we need a run mode or some > way to enable concurrent modification exceptions so that the developer has > some chance to fix the real issues. > > -Alan. > As I previously noted in the discussion [1], the current Javadoc API for EnumSet explicitly states that ConcurrentModificationException will never be thrown from its iterator. [2] Also, Mike observed that other fixes which introduce the possibility of new ConcurrentModificationExceptions being thrown have previously been rejected on that basis. [3] We may all agree that if one was to start from scratch, consistently throwing CMEs (at least, where it's feasible to detect them) would probably be the ideal approach. But given the actual starting point, where existing API documentation explicits states that CMEs will *never* be thrown from EnumSet's iterator, and has done so since EnumSet's introduction in Java 5, I can appreciate there being nervousness about changing that explicit (EnumSet-iterator-specific) contract with the user/developer at this point. Given this nervousness, my suggested change implements the next best strategy, which is to make the iterator implementation tolerate the modification without corrupting the underlying EnumSet. This was, presumably, the behaviour as intended by the original author of the EnumSet API Javadoc. (In hindsight, one might disagree with the design choice made, but not that the design choice *was* made, given its explicit documentation). To leave the EnumSet iterator's code in its current (unchanged) form, I would argue, would be the worst possible outcome: It neither protects the contents of EnumSets from being "gratuitously" corrupted due to modification from both the iterator and the set (by being tolerant of this possibility), nor does it alert the developer to the error they are making. (I describe the corruption as "gratuitous" because it is so trivial to avoid for this iterator). I don't think that having a run-mode to enable CMEs to be thrown in this case would make things any better for the developer. What would prompt a developer to run in such a mode? In practice, I suspect it would merely act as a crutch with which folk would retrospectively beat the poor developer over the head, once corrupted EnumSets were detected, possibly (probably?) after their code is deployed. If there were agreement to throw CMEs by default, and have a run mode to disable them, I guess I'd be okay with that. I'm not sure that that would generally allay the backwards-compatibility concerns sufficiently for such a solution to be acceptable, however. Also, it didn't seem like that was the direction that the conversation was previously heading. As always, suggestions and guidance on how to progress the resolution to this problem forward gratefully accepted, Thanks, Neil [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005763.html [2] http://download.oracle.com/javase/1.5.0/docs/api/java/util/EnumSet.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-February/005799.html -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
hg: jdk7/tl/jdk: 7018606: (process) test/java/lang/ProcessBuilder/Basic.java failing intermittently (win)
Changeset: 75064373ed6b Author:michaelm Date: 2011-03-03 15:34 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75064373ed6b 7018606: (process) test/java/lang/ProcessBuilder/Basic.java failing intermittently (win) Reviewed-by: alanb ! test/java/lang/ProcessBuilder/Basic.java
Re: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient
Neil Richards wrote: Please advise me on what steps remain for this change to be committed. I think the main thing with this proposal is getting agreement that it is the right thing to do. On one hand it avoids the set getting corrupted. On the other hand it's masking a problem and really part of a bigger issue. This isn't really my area but it kinda feels like we need a run mode or some way to enable concurrent modification exceptions so that the developer has some chance to fix the real issues. -Alan.
hg: jdk7/tl/jaxp: 7023289: jaxp 1.4.5 development jdk7 2nd integration
Changeset: 877fd25c5a2f Author:ohair Date: 2011-03-02 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/877fd25c5a2f 7023289: jaxp 1.4.5 development jdk7 2nd integration Reviewed-by: joehw, mchung, alanb ! jaxp.properties
hg: jdk7/tl/langtools: 7023233: False positive for -Xlint:try with nested try with resources blocks
Changeset: e9b8fbb30f5a Author:mcimadamore Date: 2011-03-03 09:43 + URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e9b8fbb30f5a 7023233: False positive for -Xlint:try with nested try with resources blocks Summary: Wrong lint warning issued about unused resource when nested try-with-resource blocks are found Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/TryWithResources/UnusedResourcesTest.java
Re: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient
Please advise me on what steps remain for this change to be committed. Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
