hg: jdk8/tl/langtools: 8024288: javadoc generated-by comment should always be present
Changeset: 044721d4d359 Author:jjg Date: 2013-09-04 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/044721d4d359 8024288: javadoc generated-by comment should always be present Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java
hg: jdk8/tl/jdk: 7186632: NLS t13y issue on jar.properties file
Changeset: c6a4df06d57e Author:sherman Date: 2013-09-04 12:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6a4df06d57e 7186632: NLS t13y issue on jar.properties file Summary: to remove the redundant backslash Reviewed-by: naoto ! src/share/classes/sun/tools/jar/resources/jar.properties
hg: jdk8/tl/jdk: 6341345: (spec) Console.reader() should make it clear that the reader requires line termination
Changeset: 478afc30679b Author:sherman Date: 2013-09-04 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/478afc30679b 6341345: (spec) Console.reader() should make it clear that the reader requires line termination Summary: to clarify the spec Reviewed-by: alanb ! src/share/classes/java/io/Console.java
hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency
Changeset: b3d6953b9829 Author:dfuchs Date: 2013-09-04 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829 8019853: Break logging and AWT circular dependency Summary: Break logging and AWT circular dependency, which was at the root cause for 8023258 - Logger.getLogger() after ImageIO.read() returns different logger instance Reviewed-by: mchung, art ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! test/java/util/logging/TestAppletLoggerContext.java + test/java/util/logging/TestLoggingWithMainAppContext.java
Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX
Indeed it did. -Rob On 04/09/13 10:36, Chris Hegarty wrote: Rob, I haven't looked at the changes yet, but I'm curious about the decision to use getifaddrs. I know that there was a discussion started at one point to determine what Apple's JDK6 is doing to retrieve the local machines IP information. Did that discussion lead to getifaddrs? -Chris. On 03/09/2013 16:18, Rob McKenna wrote: Hi folks, Mac seems to have trouble looking up local hostnames using getaddrinfo unless a domain is set. The solution is to add a check with getifaddrs . This fix replaces a usage of _ALLBSD_SOURCE with MACOSX. I haven't seen a canonical answer on whether this is the way to go so I figured trial by fire might get the discussion going. http://cr.openjdk.java.net/~robm/7180557/webrev.01/ -Rob
hg: jdk8/tl/jdk: 6823527: java.util.logging.Handler has thread safety issues
Changeset: ac6e99af2056 Author:dfuchs Date: 2013-09-04 15:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac6e99af2056 6823527: java.util.logging.Handler has thread safety issues Reviewed-by: dholmes, mchung ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java
hg: jdk8/tl/langtools: 8008275: javac.Main should be @Supported
Changeset: b94824ddcbb6 Author:vromero Date: 2013-09-04 11:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b94824ddcbb6 8008275: javac.Main should be @Supported Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/Main.java
hg: jdk8/tl/jdk: 8008981: Deprecate SecurityManager checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess
Changeset: 336784cd60c3 Author:alanb Date: 2013-09-04 11:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336784cd60c3 8008981: Deprecate SecurityManager checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess Reviewed-by: anthony, art, mchung ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java + test/java/awt/security/Permissions.java
Re: RFR:JDK-8021372 NetworkInterface.getNetworkInterfaces() returns duplicate hardware address
Mark, The source changes look good to me. The test is a good addition, but trivially I would... 1) remove the @build and @run tags. I don't think they are needed as I don't see that the test needs to run in othervm mode. 2) remove all exception handling code, and just declare all methods to throw Exception. The jtreg harness will show the test as failed if an unhandled exception is thrown. -Chris. On 04/09/2013 08:59, Mark Sheppard wrote: Hi based on feedback for initial fix, an amended webrev has been created. So, please oblige and review the fix below to address the issue in JDK-8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address webrev: http://cr.openjdk.java.net/~msheppar/8021372/webrev.01/ regressions re-run with no ill effects regards Mark
Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX
Rob, I haven't looked at the changes yet, but I'm curious about the decision to use getifaddrs. I know that there was a discussion started at one point to determine what Apple's JDK6 is doing to retrieve the local machines IP information. Did that discussion lead to getifaddrs? -Chris. On 03/09/2013 16:18, Rob McKenna wrote: Hi folks, Mac seems to have trouble looking up local hostnames using getaddrinfo unless a domain is set. The solution is to add a check with getifaddrs . This fix replaces a usage of _ALLBSD_SOURCE with MACOSX. I haven't seen a canonical answer on whether this is the way to go so I figured trial by fire might get the discussion going. http://cr.openjdk.java.net/~robm/7180557/webrev.01/ -Rob
hg: jdk8/tl/jdk: 8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees (red/black); ...
Changeset: d62c911aebbb Author:psandoz Date: 2013-09-04 09:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d62c911aebbb 8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees (red/black) 8012913: LinkedHashMap key/value/entry spliterators should report ORDERED Reviewed-by: mduigou, forax, bchristi, alanb Contributed-by: Doug Lea , Paul Sandoz ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/LinkedHashMap.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/util/Map/CheckRandomHashSeed.java ! test/java/util/Map/InPlaceOpsCollisions.java + test/java/util/Map/MapBinToFromTreeTest.java - test/java/util/Map/TreeBinSplitBackToEntries.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java
RFR:JDK-8021372 NetworkInterface.getNetworkInterfaces() returns duplicate hardware address
Hi based on feedback for initial fix, an amended webrev has been created. So, please oblige and review the fix below to address the issue in JDK-8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address webrev: http://cr.openjdk.java.net/~msheppar/8021372/webrev.01/ regressions re-run with no ill effects regards Mark
hg: jdk8/tl/jdk: 8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes
Changeset: 462c5589bc1a Author:psandoz Date: 2013-08-12 12:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/462c5589bc1a 8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes Summary: Use explicit lambda due to javac simplfying rules for overload resolution with implicit lambdas Reviewed-by: alanb, mduigou ! test/java/util/Arrays/SetAllTest.java
