hg: jdk8/tl/jdk: 8021863: Stream.concat incorrectly calculates unsized state
Changeset: 76d88a752a03 Author:psandoz Date: 2013-07-30 11:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76d88a752a03 8021863: Stream.concat incorrectly calculates unsized state Reviewed-by: chegar ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java
hg: jdk8/tl/jdk: 8021883: j.u.Random/RandomStream.java test needs more robust timeout duration
Changeset: d30f357c6050 Author:psandoz Date: 2013-07-30 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30f357c6050 8021883: j.u.Random/RandomStream.java test needs more robust timeout duration Reviewed-by: chegar ! test/java/util/Random/RandomStreamTest.java
hg: jdk8/tl/langtools: 8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6
Changeset: 7696282873f6 Author:vromero Date: 2013-07-31 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7696282873f6 8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/MethodInvokedWithWrongNumberOfArgs.java
Re: RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]
On 31/07/2013 05:18, Aleksej Efimov wrote: Hi, Can I have a review for the following problem: The MACOSX JDK (more precisely - the java.net classes) uses the select() system call to wait for different events on sockets fds. And the default behaviour for select() on Darwin is to fail when fdset contains the fd with id greater than FDSET_SIZE(=1024). Test case in webrev illustrates this behavior. There is at least one solution for it: use -D_DARWIN_UNLIMITED_SELECT compilation flag for all macosx sources: this won't affect other parts of JDK because they are not using select(). Currently, I have added this compilation flag to common/autoconf/generated-configure.sh and common/autoconf/generated-configure.sh. I wonder, if there is a better place where I can put this flag? The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/ BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820 Thanks for looking into this one. The build changes look okay to me but it's probably best that someone on build-dev agree to those. Michael McMahon can probably explain why the net code is using select for timed read/accept (I have a vague recollection of there being an issue with poll due to the way that it is implemented on kqueue with the result that it had to be changed to use select). I think the test needs re-work. It looks to me that the it attempts to connect to an Oracle internal site so that's not going to work everywhere. In general we don't want the tests to be dependent on hosts that may or may not exist (we had tests that used to this in the past but they caused a lot of grief). It also looks like the test doesn't close the 1023 files that it opens at the start and so I assume this test will always fail on Windows when jtreg tries to clean-up. -Alan.
hg: jdk8/tl/jdk: 8020539: Clean up doclint problems in java.util package, part 2
Changeset: 5561b34f6d4c Author:bpb Date: 2013-07-30 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5561b34f6d4c 8020539: Clean up doclint problems in java.util package, part 2 Summary: Clean up doclint errors and warnings in classes in java.util Reviewed-by: darcy, chegar Contributed-by: Brian Burkhalter brian.burkhal...@oracle.com ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/StringJoiner.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/Vector.java
hg: jdk8/tl/jdk: 8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified
Changeset: 4bd51f6268f4 Author:rbackman Date: 2013-07-24 10:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bd51f6268f4 8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified Reviewed-by: kvn, twisti ! test/sun/invoke/util/ValueConversionsTest.java
Re: Remaining doclint issues in java.net
On 7/29/13 7:28 AM, Chris Hegarty wrote: There are two remaining doclint warnings in the java.net package. :javac -Xdoclint:all/protected src/share/classes/java/net/DatagramPacket.java src/share/classes/java/net/DatagramPacket.java:142: warning: no @throws for java.net.SocketException public DatagramPacket(byte buf[], int offset, int length, ^ src/share/classes/java/net/DatagramPacket.java:178: warning: no @throws for java.net.SocketException public DatagramPacket(byte buf[], int length, ^ These are caused by no @throws SE declaration on the constructors. As it happens 'throws SE' was incorrectly added to these constructors when introduced in 1.4. The original API specified that SE was thrown when the given SocketAddress was not supported. That was later changed to throw IAE, in 1.4.2. These constructor now can never throw SE. Removing 'throws SE' from the method declaration is a binary compatible change, but not source compatible ( XXX is never thrown in body of corresponding try statement ). I don't think breaking source compatibility for this kind of change is justified. If it is, then the solution is to simply remove 'throws SE'. Back in the real world, I guess we need to come up with some wording for the '@throws SE' declaration. Something vague like If an I/O Exception occurs, or can we put something stronger like will never be thrown ?? I'd like to make a case for removing 'throws SE' even though it's a source incompatible change. It's not that source incompatibilities are strictly prohibited. They are allowed, and it depends on how often they occur and how difficult they are to fix. I seem to recall there was a similar issue when more precise rethrow was added in Java 7; this was indeed a source incompatibility but a survey was done and it was quite rare. How often are these DatagramPacket constructors used? I'd have to say, probably more often than the fairly obscure cases that the more precise rethrow feature caused issues with. On the other hand, fixing up code that constructs a DatagramPacket ought to be pretty simple: removing the catch of SocketException. This is already known to be dead code, so it can simply be removed. The alternative is to add @throws SocketException never to the javadoc, just to get rid of the doclint warning, but this has the consequence of requiring people to keep dead code around indefinitely, and furthermore it requires them to add new dead code every time they create a DatagramPacket. I'm not claiming that removing 'throws SE' is obviously the right answer, but I'd like to see it considered seriously. s'marks
Re: Remaining doclint issues in java.net
On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote: The alternative is to add @throws SocketException never to the javadoc, just to get rid of the doclint warning, but this has the consequence of requiring people to keep dead code around indefinitely, and furthermore it requires them to add new dead code every time they create a DatagramPacket. I have never understood in many years using Java why the compiler generates errors about attempting to catch supposedly-impossible exceptions, instead of warnings. For me it only leads to difficulties when I'm trying to write prototypes or refactor and clean up some old brittle code, and I run into that rather dubious sort of error. This is a good example of where it causes more harm than good. Is there still a really good reason for this over-paranoid compiler error given that checked exceptions aren't as popular as they used to be anyways? Matthew.
hg: jdk8/tl/langtools: 8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers
Changeset: 05370ef9dccb Author:ksrini Date: 2013-07-31 08:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05370ef9dccb 8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/NewArrayPretty.java
