! src/share/vm/prims/jniCheck.cpp
Changeset: 5e3b6f79d280
Author: rbackman
Date: 2013-07-17 13:48 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e3b6f79d280
8020701: Avoid crashes in WatcherThread
Reviewed-by: acorn, dcubed, dsimms
! src/os/posix/vm/os_posix.cpp
! src/os/posix/vm/os_posix.hpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.hpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/share/vm/runtime/mutex.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
Changeset: 248c459b2b75
Author: dcubed
Date: 2013-07-18 12:05 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/248c459b2b75
Merge
! src/share/vm/services/memTracker.cpp
Changeset: af21010d1062
Author: dcubed
Date: 2013-07-18 12:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af21010d1062
Merge
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/share/vm/runtime/os.hpp
Changeset: 02d7aa1456c9
Author: ccheung
Date: 2013-07-18 14:57 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02d7aa1456c9
8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed
Summary: this fix also removes the -XX:+UseStringCache option
Reviewed-by: dholmes, acorn, iklam
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
Changeset: 383a5e21cc2d
Author: minqi
Date: 2013-07-18 18:00 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/383a5e21cc2d
Merge
Changeset: 060ae9b7ffea
Author: mgronlun
Date: 2013-07-19 17:56 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/060ae9b7ffea
8020547: Event based tracing needs a UNICODE string type
Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn
! src/share/vm/trace/traceDataTypes.hpp
! src/share/vm/trace/tracetypes.xml
! src/share/vm/trace/xinclude.mod
Changeset: 4614a598dae1
Author: minqi
Date: 2013-07-19 08:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4614a598dae1
8016538: volatile double access via Unsafe.cpp is not atomic
Summary: volatile jdouble load/store is not atomic, fix by using of existing volatile jlong operations which are atomic for jdouble.
Reviewed-by: kvn, vladidan, jrose
Contributed-by: david.holmes at oracle.com
! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp
! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp
! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp
Changeset: 55a61ceb2fe7
Author: minqi
Date: 2013-07-19 11:17 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55a61ceb2fe7
Merge
Changeset: 16511b7e3d35
Author: emc
Date: 2013-07-22 17:57 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16511b7e3d35
8019632: Method parameters are not copied in clone_with_new_data
Summary: Add code to copy method parameters data in clone_with_new_data
Reviewed-by: coleenp, sspitsyn
! src/share/vm/oops/method.cpp
Changeset: 72727c4b6dec
Author: ccheung
Date: 2013-07-19 14:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72727c4b6dec
8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code
Summary: Added -DLINUX to the gcc command and improved the .sh script
Reviewed-by: dcubed, dholmes, minqi
! test/runtime/jsig/Test8017498.sh
! test/runtime/jsig/TestJNI.c
Changeset: 5165d659cebd
Author: minqi
Date: 2013-07-22 22:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5165d659cebd
Merge
Changeset: c0f353803b47
Author: minqi
Date: 2013-07-23 12:50 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c0f353803b47
Merge
Changeset: c90c698831d7
Author: kvn
Date: 2013-07-12 14:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c90c698831d7
8020215: Different execution plan when using JIT vs interpreter
Summary: fix bytecode analyzer
Reviewed-by: twisti
! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/bcEscapeAnalyzer.hpp
+ test/compiler/EscapeAnalysis/Test8020215.java
Changeset: fcf521c3fbc6
Author: kvn
Date: 2013-07-12 14:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fcf521c3fbc6
8007898: Incorrect optimization of Memory Barriers in Matcher::post_store_load_barrier()
Summary: generate one "fat" membar instead of set of barriers for volitile store
Reviewed-by: roland
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/parse3.cpp
+ test/compiler/membars/DekkerTest.java
Changeset: 34ce0b5acb81
Author: morris
Date: 2013-07-15 06:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34ce0b5acb81
Merge
Changeset: 0f57ccdb9084
Author: kvn
Date: 2013-07-15 10:28 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f57ccdb9084
8020433: Crash when using -XX:+RestoreMXCSROnJNICalls
Summary: remove StubRoutines::x86::_mxcsr_std and use StubRoutines::_mxcsr_std
Reviewed-by: jrose
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
+ test/compiler/cpuflags/RestoreMXCSR.java
Changeset: 46a90f83df31
Author: morris
Date: 2013-07-19 13:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46a90f83df31
Merge
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
Changeset: 6efedc114807
Author: morris
Date: 2013-07-24 13:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6efedc114807
Merge
Changeset: 01aa164323fa
Author: dholmes
Date: 2013-07-24 19:23 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01aa164323fa
8020799: Allow customization of hotspot source directories and files
Reviewed-by: kvn, dlong
! make/linux/makefiles/vm.make
Changeset: a4b9a8ec8f4a
Author: jiangli
Date: 2013-07-25 18:12 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a4b9a8ec8f4a
Merge
Changeset: 46487ba40ff2
Author: amurillo
Date: 2013-07-26 03:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46487ba40ff2
Merge
Changeset: f6921c876db1
Author: amurillo
Date: 2013-07-26 03:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6921c876db1
Added tag hs25-b43 for changeset 46487ba40ff2
! .hgtags
Changeset: 7c9885d23744
Author: cl
Date: 2013-08-01 04:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c9885d23744
Added tag jdk8-b101 for changeset f6921c876db1
! .hgtags
Changeset: e84845884c85
Author: amurillo
Date: 2013-07-26 04:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e84845884c85
8021566: new hotspot build - hs25-b44
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: d90d1b96b65b
Author: kvn
Date: 2013-07-26 12:37 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d90d1b96b65b
8008938: TieredCompilation should be default
Summary: switch on TieredCompilation by default
Reviewed-by: twisti
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp
Changeset: 1b6395189726
Author: minqi
Date: 2013-07-19 14:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b6395189726
8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails
Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash.
Reviewed-by: kvn, twisti
Contributed-by: yumin.qi at oracle.com
! src/share/vm/ci/ciReplay.cpp
Changeset: 5ad7f8179bf7
Author: minqi
Date: 2013-07-24 08:04 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ad7f8179bf7
Merge
Changeset: b6baf306e698
Author: fparain
Date: 2013-07-26 05:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6baf306e698
Merge
Changeset: 83ca9dc4564d
Author: fparain
Date: 2013-07-26 15:24 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83ca9dc4564d
8019845: Memory leak during class redefinition
Reviewed-by: acorn, jmasa, coleenp, dcubed, mgerdin
! src/share/vm/memory/metaspace.cpp
Changeset: f9ee986a9fea
Author: ccheung
Date: 2013-07-30 14:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9ee986a9fea
8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases
Summary: Added checking for gcc and simplified the sig_handler() in the test case
Reviewed-by: dcubed, coleenp, minqi, dlong
! test/runtime/6929067/Test6929067.sh
! test/runtime/7107135/Test7107135.sh
! test/runtime/jsig/Test8017498.sh
! test/runtime/jsig/TestJNI.c
Changeset: 0f98cc013b21
Author: fparain
Date: 2013-07-31 08:28 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f98cc013b21
Merge
Changeset: c65045599519
Author: dholmes
Date: 2013-07-25 21:05 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c65045599519
8021314: minimal1.make needs to force off components not supported by the minimal VM
Reviewed-by: coleenp, bpittore
! make/bsd/makefiles/minimal1.make
! make/linux/makefiles/minimal1.make
Changeset: 078e5eb2e52e
Author: clucasius
Date: 2013-07-27 17:23 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/078e5eb2e52e
Merge
Changeset: da839a3c5735
Author: dholmes
Date: 2013-07-31 19:05 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da839a3c5735
Merge
Changeset: e3c8767c5cf8
Author: tschatzl
Date: 2013-07-24 10:07 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3c8767c5cf8
8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build"
Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed
Reviewed-by: brutisso, mgerdin
! test/gc/g1/TestPrintRegionRememberedSetInfo.java
Changeset: 7b06ae405d7b
Author: jmasa
Date: 2013-07-23 09:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b06ae405d7b
6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/runtime/globals.hpp
Changeset: fb7010c7c011
Author: jmasa
Date: 2013-07-25 07:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fb7010c7c011
Merge
Changeset: ca9dedeebdec
Author: jmasa
Date: 2013-07-25 11:07 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca9dedeebdec
6412968: CMS Long initial mark pauses
Reviewed-by: rasbold, tschatzl, jmasa
Contributed-by: yamauchi at google.com
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/runtime/globals.hpp
Changeset: 8796fd3ac898
Author: tamao
Date: 2013-07-26 13:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8796fd3ac898
Merge
! src/share/vm/runtime/globals.hpp
Changeset: 313227279a05
Author: brutisso
Date: 2013-08-01 07:03 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/313227279a05
8021967: Deprecate -XX:DefaultMaxRAMFraction
Reviewed-by: tschatzl, jmasa, kvn, tamao
! src/share/vm/runtime/arguments.cpp
+ test/gc/startup_warnings/TestDefaultMaxRAMFraction.java
Changeset: dae8324fc7d1
Author: brutisso
Date: 2013-08-01 09:35 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dae8324fc7d1
8021879: G1: G1HeapRegionSize flag value not updated correctly
Reviewed-by: tschatzl, jmasa
! src/share/vm/gc_implementation/g1/heapRegion.cpp
+ test/gc/arguments/TestG1HeapRegionSize.java
Changeset: 8d4ff57af591
Author: brutisso
Date: 2013-08-01 17:29 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d4ff57af591
8022051: G1: Remove some unused G1 flags
Reviewed-by: tschatzl, jmasa
! src/share/vm/gc_implementation/g1/g1_globals.hpp
Changeset: 69d0dbb53c78
Author: tamao
Date: 2013-08-01 17:17 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69d0dbb53c78
Merge
Changeset: 530fe88b3b2c
Author: amurillo
Date: 2013-08-02 02:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/530fe88b3b2c
Merge
Changeset: c4697c1c4484
Author: amurillo
Date: 2013-08-02 02:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4697c1c4484
Added tag hs25-b44 for changeset 530fe88b3b2c
! .hgtags
From lana.steuck at oracle.com Tue Aug 6 17:17:01 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 07 Aug 2013 00:17:01 +0000
Subject: hg: jdk8/tl/langtools: 4 new changesets
Message-ID: <20130807001717.0D2A148641@hg.openjdk.java.net>
Changeset: 4c42fba7b0e7
Author: cl
Date: 2013-08-01 04:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4c42fba7b0e7
Added tag jdk8-b101 for changeset 0324dbf07b0f
! .hgtags
Changeset: 453a305e1165
Author: lana
Date: 2013-08-06 10:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/453a305e1165
Merge
Changeset: f3ea20a6e958
Author: lana
Date: 2013-08-06 17:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3ea20a6e958
Merge
Changeset: b926dc251be8
Author: lana
Date: 2013-08-06 17:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b926dc251be8
Merge
From lana.steuck at oracle.com Tue Aug 6 17:19:12 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 07 Aug 2013 00:19:12 +0000
Subject: hg: jdk8/tl/jdk: 28 new changesets
Message-ID: <20130807002511.5A6A848643@hg.openjdk.java.net>
Changeset: b52a2ecdb803
Author: cl
Date: 2013-08-01 04:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b52a2ecdb803
Added tag jdk8-b101 for changeset 690161232823
! .hgtags
Changeset: 2978c0a543ed
Author: prr
Date: 2013-07-22 12:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2978c0a543ed
7196866: CTW fails on all Solaris platforms
Reviewed-by: prr, jrose, twisti, kvn
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
Changeset: 784589c7bc55
Author: vadim
Date: 2013-07-24 13:38 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/784589c7bc55
8008782: NPE in TrueTypeGlyphMapper
Reviewed-by: bae, prr
! src/share/classes/sun/font/TrueTypeFont.java
Changeset: db2e3a686cf3
Author: jchen
Date: 2013-07-24 12:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db2e3a686cf3
8011709: [parfait] False positive: memory leak in jdk/src/share/native/sun/font/layout/CanonShaping.cpp
Reviewed-by: jgodinez, prr
! src/share/native/sun/font/layout/CanonShaping.cpp
Changeset: c2e27e7a42ae
Author: jchen
Date: 2013-07-24 13:05 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e27e7a42ae
8005126: [parfait] #418 - #428 XRBackendNative.c Integer overflow
Reviewed-by: prr, vadim
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
Changeset: 833f05116f7b
Author: bae
Date: 2013-07-25 17:14 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/833f05116f7b
8019201: Regression: java.awt.image.ConvolveOp throws java.awt.image.ImagingOpException
Reviewed-by: prr
! src/share/native/sun/awt/medialib/awt_ImagingLib.c
+ test/sun/awt/image/ImagingLib/SamePackingTypeTest.java
Changeset: a8b9df782017
Author: serb
Date: 2013-07-26 21:18 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8b9df782017
7190349: [macosx] Text (Label) is incorrectly drawn with a rotated g2d
8013569: [macosx] JLabel preferred size incorrect on retina displays with non-default font size
Reviewed-by: prr
! src/macosx/classes/sun/font/CStrike.java
! src/macosx/native/sun/font/AWTStrike.h
! src/macosx/native/sun/font/AWTStrike.m
! src/macosx/native/sun/font/CGGlyphImages.m
+ test/java/awt/Graphics2D/DrawString/DrawRotatedString.java
+ test/java/awt/Graphics2D/IncorrectTextSize/IncorrectTextSize.java
Changeset: 467a0c21790b
Author: jgodinez
Date: 2013-07-26 15:08 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/467a0c21790b
8020208: NullPointerException at sun.print.Win32PrintService.getMediaPrintables
Reviewed-by: jchen, prr
! src/windows/classes/sun/print/Win32PrintService.java
Changeset: 56c6f9a9653d
Author: jgodinez
Date: 2013-07-26 15:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56c6f9a9653d
8016343: [macosx] Print job goes to default printer regardless of chosen printer
Reviewed-by: jchen, prr
! src/share/classes/sun/print/PSPrinterJob.java
! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintJob.java
! test/javax/print/DialogMargins.java
Changeset: 1c48544c3da9
Author: lana
Date: 2013-07-26 15:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c48544c3da9
Merge
- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java
Changeset: 921338e44ba7
Author: lana
Date: 2013-07-26 17:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/921338e44ba7
Merge
Changeset: 046025f78ea8
Author: jgodinez
Date: 2013-07-30 13:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/046025f78ea8
8021835: Fix for 8016343 will not compile on Windows.
Reviewed-by: jchen, prr
! src/share/classes/sun/print/PSPrinterJob.java
Changeset: 7f0e569c5a66
Author: bae
Date: 2013-07-31 13:11 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f0e569c5a66
8020983: OutOfMemoryError caused by non garbage collected JPEGImageWriter Instances
Reviewed-by: prr, flar
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
+ test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java
Changeset: 607ad960fe24
Author: malenkov
Date: 2013-07-22 15:36 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/607ad960fe24
8019975: closed/javax/swing/JFileChooser/4966171/bug4966171.java throws java.io.NotSerializableException: javax.swing.plaf.basic.BasicFileChooserUI$AcceptAllFileFilter
Reviewed-by: alexsch
! src/share/classes/javax/swing/JFileChooser.java
Changeset: 3cbe376233a9
Author: malenkov
Date: 2013-07-22 20:33 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cbe376233a9
8015926: NPE when using SynthTreeUI's expandPath()
Reviewed-by: alexsch
! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
+ test/javax/swing/plaf/synth/Test8015926.java
Changeset: bdad697c03aa
Author: pchelko
Date: 2013-07-23 13:09 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdad697c03aa
7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session)
Reviewed-by: art, anthony
! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
Changeset: 99ee6ddab113
Author: serb
Date: 2013-07-24 17:14 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99ee6ddab113
8017189: [macosx] AWT program menu disabled on Mac
Reviewed-by: leonidr, anthony
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.h
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CMenuBar.m
Changeset: 7bd6eda2d217
Author: leonidr
Date: 2013-07-26 16:22 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd6eda2d217
8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working
Reviewed-by: anthony, serb
! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java
! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java
! src/macosx/native/sun/awt/AWTWindow.m
! src/macosx/native/sun/awt/CMenuItem.m
Changeset: 65c90209edbb
Author: lana
Date: 2013-07-26 15:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65c90209edbb
Merge
- src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties
- src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java
- src/share/classes/java/util/stream/StreamBuilder.java
- src/share/classes/javax/security/auth/callback/package.html
- src/share/classes/javax/security/auth/kerberos/package.html
- src/share/classes/javax/security/auth/login/package.html
- src/share/classes/javax/security/auth/package.html
- src/share/classes/javax/security/auth/spi/package.html
- src/share/classes/javax/security/auth/x500/package.html
- src/share/classes/javax/security/cert/package.html
- src/share/classes/javax/security/sasl/package.html
- test/java/util/Collections/EmptySortedSet.java
Changeset: 37016eaea5d2
Author: serb
Date: 2013-07-29 16:57 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37016eaea5d2
6230360: Spelling mistake in documentation for AWT: 1.4, 1.5, 1.6, 1.7
Reviewed-by: malenkov, art
! src/share/classes/java/awt/AWTException.java
Changeset: bf80c2965a84
Author: malenkov
Date: 2013-07-29 18:48 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf80c2965a84
8010782: clean up source files containing carriage return characters
Reviewed-by: alexsch, art
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties
! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties
Changeset: 1e482f58c747
Author: ant
Date: 2013-07-30 16:15 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e482f58c747
8020927: JLightweightFrame API should export layout properties change notifications
Reviewed-by: anthony
! src/share/classes/sun/swing/JLightweightFrame.java
! src/share/classes/sun/swing/LightweightContent.java
Changeset: 336a94dbecb5
Author: malenkov
Date: 2013-07-30 17:46 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336a94dbecb5
8015300: JComboBox text sometimes become selected, sometimes not (Windows LAF)
Reviewed-by: alexsch, serb
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
+ test/javax/swing/JComboBox/8015300/Test8015300.java
Changeset: 726ac8f75b54
Author: lana
Date: 2013-07-31 12:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/726ac8f75b54
Merge
Changeset: 0741b19835b0
Author: lana
Date: 2013-07-31 13:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0741b19835b0
Merge
- src/share/classes/java/net/package.html
Changeset: 8ed8e2b4b90e
Author: lana
Date: 2013-08-06 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ed8e2b4b90e
Merge
Changeset: 2bc9ce1aade5
Author: lana
Date: 2013-08-06 17:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc9ce1aade5
Merge
Changeset: 7ab5f19a9a31
Author: lana
Date: 2013-08-06 17:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ab5f19a9a31
Merge
From lana.steuck at oracle.com Tue Aug 6 17:16:51 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 07 Aug 2013 00:16:51 +0000
Subject: hg: jdk8/tl: Added tag jdk8-b101 for changeset 9f74a220677d
Message-ID: <20130807001651.B35284863B@hg.openjdk.java.net>
Changeset: 5eb3c1dc348f
Author: cl
Date: 2013-08-01 04:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/5eb3c1dc348f
Added tag jdk8-b101 for changeset 9f74a220677d
! .hgtags
From dan.xu at oracle.com Tue Aug 6 17:57:20 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 06 Aug 2013 17:57:20 -0700
Subject: RFR:JDK-8022478 - Fix Warnings In sun.net.www.protocol.http Package
Message-ID: <52019B70.807@oracle.com>
Hi All,
Please review the [serial] warning fix inside sun.net.www.protocol.http
package.
Webrev: http://cr.openjdk.java.net/~dxu/8022478/webrev/
Thanks,
-Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130806/a790d735/attachment.html
From joe.darcy at oracle.com Tue Aug 6 18:01:08 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 06 Aug 2013 18:01:08 -0700
Subject: RFR:JDK-8022478 - Fix Warnings In sun.net.www.protocol.http
Package
In-Reply-To: <52019B70.807@oracle.com>
References: <52019B70.807@oracle.com>
Message-ID: <52019C54.6070103@oracle.com>
Hi Dan,
As we discussed in person, since you are adding serial version uid that
matches the existing type, this is fine. Approved to go back.
Thanks,
-Joe
On 08/06/2013 05:57 PM, Dan Xu wrote:
> Hi All,
>
> Please review the [serial] warning fix inside
> sun.net.www.protocol.http package.
>
> Webrev: http://cr.openjdk.java.net/~dxu/8022478/webrev/
>
> Thanks,
>
> -Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130806/014fd5bb/attachment.html
From dan.xu at oracle.com Tue Aug 6 18:16:57 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Wed, 07 Aug 2013 01:16:57 +0000
Subject: hg: jdk8/tl/jdk: 8022478: Fix Warnings In sun.net.www.protocol.http
Package
Message-ID: <20130807011708.86F7148645@hg.openjdk.java.net>
Changeset: 1d21ff5c2b3f
Author: dxu
Date: 2013-08-06 18:16 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d21ff5c2b3f
8022478: Fix Warnings In sun.net.www.protocol.http Package
Reviewed-by: darcy
! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java
From mike.duigou at oracle.com Tue Aug 6 18:21:43 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 07 Aug 2013 01:21:43 +0000
Subject: hg: jdk8/tl/jdk: 8022476: cleanup some raw types and unchecked
warnings in java.util.stream
Message-ID: <20130807012155.28BBF48646@hg.openjdk.java.net>
Changeset: e117fcdd2176
Author: mduigou
Date: 2013-08-06 18:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e117fcdd2176
8022476: cleanup some raw types and unchecked warnings in java.util.stream
Reviewed-by: darcy
Contributed-by: mike.duigou at oracle.com, henry.jen at oracle.com
! src/share/classes/java/util/Optional.java
! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/ReduceOps.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/StreamSpliterators.java
From vicente.romero at oracle.com Wed Aug 7 02:41:49 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 07 Aug 2013 09:41:49 +0000
Subject: hg: jdk8/tl/langtools: 8020997: TreeMaker.AnnotationBuilder creates
broken element literals with repeating annotations
Message-ID: <20130807094204.96FBC48665@hg.openjdk.java.net>
Changeset: f3deeccbf4cf
Author: vromero
Date: 2013-08-07 10:41 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3deeccbf4cf
8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations
Reviewed-by: jjg, jfranck
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
+ test/tools/javac/T8020997/CannotCompileRepeatedAnnoTest.java
From vicente.romero at oracle.com Wed Aug 7 03:11:08 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 07 Aug 2013 10:11:08 +0000
Subject: hg: jdk8/tl/langtools: 8008274: javac should not reference/use sample
code
Message-ID: <20130807101110.F276C48668@hg.openjdk.java.net>
Changeset: c7dcf899ffff
Author: vromero
Date: 2013-08-07 11:04 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7dcf899ffff
8008274: javac should not reference/use sample code
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/Main.java
From weijun.wang at oracle.com Wed Aug 7 04:07:15 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 07 Aug 2013 11:07:15 +0000
Subject: hg: jdk8/tl/jdk: 7151062: [macosx] SCDynamicStore prints error
messages to stderr
Message-ID: <20130807110825.4E6F348669@hg.openjdk.java.net>
Changeset: 906dd23334c1
Author: weijun
Date: 2013-08-07 19:06 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/906dd23334c1
7151062: [macosx] SCDynamicStore prints error messages to stderr
Reviewed-by: xuelei
! src/macosx/native/java/util/SCDynamicStoreConfig.m
From xuelei.fan at oracle.com Wed Aug 7 05:44:15 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 07 Aug 2013 20:44:15 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <520133C7.20401@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com>
Message-ID: <5202411F.2010706@oracle.com>
On 8/7/2013 12:06 AM, Matthew Hall wrote:
> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
> and the single dot represents the root zone. So you have to be
> careful making this sort of change to check the DNS RFCs first.
That's the first question we need to answer, whether IDN allow tailling
dots ("com."), zero-length root label ("."), and zero-length label ("",
for example ""example..com")?
Per the specification of IDN.toASCII():
=======================================
"ToASCII operation can fail. ToASCII fails if any step of it fails. If
ToASCII operation fails, an IllegalArgumentException will be thrown. In
this case, the input string should not be used in an internationalized
domain name.
A label is an individual part of a domain name. The original ToASCII
operation, as defined in RFC 3490, only operates on a single label. This
method can handle both label and entire domain name, by assuming that
labels in a domain name are always separated by dots. ...
Throws IllegalArgumentException - if the input string doesn't conform to
RFC 3490 specification"
Per the specification of RFC 3490:
==================================
[section 2]
"A label is an individual part of a domain name. Labels are usually
shown separated by dots; for example, the domain name
"www.example.com" is composed of three labels: "www", "example", and
"com". (The zero-length root label described in [STD13], which can
be explicit as in "www.example.com." or implicit as in
"www.example.com", is not considered a label in this specification.)"
"An "internationalized label" is a label to which the ToASCII
operation (see section 4) can be applied without failing (with the
UseSTD3ASCIIRules flag unset). ...
Although most Unicode characters can appear in
internationalized labels, ToASCII will fail for some input strings,
and such strings are not valid internationalized labels."
"An "internationalized domain name" (IDN) is a domain name in which
every label is an internationalized label."
[Section 4.1]
"ToASCII consists of the following steps:
...
8. Verify that the number of code points is in the range 1 to 63
inclusive."
Here are the questions:
1. whether "example..com" is an valid IDN?
As dot is used as label separators, there are three labels,
"example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
"example..com" is not a valid IDN.
We need to address the issue in IDN.
2. whether "xyz." is an valid IDN?
It's an gray area, I think. We can treat the trailing "." as root
label, or a label separator.
If the trailing "." is treated as label separator, "xyz." is invalid
per RFC 3490.
if the trailing "." is treated as root label, what's the expected
return value of IDN.toASCII("xyz.")? I think the return value can be
either "xyz." or "xyz". The current implementation returns "xyz".
We may need not to update the implementation if tailing "." is
treated as root label.
3. whether "." is an valid IDN?
It's an gray area again, I think.
As above, if the trailing "." is treated as root label, I think the
return value can be either "." or "". The current implementation throws
a StringIndexOutOfBoundsException.
However, what empty domain name ("") really means? I would prefer to
return "." for "." instead.
We need to address the issue in IDN.
Here comes the solution, the IDN.toASCII() returns:
1. "." for ".";
2. "xyz" for "xyz.";
3. IAE for "example..com".
Does it make sense?
Thanks,
Xuelei
On 8/7/2013 1:35 AM, Michael McMahon wrote:
> I don't really understand the reason for the restriction in SNIHostName
> But, I guess that is where it should be enforced if it is required.
>
> Michael.
>
> On 06/08/13 17:43, Dmitry Samersoff wrote:
>> Xuelei,
>>
>> . (dot) is perfectly valid domain name and it means root domain so com.
>> is valid domain name as well.
>>
>> It thinks to me that in context of methods your change we should ignore
>> trailing dots, rather than throw exception.
>>
>> -Dmitry
>>
>>
>>
>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please review the bug fix to strict the illegal input checking in IDN.
>>>
>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>
>>> Here is two test cases, which are expected to get IAE.
>>>
>>> Case 1:
>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
>>> String index out of range: 0
>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>> at java.net.IDN.toASCII(IDN.java:118)
>>>
>>> Case 2:
>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>
>>> Thanks,
>>> Xuelei
>>>
>>
>
From dmitry.samersoff at oracle.com Wed Aug 7 06:10:23 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 07 Aug 2013 17:10:23 +0400
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5202411F.2010706@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
Message-ID: <5202473F.70808@oracle.com>
Xuelei,
root label is an empty label[1], dot is a label separator, so in printed
form domain names is dot-terminated.
Please see also below inline.
[1]
RFC rfc1034.txt:
Internally, programs that manipulate domain names should represent them
as sequences of labels, where each label is a length octet followed by
an octet string. Because all domain names end at the root, *which has a
null string for a label*, these internal representations can use a
length byte of zero to terminate a domain name.
On 2013-08-07 16:44, Xuelei Fan wrote:
> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>> and the single dot represents the root zone. So you have to be
>> careful making this sort of change to check the DNS RFCs first.
>
> That's the first question we need to answer, whether IDN allow tailling
> dots ("com."), zero-length root label ("."), and zero-length label ("",
> for example ""example..com")?
>
> Per the specification of IDN.toASCII():
> =======================================
> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
> ToASCII operation fails, an IllegalArgumentException will be thrown. In
> this case, the input string should not be used in an internationalized
> domain name.
>
> A label is an individual part of a domain name. The original ToASCII
> operation, as defined in RFC 3490, only operates on a single label. This
> method can handle both label and entire domain name, by assuming that
> labels in a domain name are always separated by dots. ...
>
> Throws IllegalArgumentException - if the input string doesn't conform to
> RFC 3490 specification"
>
> Per the specification of RFC 3490:
> ==================================
> [section 2]
> "A label is an individual part of a domain name. Labels are usually
> shown separated by dots; for example, the domain name
> "www.example.com" is composed of three labels: "www", "example", and
> "com". (The zero-length root label described in [STD13], which can
> be explicit as in "www.example.com." or implicit as in
> "www.example.com", is not considered a label in this specification.)"
>
> "An "internationalized label" is a label to which the ToASCII
> operation (see section 4) can be applied without failing (with the
> UseSTD3ASCIIRules flag unset). ...
> Although most Unicode characters can appear in
> internationalized labels, ToASCII will fail for some input strings,
> and such strings are not valid internationalized labels."
>
> "An "internationalized domain name" (IDN) is a domain name in which
> every label is an internationalized label."
>
> [Section 4.1]
> "ToASCII consists of the following steps:
>
> ...
>
> 8. Verify that the number of code points is in the range 1 to 63
> inclusive."
>
>
> Here are the questions:
> 1. whether "example..com" is an valid IDN?
> As dot is used as label separators, there are three labels,
> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
> "example..com" is not a valid IDN.
>
> We need to address the issue in IDN.
Root label can't appear in the middle of domain name, so example..com is
an invalid domain name and appropriate exception have to be thrown.
>
> 2. whether "xyz." is an valid IDN?
> It's an gray area, I think. We can treat the trailing "." as root
> label, or a label separator.
> If the trailing "." is treated as label separator, "xyz." is invalid
> per RFC 3490.
> if the trailing "." is treated as root label, what's the expected
> return value of IDN.toASCII("xyz.")? I think the return value can be
> either "xyz." or "xyz". The current implementation returns "xyz".
>
> We may need not to update the implementation if tailing "." is
> treated as root label.
Empty label at the end of domain names is valid per RFC 1034 and means
root label. So we should process this name and return all non-empty
labels.
> 3. whether "." is an valid IDN?
> It's an gray area again, I think.
> As above, if the trailing "." is treated as root label, I think the
> return value can be either "." or "". The current implementation throws
> a StringIndexOutOfBoundsException.
>
> However, what empty domain name ("") really means? I would prefer to
> return "." for "." instead.
>
> We need to address the issue in IDN.
As dot is a label separator and root (empty) label can't appear in the
middle of domain name, . (dot) is not valid name and this case is
similar to case (1) - we should throw an appropriate exception.
-Dmitry
>
> Here comes the solution, the IDN.toASCII() returns:
> 1. "." for ".";
> 2. "xyz" for "xyz.";
> 3. IAE for "example..com".
>
> Does it make sense?
>
> Thanks,
> Xuelei
>
>
> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>> I don't really understand the reason for the restriction in SNIHostName
>> But, I guess that is where it should be enforced if it is required.
>>
>> Michael.
>>
>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>> Xuelei,
>>>
>>> . (dot) is perfectly valid domain name and it means root domain so com.
>>> is valid domain name as well.
>>>
>>> It thinks to me that in context of methods your change we should ignore
>>> trailing dots, rather than throw exception.
>>>
>>> -Dmitry
>>>
>>>
>>>
>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please review the bug fix to strict the illegal input checking in IDN.
>>>>
>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>
>>>> Here is two test cases, which are expected to get IAE.
>>>>
>>>> Case 1:
>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
>>>> String index out of range: 0
>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>
>>>> Case 2:
>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From xuelei.fan at oracle.com Wed Aug 7 06:43:10 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 07 Aug 2013 13:43:10 +0000
Subject: hg: jdk8/tl/jdk: 8013809: deadlock in SSLSocketImpl between between
write and close
Message-ID: <20130807134325.C4A2E48679@hg.openjdk.java.net>
Changeset: 8c7cf4926157
Author: xuelei
Date: 2013-08-07 06:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c7cf4926157
8013809: deadlock in SSLSocketImpl between between write and close
Reviewed-by: wetmore
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
From michael.x.mcmahon at oracle.com Wed Aug 7 07:05:40 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 07 Aug 2013 15:05:40 +0100
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5202411F.2010706@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
Message-ID: <52025434.8070200@oracle.com>
Resolvers seem to accept queries using trailing dots.
eg nslookup www.oracle.com.
or InetAddress.getByName("www.oracle.com.");
The part of RFC3490 quoted below seems to me to be saying
that the empty label implied by the trailing dot is not regarded
as a label so that you don't end up calling toAscii() or toUnicode()
with an empty string. I don't think it's saying the trailing dot can't
be there.
Michael
On 07/08/13 13:44, Xuelei Fan wrote:
> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>> and the single dot represents the root zone. So you have to be
>> careful making this sort of change to check the DNS RFCs first.
> That's the first question we need to answer, whether IDN allow tailling
> dots ("com."), zero-length root label ("."), and zero-length label ("",
> for example ""example..com")?
>
> Per the specification of IDN.toASCII():
> =======================================
> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
> ToASCII operation fails, an IllegalArgumentException will be thrown. In
> this case, the input string should not be used in an internationalized
> domain name.
>
> A label is an individual part of a domain name. The original ToASCII
> operation, as defined in RFC 3490, only operates on a single label. This
> method can handle both label and entire domain name, by assuming that
> labels in a domain name are always separated by dots. ...
>
> Throws IllegalArgumentException - if the input string doesn't conform to
> RFC 3490 specification"
>
> Per the specification of RFC 3490:
> ==================================
> [section 2]
> "A label is an individual part of a domain name. Labels are usually
> shown separated by dots; for example, the domain name
> "www.example.com" is composed of three labels: "www", "example", and
> "com". (The zero-length root label described in [STD13], which can
> be explicit as in "www.example.com." or implicit as in
> "www.example.com", is not considered a label in this specification.)"
>
> "An "internationalized label" is a label to which the ToASCII
> operation (see section 4) can be applied without failing (with the
> UseSTD3ASCIIRules flag unset). ...
> Although most Unicode characters can appear in
> internationalized labels, ToASCII will fail for some input strings,
> and such strings are not valid internationalized labels."
>
> "An "internationalized domain name" (IDN) is a domain name in which
> every label is an internationalized label."
>
> [Section 4.1]
> "ToASCII consists of the following steps:
>
> ...
>
> 8. Verify that the number of code points is in the range 1 to 63
> inclusive."
>
>
> Here are the questions:
> 1. whether "example..com" is an valid IDN?
> As dot is used as label separators, there are three labels,
> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
> "example..com" is not a valid IDN.
>
> We need to address the issue in IDN.
>
> 2. whether "xyz." is an valid IDN?
> It's an gray area, I think. We can treat the trailing "." as root
> label, or a label separator.
> If the trailing "." is treated as label separator, "xyz." is invalid
> per RFC 3490.
> if the trailing "." is treated as root label, what's the expected
> return value of IDN.toASCII("xyz.")? I think the return value can be
> either "xyz." or "xyz". The current implementation returns "xyz".
>
> We may need not to update the implementation if tailing "." is
> treated as root label.
>
> 3. whether "." is an valid IDN?
> It's an gray area again, I think.
> As above, if the trailing "." is treated as root label, I think the
> return value can be either "." or "". The current implementation throws
> a StringIndexOutOfBoundsException.
>
> However, what empty domain name ("") really means? I would prefer to
> return "." for "." instead.
>
> We need to address the issue in IDN.
>
>
> Here comes the solution, the IDN.toASCII() returns:
> 1. "." for ".";
> 2. "xyz" for "xyz.";
> 3. IAE for "example..com".
>
> Does it make sense?
>
> Thanks,
> Xuelei
>
>
> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>> I don't really understand the reason for the restriction in SNIHostName
>> But, I guess that is where it should be enforced if it is required.
>>
>> Michael.
>>
>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>> Xuelei,
>>>
>>> . (dot) is perfectly valid domain name and it means root domain so com.
>>> is valid domain name as well.
>>>
>>> It thinks to me that in context of methods your change we should ignore
>>> trailing dots, rather than throw exception.
>>>
>>> -Dmitry
>>>
>>>
>>>
>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please review the bug fix to strict the illegal input checking in IDN.
>>>>
>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>
>>>> Here is two test cases, which are expected to get IAE.
>>>>
>>>> Case 1:
>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
>>>> String index out of range: 0
>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>
>>>> Case 2:
>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
From xuelei.fan at oracle.com Wed Aug 7 07:13:46 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 07 Aug 2013 22:13:46 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52025434.8070200@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com>
Message-ID: <5202561A.5040908@oracle.com>
On 8/7/2013 10:05 PM, Michael McMahon wrote:
> Resolvers seem to accept queries using trailing dots.
>
> eg nslookup www.oracle.com.
>
> or InetAddress.getByName("www.oracle.com.");
>
> The part of RFC3490 quoted below seems to me to be saying
> that the empty label implied by the trailing dot is not regarded
> as a label so that you don't end up calling toAscii() or toUnicode()
> with an empty string. I don't think it's saying the trailing dot can't
> be there.
>
It makes sense.
What's your preference to return for IDN.toASCII("www.oracle.com."),
"www.oracle.com." or "www.oracle.com"? The current returned value is
"www.oracle.com". I would like to reserve the behavior in this update.
I think we are on same page soon.
Thanks,
Xuelei
> Michael
>
> On 07/08/13 13:44, Xuelei Fan wrote:
>> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>>> and the single dot represents the root zone. So you have to be
>>> careful making this sort of change to check the DNS RFCs first.
>> That's the first question we need to answer, whether IDN allow tailling
>> dots ("com."), zero-length root label ("."), and zero-length label ("",
>> for example ""example..com")?
>>
>> Per the specification of IDN.toASCII():
>> =======================================
>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
>> ToASCII operation fails, an IllegalArgumentException will be thrown. In
>> this case, the input string should not be used in an internationalized
>> domain name.
>>
>> A label is an individual part of a domain name. The original ToASCII
>> operation, as defined in RFC 3490, only operates on a single label. This
>> method can handle both label and entire domain name, by assuming that
>> labels in a domain name are always separated by dots. ...
>>
>> Throws IllegalArgumentException - if the input string doesn't conform to
>> RFC 3490 specification"
>>
>> Per the specification of RFC 3490:
>> ==================================
>> [section 2]
>> "A label is an individual part of a domain name. Labels are usually
>> shown separated by dots; for example, the domain name
>> "www.example.com" is composed of three labels: "www", "example", and
>> "com". (The zero-length root label described in [STD13], which can
>> be explicit as in "www.example.com." or implicit as in
>> "www.example.com", is not considered a label in this specification.)"
>>
>> "An "internationalized label" is a label to which the ToASCII
>> operation (see section 4) can be applied without failing (with the
>> UseSTD3ASCIIRules flag unset). ...
>> Although most Unicode characters can appear in
>> internationalized labels, ToASCII will fail for some input strings,
>> and such strings are not valid internationalized labels."
>>
>> "An "internationalized domain name" (IDN) is a domain name in which
>> every label is an internationalized label."
>>
>> [Section 4.1]
>> "ToASCII consists of the following steps:
>>
>> ...
>>
>> 8. Verify that the number of code points is in the range 1 to 63
>> inclusive."
>>
>>
>> Here are the questions:
>> 1. whether "example..com" is an valid IDN?
>> As dot is used as label separators, there are three labels,
>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
>> "example..com" is not a valid IDN.
>>
>> We need to address the issue in IDN.
>>
>> 2. whether "xyz." is an valid IDN?
>> It's an gray area, I think. We can treat the trailing "." as root
>> label, or a label separator.
>> If the trailing "." is treated as label separator, "xyz." is invalid
>> per RFC 3490.
>> if the trailing "." is treated as root label, what's the expected
>> return value of IDN.toASCII("xyz.")? I think the return value can be
>> either "xyz." or "xyz". The current implementation returns "xyz".
>>
>> We may need not to update the implementation if tailing "." is
>> treated as root label.
>>
>> 3. whether "." is an valid IDN?
>> It's an gray area again, I think.
>> As above, if the trailing "." is treated as root label, I think the
>> return value can be either "." or "". The current implementation throws
>> a StringIndexOutOfBoundsException.
>>
>> However, what empty domain name ("") really means? I would prefer to
>> return "." for "." instead.
>>
>> We need to address the issue in IDN.
>>
>>
>> Here comes the solution, the IDN.toASCII() returns:
>> 1. "." for ".";
>> 2. "xyz" for "xyz.";
>> 3. IAE for "example..com".
>>
>> Does it make sense?
>>
>> Thanks,
>> Xuelei
>>
>>
>> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>>> I don't really understand the reason for the restriction in SNIHostName
>>> But, I guess that is where it should be enforced if it is required.
>>>
>>> Michael.
>>>
>>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>>> Xuelei,
>>>>
>>>> . (dot) is perfectly valid domain name and it means root domain so com.
>>>> is valid domain name as well.
>>>>
>>>> It thinks to me that in context of methods your change we should ignore
>>>> trailing dots, rather than throw exception.
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>>
>>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the bug fix to strict the illegal input checking in IDN.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>>
>>>>> Here is two test cases, which are expected to get IAE.
>>>>>
>>>>> Case 1:
>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
>>>>> String index out of range: 0
>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>>
>>>>> Case 2:
>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>
From michael.x.mcmahon at oracle.com Wed Aug 7 07:18:14 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 07 Aug 2013 15:18:14 +0100
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5202561A.5040908@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
Message-ID: <52025726.8060203@oracle.com>
On 07/08/13 15:13, Xuelei Fan wrote:
> On 8/7/2013 10:05 PM, Michael McMahon wrote:
>> Resolvers seem to accept queries using trailing dots.
>>
>> eg nslookup www.oracle.com.
>>
>> or InetAddress.getByName("www.oracle.com.");
>>
>> The part of RFC3490 quoted below seems to me to be saying
>> that the empty label implied by the trailing dot is not regarded
>> as a label so that you don't end up calling toAscii() or toUnicode()
>> with an empty string. I don't think it's saying the trailing dot can't
>> be there.
>>
> It makes sense.
>
> What's your preference to return for IDN.toASCII("www.oracle.com."),
> "www.oracle.com." or "www.oracle.com"? The current returned value is
> "www.oracle.com". I would like to reserve the behavior in this update.
My opinion is to keep it as at present ie. "www.oracle.com."
Michael
> I think we are on same page soon.
>
> Thanks,
> Xuelei
>
>> Michael
>>
>> On 07/08/13 13:44, Xuelei Fan wrote:
>>> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>>>> and the single dot represents the root zone. So you have to be
>>>> careful making this sort of change to check the DNS RFCs first.
>>> That's the first question we need to answer, whether IDN allow tailling
>>> dots ("com."), zero-length root label ("."), and zero-length label ("",
>>> for example ""example..com")?
>>>
>>> Per the specification of IDN.toASCII():
>>> =======================================
>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In
>>> this case, the input string should not be used in an internationalized
>>> domain name.
>>>
>>> A label is an individual part of a domain name. The original ToASCII
>>> operation, as defined in RFC 3490, only operates on a single label. This
>>> method can handle both label and entire domain name, by assuming that
>>> labels in a domain name are always separated by dots. ...
>>>
>>> Throws IllegalArgumentException - if the input string doesn't conform to
>>> RFC 3490 specification"
>>>
>>> Per the specification of RFC 3490:
>>> ==================================
>>> [section 2]
>>> "A label is an individual part of a domain name. Labels are usually
>>> shown separated by dots; for example, the domain name
>>> "www.example.com" is composed of three labels: "www", "example", and
>>> "com". (The zero-length root label described in [STD13], which can
>>> be explicit as in "www.example.com." or implicit as in
>>> "www.example.com", is not considered a label in this specification.)"
>>>
>>> "An "internationalized label" is a label to which the ToASCII
>>> operation (see section 4) can be applied without failing (with the
>>> UseSTD3ASCIIRules flag unset). ...
>>> Although most Unicode characters can appear in
>>> internationalized labels, ToASCII will fail for some input strings,
>>> and such strings are not valid internationalized labels."
>>>
>>> "An "internationalized domain name" (IDN) is a domain name in which
>>> every label is an internationalized label."
>>>
>>> [Section 4.1]
>>> "ToASCII consists of the following steps:
>>>
>>> ...
>>>
>>> 8. Verify that the number of code points is in the range 1 to 63
>>> inclusive."
>>>
>>>
>>> Here are the questions:
>>> 1. whether "example..com" is an valid IDN?
>>> As dot is used as label separators, there are three labels,
>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
>>> "example..com" is not a valid IDN.
>>>
>>> We need to address the issue in IDN.
>>>
>>> 2. whether "xyz." is an valid IDN?
>>> It's an gray area, I think. We can treat the trailing "." as root
>>> label, or a label separator.
>>> If the trailing "." is treated as label separator, "xyz." is invalid
>>> per RFC 3490.
>>> if the trailing "." is treated as root label, what's the expected
>>> return value of IDN.toASCII("xyz.")? I think the return value can be
>>> either "xyz." or "xyz". The current implementation returns "xyz".
>>>
>>> We may need not to update the implementation if tailing "." is
>>> treated as root label.
>>>
>>> 3. whether "." is an valid IDN?
>>> It's an gray area again, I think.
>>> As above, if the trailing "." is treated as root label, I think the
>>> return value can be either "." or "". The current implementation throws
>>> a StringIndexOutOfBoundsException.
>>>
>>> However, what empty domain name ("") really means? I would prefer to
>>> return "." for "." instead.
>>>
>>> We need to address the issue in IDN.
>>>
>>>
>>> Here comes the solution, the IDN.toASCII() returns:
>>> 1. "." for ".";
>>> 2. "xyz" for "xyz.";
>>> 3. IAE for "example..com".
>>>
>>> Does it make sense?
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>
>>> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>>>> I don't really understand the reason for the restriction in SNIHostName
>>>> But, I guess that is where it should be enforced if it is required.
>>>>
>>>> Michael.
>>>>
>>>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>>>> Xuelei,
>>>>>
>>>>> . (dot) is perfectly valid domain name and it means root domain so com.
>>>>> is valid domain name as well.
>>>>>
>>>>> It thinks to me that in context of methods your change we should ignore
>>>>> trailing dots, rather than throw exception.
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>>
>>>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the bug fix to strict the illegal input checking in IDN.
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>>>
>>>>>> Here is two test cases, which are expected to get IAE.
>>>>>>
>>>>>> Case 1:
>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
>>>>>> String index out of range: 0
>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>>>
>>>>>> Case 2:
>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
From xuelei.fan at oracle.com Wed Aug 7 08:17:05 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 07 Aug 2013 23:17:05 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52025726.8060203@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com>
Message-ID: <520264F1.1090802@oracle.com>
Please review the new update:
http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
With this update, "com." is valid (return "com."); "." and
"example..com" are invalid. And IAE will be thrown for invalid IDN.
Thanks,
Xuelei
On 8/7/2013 10:18 PM, Michael McMahon wrote:
> On 07/08/13 15:13, Xuelei Fan wrote:
>> On 8/7/2013 10:05 PM, Michael McMahon wrote:
>>> Resolvers seem to accept queries using trailing dots.
>>>
>>> eg nslookup www.oracle.com.
>>>
>>> or InetAddress.getByName("www.oracle.com.");
>>>
>>> The part of RFC3490 quoted below seems to me to be saying
>>> that the empty label implied by the trailing dot is not regarded
>>> as a label so that you don't end up calling toAscii() or toUnicode()
>>> with an empty string. I don't think it's saying the trailing dot can't
>>> be there.
>>>
>> It makes sense.
>>
>> What's your preference to return for IDN.toASCII("www.oracle.com."),
>> "www.oracle.com." or "www.oracle.com"? The current returned value is
>> "www.oracle.com". I would like to reserve the behavior in this update.
>
> My opinion is to keep it as at present ie. "www.oracle.com."
>
> Michael
>
>> I think we are on same page soon.
>>
>> Thanks,
>> Xuelei
>>
>>> Michael
>>>
>>> On 07/08/13 13:44, Xuelei Fan wrote:
>>>> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>>>>> and the single dot represents the root zone. So you have to be
>>>>> careful making this sort of change to check the DNS RFCs first.
>>>> That's the first question we need to answer, whether IDN allow tailling
>>>> dots ("com."), zero-length root label ("."), and zero-length label ("",
>>>> for example ""example..com")?
>>>>
>>>> Per the specification of IDN.toASCII():
>>>> =======================================
>>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
>>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In
>>>> this case, the input string should not be used in an internationalized
>>>> domain name.
>>>>
>>>> A label is an individual part of a domain name. The original ToASCII
>>>> operation, as defined in RFC 3490, only operates on a single label.
>>>> This
>>>> method can handle both label and entire domain name, by assuming that
>>>> labels in a domain name are always separated by dots. ...
>>>>
>>>> Throws IllegalArgumentException - if the input string doesn't
>>>> conform to
>>>> RFC 3490 specification"
>>>>
>>>> Per the specification of RFC 3490:
>>>> ==================================
>>>> [section 2]
>>>> "A label is an individual part of a domain name. Labels are usually
>>>> shown separated by dots; for example, the domain name
>>>> "www.example.com" is composed of three labels: "www", "example", and
>>>> "com". (The zero-length root label described in [STD13], which can
>>>> be explicit as in "www.example.com." or implicit as in
>>>> "www.example.com", is not considered a label in this
>>>> specification.)"
>>>>
>>>> "An "internationalized label" is a label to which the ToASCII
>>>> operation (see section 4) can be applied without failing (with the
>>>> UseSTD3ASCIIRules flag unset). ...
>>>> Although most Unicode characters can appear in
>>>> internationalized labels, ToASCII will fail for some input strings,
>>>> and such strings are not valid internationalized labels."
>>>>
>>>> "An "internationalized domain name" (IDN) is a domain name in which
>>>> every label is an internationalized label."
>>>>
>>>> [Section 4.1]
>>>> "ToASCII consists of the following steps:
>>>>
>>>> ...
>>>>
>>>> 8. Verify that the number of code points is in the range 1 to 63
>>>> inclusive."
>>>>
>>>>
>>>> Here are the questions:
>>>> 1. whether "example..com" is an valid IDN?
>>>> As dot is used as label separators, there are three labels,
>>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
>>>> "example..com" is not a valid IDN.
>>>>
>>>> We need to address the issue in IDN.
>>>>
>>>> 2. whether "xyz." is an valid IDN?
>>>> It's an gray area, I think. We can treat the trailing "." as root
>>>> label, or a label separator.
>>>> If the trailing "." is treated as label separator, "xyz." is
>>>> invalid
>>>> per RFC 3490.
>>>> if the trailing "." is treated as root label, what's the expected
>>>> return value of IDN.toASCII("xyz.")? I think the return value can be
>>>> either "xyz." or "xyz". The current implementation returns "xyz".
>>>>
>>>> We may need not to update the implementation if tailing "." is
>>>> treated as root label.
>>>>
>>>> 3. whether "." is an valid IDN?
>>>> It's an gray area again, I think.
>>>> As above, if the trailing "." is treated as root label, I think
>>>> the
>>>> return value can be either "." or "". The current implementation
>>>> throws
>>>> a StringIndexOutOfBoundsException.
>>>>
>>>> However, what empty domain name ("") really means? I would
>>>> prefer to
>>>> return "." for "." instead.
>>>>
>>>> We need to address the issue in IDN.
>>>>
>>>>
>>>> Here comes the solution, the IDN.toASCII() returns:
>>>> 1. "." for ".";
>>>> 2. "xyz" for "xyz.";
>>>> 3. IAE for "example..com".
>>>>
>>>> Does it make sense?
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>
>>>> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>>>>> I don't really understand the reason for the restriction in
>>>>> SNIHostName
>>>>> But, I guess that is where it should be enforced if it is required.
>>>>>
>>>>> Michael.
>>>>>
>>>>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>>>>> Xuelei,
>>>>>>
>>>>>> . (dot) is perfectly valid domain name and it means root domain so
>>>>>> com.
>>>>>> is valid domain name as well.
>>>>>>
>>>>>> It thinks to me that in context of methods your change we should
>>>>>> ignore
>>>>>> trailing dots, rather than throw exception.
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the bug fix to strict the illegal input checking in
>>>>>>> IDN.
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>>>>
>>>>>>> Here is two test cases, which are expected to get IAE.
>>>>>>>
>>>>>>> Case 1:
>>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>>>>> Exception in thread "main"
>>>>>>> java.lang.StringIndexOutOfBoundsException:
>>>>>>> String index out of range: 0
>>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>>>>
>>>>>>> Case 2:
>>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>
From chris.hegarty at oracle.com Wed Aug 7 08:45:55 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 07 Aug 2013 16:45:55 +0100
Subject: RFR 8022126: Remove throws SocketException from DatagramPacket
constructors accepting SocketAddress
In-Reply-To: <20130806192520.GB5157@mhcomputing.net>
References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com>
<52012FEF.9030307@oracle.com>
<20130806192520.GB5157@mhcomputing.net>
Message-ID: <52026BB3.5000406@oracle.com>
I'm not sure if there is precedent for adding such release notes inline
in the javadoc (and subsequently removed in the next major release), but
I am not opposed to it in principle. I guess it may look something like:
* Note: In this release, this constructor no longer declares
* that it throws {@code SocketException}. Callers that explicitly
* handle {@code SocketException} ( or one of its superclasses )
* may need to remove this explicit exception handling.
Anyone every encounter this kind of comment before, or have a strong
opinion either way ( I'm personally on the fence ).
-Chris.
On 06/08/2013 20:25, Matthew Hall wrote:
> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
>> Documenting in release notes is okay too, but I suspect developers are not
>> likely to look there at first anyway. Thinking aloud, it would be nice if
>> some kind of annotation could be associated with the affected constructors
>> such that a more meaningful/customized error message could be emitted by
>> javac. But, perhaps there aren't sufficient other use cases to justify that.
>
> Many of us use Eclipse, NetBeans, and JavaDoc.
>
> So if we just had a comment in the JavaDoc, saying this was fixed, and what to
> do, that ought to be more than adequate, and would prevent missing it if you
> didn't see the relnotes.
>
> Matthew.
From michael.x.mcmahon at oracle.com Wed Aug 7 08:49:40 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 07 Aug 2013 16:49:40 +0100
Subject: RFR 8022126: Remove throws SocketException from DatagramPacket
constructors accepting SocketAddress
In-Reply-To: <52026BB3.5000406@oracle.com>
References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com>
<52012FEF.9030307@oracle.com>
<20130806192520.GB5157@mhcomputing.net>
<52026BB3.5000406@oracle.com>
Message-ID: <52026C94.3030309@oracle.com>
As a matter of interest, what (if any) precedent is there for such
source incompatible changes? Maybe it's more common that I thought.
Michael.
On 07/08/13 16:45, Chris Hegarty wrote:
> I'm not sure if there is precedent for adding such release notes
> inline in the javadoc (and subsequently removed in the next major
> release), but I am not opposed to it in principle. I guess it may look
> something like:
>
> *
Note: In this release, this constructor no longer declares
> * that it throws {@code SocketException}. Callers that explicitly
> * handle {@code SocketException} ( or one of its superclasses )
> * may need to remove this explicit exception handling.
>
> Anyone every encounter this kind of comment before, or have a strong
> opinion either way ( I'm personally on the fence ).
>
> -Chris.
>
> On 06/08/2013 20:25, Matthew Hall wrote:
>> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
>>> Documenting in release notes is okay too, but I suspect developers
>>> are not
>>> likely to look there at first anyway. Thinking aloud, it would be
>>> nice if
>>> some kind of annotation could be associated with the affected
>>> constructors
>>> such that a more meaningful/customized error message could be
>>> emitted by
>>> javac. But, perhaps there aren't sufficient other use cases to
>>> justify that.
>>
>> Many of us use Eclipse, NetBeans, and JavaDoc.
>>
>> So if we just had a comment in the JavaDoc, saying this was fixed,
>> and what to
>> do, that ought to be more than adequate, and would prevent missing it
>> if you
>> didn't see the relnotes.
>>
>> Matthew.
From joe.darcy at oracle.com Wed Aug 7 09:03:30 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 07 Aug 2013 09:03:30 -0700
Subject: RFR 8022126: Remove throws SocketException from DatagramPacket
constructors accepting SocketAddress
In-Reply-To: <52026C94.3030309@oracle.com>
References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com>
<52012FEF.9030307@oracle.com>
<20130806192520.GB5157@mhcomputing.net>
<52026BB3.5000406@oracle.com> <52026C94.3030309@oracle.com>
Message-ID: <52026FD2.7080902@oracle.com>
Hello,
Source incompatible changes of this magnitude (if not exact character),
have been made in major release before.
IMO, release notes are the proper mechanism to inform users of such a
change rather than the constructor javadoc. (Putting such time-sensitive
notes in javadoc tends to age poorly and become a distraction rather
than a help.)
Cheers,
-Joe
On 08/07/2013 08:49 AM, Michael McMahon wrote:
> As a matter of interest, what (if any) precedent is there for such
> source incompatible changes? Maybe it's more common that I thought.
>
> Michael.
>
> On 07/08/13 16:45, Chris Hegarty wrote:
>> I'm not sure if there is precedent for adding such release notes
>> inline in the javadoc (and subsequently removed in the next major
>> release), but I am not opposed to it in principle. I guess it may
>> look something like:
>>
>> *
Note: In this release, this constructor no longer declares
>> * that it throws {@code SocketException}. Callers that explicitly
>> * handle {@code SocketException} ( or one of its superclasses )
>> * may need to remove this explicit exception handling.
>>
>> Anyone every encounter this kind of comment before, or have a strong
>> opinion either way ( I'm personally on the fence ).
>>
>> -Chris.
>>
>> On 06/08/2013 20:25, Matthew Hall wrote:
>>> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
>>>> Documenting in release notes is okay too, but I suspect developers
>>>> are not
>>>> likely to look there at first anyway. Thinking aloud, it would be
>>>> nice if
>>>> some kind of annotation could be associated with the affected
>>>> constructors
>>>> such that a more meaningful/customized error message could be
>>>> emitted by
>>>> javac. But, perhaps there aren't sufficient other use cases to
>>>> justify that.
>>>
>>> Many of us use Eclipse, NetBeans, and JavaDoc.
>>>
>>> So if we just had a comment in the JavaDoc, saying this was fixed,
>>> and what to
>>> do, that ought to be more than adequate, and would prevent missing
>>> it if you
>>> didn't see the relnotes.
>>>
>>> Matthew.
>
From michael.x.mcmahon at oracle.com Wed Aug 7 09:22:14 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 07 Aug 2013 17:22:14 +0100
Subject: RFR 8022126: Remove throws SocketException from DatagramPacket
constructors accepting SocketAddress
In-Reply-To: <52026FD2.7080902@oracle.com>
References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com>
<52012FEF.9030307@oracle.com>
<20130806192520.GB5157@mhcomputing.net>
<52026BB3.5000406@oracle.com> <52026C94.3030309@oracle.com>
<52026FD2.7080902@oracle.com>
Message-ID: <52027436.3090308@oracle.com>
In that case, my vote would be to just put it in release notes. If there
are others in JDK 8, then maybe
they could be listed together.
Michael
On 07/08/13 17:03, Joe Darcy wrote:
> Hello,
>
> Source incompatible changes of this magnitude (if not exact
> character), have been made in major release before.
>
> IMO, release notes are the proper mechanism to inform users of such a
> change rather than the constructor javadoc. (Putting such
> time-sensitive notes in javadoc tends to age poorly and become a
> distraction rather than a help.)
>
> Cheers,
>
> -Joe
>
> On 08/07/2013 08:49 AM, Michael McMahon wrote:
>> As a matter of interest, what (if any) precedent is there for such
>> source incompatible changes? Maybe it's more common that I thought.
>>
>> Michael.
>>
>> On 07/08/13 16:45, Chris Hegarty wrote:
>>> I'm not sure if there is precedent for adding such release notes
>>> inline in the javadoc (and subsequently removed in the next major
>>> release), but I am not opposed to it in principle. I guess it may
>>> look something like:
>>>
>>> *
Note: In this release, this constructor no longer declares
>>> * that it throws {@code SocketException}. Callers that explicitly
>>> * handle {@code SocketException} ( or one of its superclasses )
>>> * may need to remove this explicit exception handling.
>>>
>>> Anyone every encounter this kind of comment before, or have a strong
>>> opinion either way ( I'm personally on the fence ).
>>>
>>> -Chris.
>>>
>>> On 06/08/2013 20:25, Matthew Hall wrote:
>>>> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote:
>>>>> Documenting in release notes is okay too, but I suspect developers
>>>>> are not
>>>>> likely to look there at first anyway. Thinking aloud, it would be
>>>>> nice if
>>>>> some kind of annotation could be associated with the affected
>>>>> constructors
>>>>> such that a more meaningful/customized error message could be
>>>>> emitted by
>>>>> javac. But, perhaps there aren't sufficient other use cases to
>>>>> justify that.
>>>>
>>>> Many of us use Eclipse, NetBeans, and JavaDoc.
>>>>
>>>> So if we just had a comment in the JavaDoc, saying this was fixed,
>>>> and what to
>>>> do, that ought to be more than adequate, and would prevent missing
>>>> it if you
>>>> didn't see the relnotes.
>>>>
>>>> Matthew.
>>
>
From joe.darcy at oracle.com Wed Aug 7 09:39:59 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 07 Aug 2013 16:39:59 +0000
Subject: hg: jdk8/tl/jdk: 8022454: Fixed various serializations and
deprecation warnings in java.util, java.net and sun.tools
Message-ID: <20130807164058.5468948686@hg.openjdk.java.net>
Changeset: c1f129f62f36
Author: lagergren
Date: 2013-08-07 08:08 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36
8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools
Reviewed-by: darcy
Contributed-by: marcus.lagergren at oracle.com
! src/share/classes/java/net/SocketAddress.java
! src/share/classes/java/util/logging/XMLFormatter.java
! src/share/classes/sun/tools/jar/JarException.java
From dan.xu at oracle.com Wed Aug 7 12:13:55 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Wed, 07 Aug 2013 19:13:55 +0000
Subject: hg: jdk8/tl/jdk: 8022554: Fix Warnings in sun.invoke.anon Package
Message-ID: <20130807191425.1EC9648690@hg.openjdk.java.net>
Changeset: d1c82d5bee3f
Author: dxu
Date: 2013-08-07 12:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c82d5bee3f
8022554: Fix Warnings in sun.invoke.anon Package
Reviewed-by: darcy, mduigou, lancea
! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java
From Alan.Bateman at oracle.com Wed Aug 7 18:05:10 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 07 Aug 2013 18:05:10 -0700
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5202EA83.70207@oracle.com>
References: <5202EA83.70207@oracle.com>
Message-ID: <5202EEC6.8050106@oracle.com>
(cc'ing net-dev).
The change looks okay to me. One suggestion (while you are there) is to
check the return from GetStringUTFChars so that the name returns when
it fails with NULL.
-Alan.
On 07/08/2013 17:46, Ivan Gerasimov wrote:
> Hello everybody!
>
> Some methods of NetworkInterface class were reported to leak memory.
> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.)
>
> Examples are isUp() and isLoopback().
>
> Affected versions of jdk are 6, 7 and 8
>
> Would you please review a simple fix that removes the unnecessary
> allocation?
> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>
> Sincerely yours,
> Ivan
From ivan.gerasimov at oracle.com Wed Aug 7 18:20:04 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 08 Aug 2013 05:20:04 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5202EEC6.8050106@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
Message-ID: <5202F244.6070006@oracle.com>
Thanks Alan!
I've checked that and it turns out that GetStringUTFChars cannot return
NULL.
For allocation of the result string it calls AllocateHeap() with the
default EXIT_OOM fail strategy.
Thus, in case of being unable to allocate memory it simply stops VM.
Sincerely yours,
Ivan
On 08.08.2013 5:05, Alan Bateman wrote:
> (cc'ing net-dev).
>
> The change looks okay to me. One suggestion (while you are there) is
> to check the return from GetStringUTFChars so that the name returns
> when it fails with NULL.
>
> -Alan.
>
> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>> Hello everybody!
>>
>> Some methods of NetworkInterface class were reported to leak memory.
>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.)
>>
>> Examples are isUp() and isLoopback().
>>
>> Affected versions of jdk are 6, 7 and 8
>>
>> Would you please review a simple fix that removes the unnecessary
>> allocation?
>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>
>
>
From stuart.marks at oracle.com Wed Aug 7 16:25:51 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Wed, 07 Aug 2013 23:25:51 +0000
Subject: hg: jdk8/tl/jdk: 8022479: clean up warnings from sun.tools.asm
Message-ID: <20130807232621.8D617486AD@hg.openjdk.java.net>
Changeset: 8c50c27418d3
Author: smarks
Date: 2013-08-07 16:29 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c50c27418d3
8022479: clean up warnings from sun.tools.asm
Reviewed-by: lancea, darcy
! src/share/classes/sun/tools/asm/Assembler.java
! src/share/classes/sun/tools/asm/ConstantPool.java
! src/share/classes/sun/tools/asm/Instruction.java
! src/share/classes/sun/tools/asm/SwitchData.java
! src/share/classes/sun/tools/asm/TryData.java
From david.holmes at oracle.com Wed Aug 7 18:35:16 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 08 Aug 2013 11:35:16 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5202F244.6070006@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com>
Message-ID: <5202F5D4.7070806@oracle.com>
On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
> Thanks Alan!
>
> I've checked that and it turns out that GetStringUTFChars cannot return
> NULL.
> For allocation of the result string it calls AllocateHeap() with the
> default EXIT_OOM fail strategy.
> Thus, in case of being unable to allocate memory it simply stops VM.
Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
OutOfMemoryError if it has memory issues, not abort the VM!
I recommend that you check for NULL and/or a pending exception.
David
> Sincerely yours,
> Ivan
>
> On 08.08.2013 5:05, Alan Bateman wrote:
>> (cc'ing net-dev).
>>
>> The change looks okay to me. One suggestion (while you are there) is
>> to check the return from GetStringUTFChars so that the name returns
>> when it fails with NULL.
>>
>> -Alan.
>>
>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>> Hello everybody!
>>>
>>> Some methods of NetworkInterface class were reported to leak memory.
>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.)
>>>
>>> Examples are isUp() and isLoopback().
>>>
>>> Affected versions of jdk are 6, 7 and 8
>>>
>>> Would you please review a simple fix that removes the unnecessary
>>> allocation?
>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>
>>
>>
>
From Alan.Bateman at oracle.com Wed Aug 7 18:38:28 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 07 Aug 2013 18:38:28 -0700
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5202F244.6070006@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com>
Message-ID: <5202F694.5080707@oracle.com>
On 07/08/2013 18:20, Ivan Gerasimov wrote:
> Thanks Alan!
>
> I've checked that and it turns out that GetStringUTFChars cannot
> return NULL.
> For allocation of the result string it calls AllocateHeap() with the
> default EXIT_OOM fail strategy.
> Thus, in case of being unable to allocate memory it simply stops VM.
>
GetStringUTFChars is supposed to return NULL in OOM situations so this
may be a bug (but if you can, it would be good to handle it in the
NetworkInterface code).
-Alan
From ivan.gerasimov at oracle.com Wed Aug 7 21:05:07 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 08 Aug 2013 08:05:07 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5202F5D4.7070806@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
Message-ID: <520318F3.7080609@oracle.com>
David, Alan,
I added checking for NULL results and throwing OOMException if necessary.
I've also added some spaces along the code to improve indentation.
Would you please review the updated webrev?
http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
Sincerely yours,
Ivan
On 08.08.2013 5:35, David Holmes wrote:
> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>> Thanks Alan!
>>
>> I've checked that and it turns out that GetStringUTFChars cannot return
>> NULL.
>> For allocation of the result string it calls AllocateHeap() with the
>> default EXIT_OOM fail strategy.
>> Thus, in case of being unable to allocate memory it simply stops VM.
>
> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
> OutOfMemoryError if it has memory issues, not abort the VM!
>
> I recommend that you check for NULL and/or a pending exception.
>
> David
>
>> Sincerely yours,
>> Ivan
>>
>> On 08.08.2013 5:05, Alan Bateman wrote:
>>> (cc'ing net-dev).
>>>
>>> The change looks okay to me. One suggestion (while you are there) is
>>> to check the return from GetStringUTFChars so that the name returns
>>> when it fails with NULL.
>>>
>>> -Alan.
>>>
>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>> Hello everybody!
>>>>
>>>> Some methods of NetworkInterface class were reported to leak memory.
>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>> available.)
>>>>
>>>> Examples are isUp() and isLoopback().
>>>>
>>>> Affected versions of jdk are 6, 7 and 8
>>>>
>>>> Would you please review a simple fix that removes the unnecessary
>>>> allocation?
>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>
>>>
>>>
>>
>
>
From masayoshi.okutsu at oracle.com Wed Aug 7 21:52:43 2013
From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com)
Date: Thu, 08 Aug 2013 04:52:43 +0000
Subject: hg: jdk8/tl/jdk: 8015986: Incorrect Localization of HijrahChronology
Message-ID: <20130808045318.043F3486C2@hg.openjdk.java.net>
Changeset: 0beaa65c90c8
Author: okutsu
Date: 2013-08-08 13:51 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0beaa65c90c8
8015986: Incorrect Localization of HijrahChronology
Reviewed-by: naoto
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com
! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/CalendarType.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
From david.holmes at oracle.com Wed Aug 7 22:01:25 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 08 Aug 2013 15:01:25 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <520318F3.7080609@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com>
Message-ID: <52032625.3000501@oracle.com>
Ivan,
On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
> David, Alan,
>
> I added checking for NULL results and throwing OOMException if necessary.
You don't need to throw it yourself:
JNU_ThrowOutOfMemoryError(env, NULL);
Assuming a correct VM implementation if NULL is returned then an OOME
should already be pending and will be thrown as soon as your native code
returns to Java.
Thanks,
David
> I've also added some spaces along the code to improve indentation.
>
> Would you please review the updated webrev?
> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>
> Sincerely yours,
> Ivan
>
>
> On 08.08.2013 5:35, David Holmes wrote:
>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>> Thanks Alan!
>>>
>>> I've checked that and it turns out that GetStringUTFChars cannot return
>>> NULL.
>>> For allocation of the result string it calls AllocateHeap() with the
>>> default EXIT_OOM fail strategy.
>>> Thus, in case of being unable to allocate memory it simply stops VM.
>>
>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>> OutOfMemoryError if it has memory issues, not abort the VM!
>>
>> I recommend that you check for NULL and/or a pending exception.
>>
>> David
>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>> (cc'ing net-dev).
>>>>
>>>> The change looks okay to me. One suggestion (while you are there) is
>>>> to check the return from GetStringUTFChars so that the name returns
>>>> when it fails with NULL.
>>>>
>>>> -Alan.
>>>>
>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>> Hello everybody!
>>>>>
>>>>> Some methods of NetworkInterface class were reported to leak memory.
>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>> available.)
>>>>>
>>>>> Examples are isUp() and isLoopback().
>>>>>
>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>
>>>>> Would you please review a simple fix that removes the unnecessary
>>>>> allocation?
>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>
>>>>
>>>>
>>>
>>
>>
>
From chris.hegarty at oracle.com Thu Aug 8 01:43:04 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 08 Aug 2013 09:43:04 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52032625.3000501@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
Message-ID: <52035A18.8020803@oracle.com>
Thanks for taking this Ivan.
Can you please make the changes suggested by both David and Alan (
simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
fails ( returns NULL ), then I will sponsor this change into jdk8 for you.
Please post an update webrev to cr.openjdk.java.net.
-Chris.
On 08/08/2013 06:01 AM, David Holmes wrote:
> Ivan,
>
> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>> David, Alan,
>>
>> I added checking for NULL results and throwing OOMException if
>> necessary.
>
> You don't need to throw it yourself:
>
> JNU_ThrowOutOfMemoryError(env, NULL);
>
> Assuming a correct VM implementation if NULL is returned then an OOME
> should already be pending and will be thrown as soon as your native code
> returns to Java.
>
> Thanks,
> David
>
>> I've also added some spaces along the code to improve indentation.
>>
>> Would you please review the updated webrev?
>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 08.08.2013 5:35, David Holmes wrote:
>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>> Thanks Alan!
>>>>
>>>> I've checked that and it turns out that GetStringUTFChars cannot return
>>>> NULL.
>>>> For allocation of the result string it calls AllocateHeap() with the
>>>> default EXIT_OOM fail strategy.
>>>> Thus, in case of being unable to allocate memory it simply stops VM.
>>>
>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>
>>> I recommend that you check for NULL and/or a pending exception.
>>>
>>> David
>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>> (cc'ing net-dev).
>>>>>
>>>>> The change looks okay to me. One suggestion (while you are there) is
>>>>> to check the return from GetStringUTFChars so that the name returns
>>>>> when it fails with NULL.
>>>>>
>>>>> -Alan.
>>>>>
>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>> Hello everybody!
>>>>>>
>>>>>> Some methods of NetworkInterface class were reported to leak memory.
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>> available.)
>>>>>>
>>>>>> Examples are isUp() and isLoopback().
>>>>>>
>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>
>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>> allocation?
>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
From vicente.romero at oracle.com Thu Aug 8 03:49:52 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 08 Aug 2013 10:49:52 +0000
Subject: hg: jdk8/tl/langtools: 8019486: javac,
generates erroneous LVT for a test case with lambda code
Message-ID: <20130808105013.81177486D1@hg.openjdk.java.net>
Changeset: b8610a65fbf9
Author: vromero
Date: 2013-08-08 11:49 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b8610a65fbf9
8019486: javac, generates erroneous LVT for a test case with lambda code
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/T8019486/WrongLVTForLambdaTest.java
From weijun.wang at oracle.com Thu Aug 8 06:13:28 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Thu, 08 Aug 2013 13:13:28 +0000
Subject: hg: jdk8/tl/jdk: 8016594: Native Windows ccache still reads DES
tickets
Message-ID: <20130808131448.9A66E486D9@hg.openjdk.java.net>
Changeset: b7d594716f86
Author: weijun
Date: 2013-08-08 21:13 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7d594716f86
8016594: Native Windows ccache still reads DES tickets
Reviewed-by: dsamersoff, xuelei
! src/share/classes/sun/security/krb5/Credentials.java
! src/share/native/sun/security/krb5/nativeccache.c
! src/windows/native/sun/security/krb5/NativeCreds.c
From ivan.gerasimov at oracle.com Thu Aug 8 06:33:34 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 08 Aug 2013 17:33:34 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52035A18.8020803@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com>
Message-ID: <52039E2E.6090504@oracle.com>
Hello Chris!
Here's the update:
http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
Thanks for offering the sponsorship!
Here's the hg-export
http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
Sincerely yours,
Ivan
On 08.08.2013 12:43, Chris Hegarty wrote:
> Thanks for taking this Ivan.
>
> Can you please make the changes suggested by both David and Alan (
> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
> fails ( returns NULL ), then I will sponsor this change into jdk8 for
> you.
>
> Please post an update webrev to cr.openjdk.java.net.
>
> -Chris.
>
> On 08/08/2013 06:01 AM, David Holmes wrote:
>> Ivan,
>>
>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>> David, Alan,
>>>
>>> I added checking for NULL results and throwing OOMException if
>>> necessary.
>>
>> You don't need to throw it yourself:
>>
>> JNU_ThrowOutOfMemoryError(env, NULL);
>>
>> Assuming a correct VM implementation if NULL is returned then an OOME
>> should already be pending and will be thrown as soon as your native code
>> returns to Java.
>>
>> Thanks,
>> David
>>
>>> I've also added some spaces along the code to improve indentation.
>>>
>>> Would you please review the updated webrev?
>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>> On 08.08.2013 5:35, David Holmes wrote:
>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>> Thanks Alan!
>>>>>
>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>> return
>>>>> NULL.
>>>>> For allocation of the result string it calls AllocateHeap() with the
>>>>> default EXIT_OOM fail strategy.
>>>>> Thus, in case of being unable to allocate memory it simply stops VM.
>>>>
>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>
>>>> I recommend that you check for NULL and/or a pending exception.
>>>>
>>>> David
>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>> (cc'ing net-dev).
>>>>>>
>>>>>> The change looks okay to me. One suggestion (while you are there) is
>>>>>> to check the return from GetStringUTFChars so that the name returns
>>>>>> when it fails with NULL.
>>>>>>
>>>>>> -Alan.
>>>>>>
>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>> Hello everybody!
>>>>>>>
>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>> memory.
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>> available.)
>>>>>>>
>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>
>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>
>>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>>> allocation?
>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
From ivan.gerasimov at oracle.com Thu Aug 8 06:39:55 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 08 Aug 2013 17:39:55 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52032625.3000501@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
Message-ID: <52039FAB.3040206@oracle.com>
Thanks, David
I've updated the webrev
http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/.
On 08.08.2013 9:01, David Holmes wrote:
> Ivan,
>
> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>> David, Alan,
>>
>> I added checking for NULL results and throwing OOMException if
>> necessary.
>
> You don't need to throw it yourself:
>
> JNU_ThrowOutOfMemoryError(env, NULL);
>
> Assuming a correct VM implementation if NULL is returned then an OOME
> should already be pending and will be thrown as soon as your native
> code returns to Java.
It seemed to me that, JNU_ThrowOutOfMemoryError only throws an exception
in a case one is not pending.
But I don't mind to remove it, relaying on the correct implementation of
GetStringUTFChars.
Sincerely yours,
Ivan
> Thanks,
> David
>
>> I've also added some spaces along the code to improve indentation.
>>
>> Would you please review the updated webrev?
>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 08.08.2013 5:35, David Holmes wrote:
>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>> Thanks Alan!
>>>>
>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>> return
>>>> NULL.
>>>> For allocation of the result string it calls AllocateHeap() with the
>>>> default EXIT_OOM fail strategy.
>>>> Thus, in case of being unable to allocate memory it simply stops VM.
>>>
>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>
>>> I recommend that you check for NULL and/or a pending exception.
>>>
>>> David
>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>> (cc'ing net-dev).
>>>>>
>>>>> The change looks okay to me. One suggestion (while you are there) is
>>>>> to check the return from GetStringUTFChars so that the name returns
>>>>> when it fails with NULL.
>>>>>
>>>>> -Alan.
>>>>>
>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>> Hello everybody!
>>>>>>
>>>>>> Some methods of NetworkInterface class were reported to leak memory.
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>> available.)
>>>>>>
>>>>>> Examples are isUp() and isLoopback().
>>>>>>
>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>
>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>> allocation?
>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
From chris.hegarty at oracle.com Thu Aug 8 06:50:59 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 08 Aug 2013 14:50:59 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52039E2E.6090504@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
Message-ID: <5203A243.60505@oracle.com>
Looks good to me. Thanks Ivan.
-Chris.
On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
> Hello Chris!
>
> Here's the update:
> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>
> Thanks for offering the sponsorship!
> Here's the hg-export
> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>
>
> Sincerely yours,
> Ivan
>
> On 08.08.2013 12:43, Chris Hegarty wrote:
>> Thanks for taking this Ivan.
>>
>> Can you please make the changes suggested by both David and Alan (
>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
>> fails ( returns NULL ), then I will sponsor this change into jdk8 for
>> you.
>>
>> Please post an update webrev to cr.openjdk.java.net.
>>
>> -Chris.
>>
>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>> Ivan,
>>>
>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>> David, Alan,
>>>>
>>>> I added checking for NULL results and throwing OOMException if
>>>> necessary.
>>>
>>> You don't need to throw it yourself:
>>>
>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>
>>> Assuming a correct VM implementation if NULL is returned then an OOME
>>> should already be pending and will be thrown as soon as your native code
>>> returns to Java.
>>>
>>> Thanks,
>>> David
>>>
>>>> I've also added some spaces along the code to improve indentation.
>>>>
>>>> Would you please review the updated webrev?
>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>> Thanks Alan!
>>>>>>
>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>> return
>>>>>> NULL.
>>>>>> For allocation of the result string it calls AllocateHeap() with the
>>>>>> default EXIT_OOM fail strategy.
>>>>>> Thus, in case of being unable to allocate memory it simply stops VM.
>>>>>
>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>
>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>
>>>>> David
>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>> (cc'ing net-dev).
>>>>>>>
>>>>>>> The change looks okay to me. One suggestion (while you are there) is
>>>>>>> to check the return from GetStringUTFChars so that the name returns
>>>>>>> when it fails with NULL.
>>>>>>>
>>>>>>> -Alan.
>>>>>>>
>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>> Hello everybody!
>>>>>>>>
>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>> memory.
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>> available.)
>>>>>>>>
>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>
>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>
>>>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>>>> allocation?
>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
From michael.x.mcmahon at oracle.com Thu Aug 8 06:51:19 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 08 Aug 2013 14:51:19 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52039FAB.3040206@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52039FAB.3040206@oracle.com>
Message-ID: <5203A257.7000803@oracle.com>
The patch looks good to me. I guess a regression test isn't feasible.
So, the bug will be tagged noreg-hard
Michael
On 08/08/13 14:39, Ivan Gerasimov wrote:
> Thanks, David
>
> I've updated the webrev
> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/.
>
> On 08.08.2013 9:01, David Holmes wrote:
>> Ivan,
>>
>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>> David, Alan,
>>>
>>> I added checking for NULL results and throwing OOMException if
>>> necessary.
>>
>> You don't need to throw it yourself:
>>
>> JNU_ThrowOutOfMemoryError(env, NULL);
>>
>> Assuming a correct VM implementation if NULL is returned then an OOME
>> should already be pending and will be thrown as soon as your native
>> code returns to Java.
>
> It seemed to me that, JNU_ThrowOutOfMemoryError only throws an
> exception in a case one is not pending.
> But I don't mind to remove it, relaying on the correct implementation
> of GetStringUTFChars.
>
> Sincerely yours,
> Ivan
>
>> Thanks,
>> David
>>
>>> I've also added some spaces along the code to improve indentation.
>>>
>>> Would you please review the updated webrev?
>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>> On 08.08.2013 5:35, David Holmes wrote:
>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>> Thanks Alan!
>>>>>
>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>> return
>>>>> NULL.
>>>>> For allocation of the result string it calls AllocateHeap() with the
>>>>> default EXIT_OOM fail strategy.
>>>>> Thus, in case of being unable to allocate memory it simply stops VM.
>>>>
>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>
>>>> I recommend that you check for NULL and/or a pending exception.
>>>>
>>>> David
>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>> (cc'ing net-dev).
>>>>>>
>>>>>> The change looks okay to me. One suggestion (while you are there) is
>>>>>> to check the return from GetStringUTFChars so that the name returns
>>>>>> when it fails with NULL.
>>>>>>
>>>>>> -Alan.
>>>>>>
>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>> Hello everybody!
>>>>>>>
>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>> memory.
>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>> available.)
>>>>>>>
>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>
>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>
>>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>>> allocation?
>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
From Alan.Bateman at oracle.com Thu Aug 8 08:27:20 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 08 Aug 2013 08:27:20 -0700
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52039FAB.3040206@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52039FAB.3040206@oracle.com>
Message-ID: <5203B8D8.3090206@oracle.com>
On 08/08/2013 06:39, Ivan Gerasimov wrote:
> Thanks, David
>
> I've updated the webrev
> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/.
Thanks for fixing the other GetStringUTFChars usages too. This version
looks good to me.
-Alan.
From ivan.gerasimov at oracle.com Thu Aug 8 11:17:57 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 08 Aug 2013 22:17:57 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5203A257.7000803@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52039FAB.3040206@oracle.com> <5203A257.7000803@oracle.com>
Message-ID: <5203E0D5.8000308@oracle.com>
Thank you Michael!
I'm working on the test.
Chris, if it's not too late, I would like to include a regtest into the
change.
It will be ready in a few minutes and I'll send an updated webrev.
Thanks,
Ivan
On 08.08.2013 17:51, Michael McMahon wrote:
> The patch looks good to me. I guess a regression test isn't feasible.
> So, the bug will be tagged noreg-hard
>
> Michael
>
> On 08/08/13 14:39, Ivan Gerasimov wrote:
>> Thanks, David
>>
>> I've updated the webrev
>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/.
>>
>> On 08.08.2013 9:01, David Holmes wrote:
>>> Ivan,
>>>
>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>> David, Alan,
>>>>
>>>> I added checking for NULL results and throwing OOMException if
>>>> necessary.
>>>
>>> You don't need to throw it yourself:
>>>
>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>
>>> Assuming a correct VM implementation if NULL is returned then an
>>> OOME should already be pending and will be thrown as soon as your
>>> native code returns to Java.
>>
>> It seemed to me that, JNU_ThrowOutOfMemoryError only throws an
>> exception in a case one is not pending.
>> But I don't mind to remove it, relaying on the correct implementation
>> of GetStringUTFChars.
>>
>> Sincerely yours,
>> Ivan
>>
>>> Thanks,
>>> David
>>>
>>>> I've also added some spaces along the code to improve indentation.
>>>>
>>>> Would you please review the updated webrev?
>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>> Thanks Alan!
>>>>>>
>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>> return
>>>>>> NULL.
>>>>>> For allocation of the result string it calls AllocateHeap() with the
>>>>>> default EXIT_OOM fail strategy.
>>>>>> Thus, in case of being unable to allocate memory it simply stops VM.
>>>>>
>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>
>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>
>>>>> David
>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>> (cc'ing net-dev).
>>>>>>>
>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>> there) is
>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>> returns
>>>>>>> when it fails with NULL.
>>>>>>>
>>>>>>> -Alan.
>>>>>>>
>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>> Hello everybody!
>>>>>>>>
>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>> memory.
>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>> available.)
>>>>>>>>
>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>
>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>
>>>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>>>> allocation?
>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
>
From ivan.gerasimov at oracle.com Thu Aug 8 11:41:06 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 08 Aug 2013 22:41:06 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5203A243.60505@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com>
Message-ID: <5203E642.40005@oracle.com>
Chris, if it's not too late, I'd like to include a regtest in the fix.
Here's webrev that includes the test:
http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7
as expected.
Sincerely yours,
Ivan
On 08.08.2013 17:50, Chris Hegarty wrote:
> Looks good to me. Thanks Ivan.
>
> -Chris.
>
> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>> Hello Chris!
>>
>> Here's the update:
>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>
>> Thanks for offering the sponsorship!
>> Here's the hg-export
>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>
>>
>>
>> Sincerely yours,
>> Ivan
>>
>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>> Thanks for taking this Ivan.
>>>
>>> Can you please make the changes suggested by both David and Alan (
>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for
>>> you.
>>>
>>> Please post an update webrev to cr.openjdk.java.net.
>>>
>>> -Chris.
>>>
>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>> Ivan,
>>>>
>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>> David, Alan,
>>>>>
>>>>> I added checking for NULL results and throwing OOMException if
>>>>> necessary.
>>>>
>>>> You don't need to throw it yourself:
>>>>
>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>
>>>> Assuming a correct VM implementation if NULL is returned then an OOME
>>>> should already be pending and will be thrown as soon as your native
>>>> code
>>>> returns to Java.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> I've also added some spaces along the code to improve indentation.
>>>>>
>>>>> Would you please review the updated webrev?
>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>>
>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>> Thanks Alan!
>>>>>>>
>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>>> return
>>>>>>> NULL.
>>>>>>> For allocation of the result string it calls AllocateHeap() with
>>>>>>> the
>>>>>>> default EXIT_OOM fail strategy.
>>>>>>> Thus, in case of being unable to allocate memory it simply stops
>>>>>>> VM.
>>>>>>
>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>
>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>> (cc'ing net-dev).
>>>>>>>>
>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>> there) is
>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>> returns
>>>>>>>> when it fails with NULL.
>>>>>>>>
>>>>>>>> -Alan.
>>>>>>>>
>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>> Hello everybody!
>>>>>>>>>
>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>> memory.
>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>> available.)
>>>>>>>>>
>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>
>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>
>>>>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>>>>> allocation?
>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
>
From xueming.shen at oracle.com Thu Aug 8 12:00:49 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Thu, 08 Aug 2013 19:00:49 +0000
Subject: hg: jdk8/tl/jdk: 8015666: test/tools/pack200/TimeStamp.java failing
Message-ID: <20130808190152.9A34248707@hg.openjdk.java.net>
Changeset: a388263a7287
Author: sherman
Date: 2013-08-08 12:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a388263a7287
8015666: test/tools/pack200/TimeStamp.java failing
Summary: to keep the default behavior of ZOS unchanged, if ze extra time not explicitly set
Reviewed-by: alanb, ksrini
! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipEntry.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/java/util/zip/ZipInputStream.java
! src/share/classes/java/util/zip/ZipOutputStream.java
! src/share/classes/java/util/zip/ZipUtils.java
! test/ProblemList.txt
! test/java/util/zip/TestExtraTime.java
! test/tools/pack200/TimeStamp.java
From david.holmes at oracle.com Thu Aug 8 14:15:34 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 09 Aug 2013 07:15:34 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5203E642.40005@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
Message-ID: <52040A76.3060602@oracle.com>
Main fix looks good to me.
Regression test may need some tweaking eg I think othervm will be needed.
Also this:
System.out.println("WARNING: Cannot perform memory leak detection on
this OS");
should probably just say something like "Test skipped on this OS" -
there are other tests that do this so just check if there is common
terminology. (In the future we may have keyword tags to flag this as
linux only etc.)
Thanks,
David
On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
> Chris, if it's not too late, I'd like to include a regtest in the fix.
>
> Here's webrev that includes the test:
> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>
> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7
> as expected.
>
> Sincerely yours,
> Ivan
>
> On 08.08.2013 17:50, Chris Hegarty wrote:
>> Looks good to me. Thanks Ivan.
>>
>> -Chris.
>>
>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>> Hello Chris!
>>>
>>> Here's the update:
>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>
>>> Thanks for offering the sponsorship!
>>> Here's the hg-export
>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>
>>>
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>> Thanks for taking this Ivan.
>>>>
>>>> Can you please make the changes suggested by both David and Alan (
>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for
>>>> you.
>>>>
>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>
>>>> -Chris.
>>>>
>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>> Ivan,
>>>>>
>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>> David, Alan,
>>>>>>
>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>> necessary.
>>>>>
>>>>> You don't need to throw it yourself:
>>>>>
>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>
>>>>> Assuming a correct VM implementation if NULL is returned then an OOME
>>>>> should already be pending and will be thrown as soon as your native
>>>>> code
>>>>> returns to Java.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> I've also added some spaces along the code to improve indentation.
>>>>>>
>>>>>> Would you please review the updated webrev?
>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>>
>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>> Thanks Alan!
>>>>>>>>
>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>>>> return
>>>>>>>> NULL.
>>>>>>>> For allocation of the result string it calls AllocateHeap() with
>>>>>>>> the
>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>> Thus, in case of being unable to allocate memory it simply stops
>>>>>>>> VM.
>>>>>>>
>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw
>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>
>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>
>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>> there) is
>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>> returns
>>>>>>>>> when it fails with NULL.
>>>>>>>>>
>>>>>>>>> -Alan.
>>>>>>>>>
>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>> Hello everybody!
>>>>>>>>>>
>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>> memory.
>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>> available.)
>>>>>>>>>>
>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>
>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>
>>>>>>>>>> Would you please review a simple fix that removes the unnecessary
>>>>>>>>>> allocation?
>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>
From michael.x.mcmahon at oracle.com Thu Aug 8 14:38:34 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 08 Aug 2013 22:38:34 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52040A76.3060602@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com>
Message-ID: <52040FDA.2040600@oracle.com>
Yes, definitely "othervm" would be required for the test. Also, why skip
other OS'es?
The fix is only for Linux, but it might catch future leaks on Windows.
The trouble with tests like this, is they sometimes don't age well.
Future changes in OS kernel behavior could cause problems but I guess
32MB is a fairly large difference.
So, it should be okay
Michael
On 08/08/13 22:15, David Holmes wrote:
> Main fix looks good to me.
>
> Regression test may need some tweaking eg I think othervm will be needed.
>
> Also this:
>
> System.out.println("WARNING: Cannot perform memory leak detection on
> this OS");
>
> should probably just say something like "Test skipped on this OS" -
> there are other tests that do this so just check if there is common
> terminology. (In the future we may have keyword tags to flag this as
> linux only etc.)
>
> Thanks,
> David
>
> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>> Chris, if it's not too late, I'd like to include a regtest in the fix.
>>
>> Here's webrev that includes the test:
>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>
>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7
>> as expected.
>>
>> Sincerely yours,
>> Ivan
>>
>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>> Looks good to me. Thanks Ivan.
>>>
>>> -Chris.
>>>
>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>> Hello Chris!
>>>>
>>>> Here's the update:
>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>
>>>> Thanks for offering the sponsorship!
>>>> Here's the hg-export
>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>
>>>>
>>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>> Thanks for taking this Ivan.
>>>>>
>>>>> Can you please make the changes suggested by both David and Alan (
>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for
>>>>> you.
>>>>>
>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>> Ivan,
>>>>>>
>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>> David, Alan,
>>>>>>>
>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>> necessary.
>>>>>>
>>>>>> You don't need to throw it yourself:
>>>>>>
>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>
>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>> OOME
>>>>>> should already be pending and will be thrown as soon as your native
>>>>>> code
>>>>>> returns to Java.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> I've also added some spaces along the code to improve indentation.
>>>>>>>
>>>>>>> Would you please review the updated webrev?
>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>>
>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>> Thanks Alan!
>>>>>>>>>
>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>>>>> return
>>>>>>>>> NULL.
>>>>>>>>> For allocation of the result string it calls AllocateHeap() with
>>>>>>>>> the
>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops
>>>>>>>>> VM.
>>>>>>>>
>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>> throw
>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>
>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>
>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>> there) is
>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>> returns
>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>
>>>>>>>>>> -Alan.
>>>>>>>>>>
>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>
>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>> memory.
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>> available.)
>>>>>>>>>>>
>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>
>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>
>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>> unnecessary
>>>>>>>>>>> allocation?
>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>
>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
From ivan.gerasimov at oracle.com Thu Aug 8 15:15:49 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 09 Aug 2013 02:15:49 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52040FDA.2040600@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com>
Message-ID: <52041895.9010706@oracle.com>
Michael,
The test uses /proc/self/stat file to detect changes in virtual memory
usage.
This approach is specific for Linux.
That's why I included the check of OS in the test.
Sincerely yours,
Ivan
On 09.08.2013 1:38, Michael McMahon wrote:
> Yes, definitely "othervm" would be required for the test. Also, why
> skip other OS'es?
> The fix is only for Linux, but it might catch future leaks on Windows.
>
> The trouble with tests like this, is they sometimes don't age well.
> Future changes in OS kernel behavior could cause problems but I guess
> 32MB is a fairly large difference.
> So, it should be okay
>
> Michael
>
> On 08/08/13 22:15, David Holmes wrote:
>> Main fix looks good to me.
>>
>> Regression test may need some tweaking eg I think othervm will be
>> needed.
>>
>> Also this:
>>
>> System.out.println("WARNING: Cannot perform memory leak detection on
>> this OS");
>>
>> should probably just say something like "Test skipped on this OS" -
>> there are other tests that do this so just check if there is common
>> terminology. (In the future we may have keyword tags to flag this as
>> linux only etc.)
>>
>> Thanks,
>> David
>>
>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>> Chris, if it's not too late, I'd like to include a regtest in the fix.
>>>
>>> Here's webrev that includes the test:
>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>
>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and
>>> jdk7
>>> as expected.
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>> Looks good to me. Thanks Ivan.
>>>>
>>>> -Chris.
>>>>
>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>> Hello Chris!
>>>>>
>>>>> Here's the update:
>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>
>>>>> Thanks for offering the sponsorship!
>>>>> Here's the hg-export
>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>> Thanks for taking this Ivan.
>>>>>>
>>>>>> Can you please make the changes suggested by both David and Alan (
>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>> GetStringUTFChars
>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8
>>>>>> for
>>>>>> you.
>>>>>>
>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>> Ivan,
>>>>>>>
>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>> David, Alan,
>>>>>>>>
>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>> necessary.
>>>>>>>
>>>>>>> You don't need to throw it yourself:
>>>>>>>
>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>
>>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>>> OOME
>>>>>>> should already be pending and will be thrown as soon as your native
>>>>>>> code
>>>>>>> returns to Java.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> I've also added some spaces along the code to improve indentation.
>>>>>>>>
>>>>>>>> Would you please review the updated webrev?
>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>> Thanks Alan!
>>>>>>>>>>
>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>>>>>> return
>>>>>>>>>> NULL.
>>>>>>>>>> For allocation of the result string it calls AllocateHeap() with
>>>>>>>>>> the
>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops
>>>>>>>>>> VM.
>>>>>>>>>
>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>> throw
>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>
>>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>
>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>> there) is
>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>> returns
>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>
>>>>>>>>>>> -Alan.
>>>>>>>>>>>
>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>
>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>>> memory.
>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>> available.)
>>>>>>>>>>>>
>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>
>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>
>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>> unnecessary
>>>>>>>>>>>> allocation?
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
>
From michael.x.mcmahon at oracle.com Thu Aug 8 15:19:17 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 08 Aug 2013 23:19:17 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52041895.9010706@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com>
<52041895.9010706@oracle.com>
Message-ID: <52041965.3090808@oracle.com>
Ivan,
Right, it's not worth trying to do the equivalent, whatever it is, for
Windows.
The test is fine with me.
Thanks
Michael
On 08/08/13 23:15, Ivan Gerasimov wrote:
> Michael,
>
> The test uses /proc/self/stat file to detect changes in virtual memory
> usage.
> This approach is specific for Linux.
> That's why I included the check of OS in the test.
>
> Sincerely yours,
> Ivan
>
> On 09.08.2013 1:38, Michael McMahon wrote:
>> Yes, definitely "othervm" would be required for the test. Also, why
>> skip other OS'es?
>> The fix is only for Linux, but it might catch future leaks on Windows.
>>
>> The trouble with tests like this, is they sometimes don't age well.
>> Future changes in OS kernel behavior could cause problems but I guess
>> 32MB is a fairly large difference.
>> So, it should be okay
>>
>> Michael
>>
>> On 08/08/13 22:15, David Holmes wrote:
>>> Main fix looks good to me.
>>>
>>> Regression test may need some tweaking eg I think othervm will be
>>> needed.
>>>
>>> Also this:
>>>
>>> System.out.println("WARNING: Cannot perform memory leak detection
>>> on this OS");
>>>
>>> should probably just say something like "Test skipped on this OS" -
>>> there are other tests that do this so just check if there is common
>>> terminology. (In the future we may have keyword tags to flag this as
>>> linux only etc.)
>>>
>>> Thanks,
>>> David
>>>
>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>> Chris, if it's not too late, I'd like to include a regtest in the fix.
>>>>
>>>> Here's webrev that includes the test:
>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>
>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and
>>>> jdk7
>>>> as expected.
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>> Looks good to me. Thanks Ivan.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>> Hello Chris!
>>>>>>
>>>>>> Here's the update:
>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>
>>>>>> Thanks for offering the sponsorship!
>>>>>> Here's the hg-export
>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>> Thanks for taking this Ivan.
>>>>>>>
>>>>>>> Can you please make the changes suggested by both David and Alan (
>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>> GetStringUTFChars
>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>> jdk8 for
>>>>>>> you.
>>>>>>>
>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>> Ivan,
>>>>>>>>
>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>> David, Alan,
>>>>>>>>>
>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>> necessary.
>>>>>>>>
>>>>>>>> You don't need to throw it yourself:
>>>>>>>>
>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>
>>>>>>>> Assuming a correct VM implementation if NULL is returned then
>>>>>>>> an OOME
>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>> native
>>>>>>>> code
>>>>>>>> returns to Java.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>> indentation.
>>>>>>>>>
>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>
>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>> cannot
>>>>>>>>>>> return
>>>>>>>>>>> NULL.
>>>>>>>>>>> For allocation of the result string it calls AllocateHeap()
>>>>>>>>>>> with
>>>>>>>>>>> the
>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>> stops
>>>>>>>>>>> VM.
>>>>>>>>>>
>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>>> throw
>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>
>>>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>> Ivan
>>>>>>>>>>>
>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>
>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>> there) is
>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>> returns
>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>
>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>
>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>>>> memory.
>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>
>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
>
From ivan.gerasimov at oracle.com Thu Aug 8 15:19:52 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 09 Aug 2013 02:19:52 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52040A76.3060602@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com>
Message-ID: <52041988.80705@oracle.com>
Thanks David!
On 09.08.2013 1:15, David Holmes wrote:
> Main fix looks good to me.
>
> Regression test may need some tweaking eg I think othervm will be needed.
>
Yes, it's a good point.
Since there may be a memory leak in the test, it'd better not interfere
with other tests in jtreg.
> Also this:
>
> System.out.println("WARNING: Cannot perform memory leak detection on
> this OS");
>
> should probably just say something like "Test skipped on this OS" -
> there are other tests that do this so just check if there is common
> terminology. (In the future we may have keyword tags to flag this as
> linux only etc.)
>
OK, I changed the phrase to "Test only runs on Linux".
Updated webrev is here:
http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
Updated export is at the same place:
http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
Sincerely yours,
Ivan
> Thanks,
> David
>
> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>> Chris, if it's not too late, I'd like to include a regtest in the fix.
>>
>> Here's webrev that includes the test:
>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>
>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7
>> as expected.
>>
>> Sincerely yours,
>> Ivan
>>
>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>> Looks good to me. Thanks Ivan.
>>>
>>> -Chris.
>>>
>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>> Hello Chris!
>>>>
>>>> Here's the update:
>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>
>>>> Thanks for offering the sponsorship!
>>>> Here's the hg-export
>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>
>>>>
>>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>> Thanks for taking this Ivan.
>>>>>
>>>>> Can you please make the changes suggested by both David and Alan (
>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for
>>>>> you.
>>>>>
>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>> Ivan,
>>>>>>
>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>> David, Alan,
>>>>>>>
>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>> necessary.
>>>>>>
>>>>>> You don't need to throw it yourself:
>>>>>>
>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>
>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>> OOME
>>>>>> should already be pending and will be thrown as soon as your native
>>>>>> code
>>>>>> returns to Java.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> I've also added some spaces along the code to improve indentation.
>>>>>>>
>>>>>>> Would you please review the updated webrev?
>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>>
>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>> Thanks Alan!
>>>>>>>>>
>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>>>>> return
>>>>>>>>> NULL.
>>>>>>>>> For allocation of the result string it calls AllocateHeap() with
>>>>>>>>> the
>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops
>>>>>>>>> VM.
>>>>>>>>
>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>> throw
>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>
>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>
>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>> there) is
>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>> returns
>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>
>>>>>>>>>> -Alan.
>>>>>>>>>>
>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>
>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>> memory.
>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>> available.)
>>>>>>>>>>>
>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>
>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>
>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>> unnecessary
>>>>>>>>>>> allocation?
>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>
>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
From ivan.gerasimov at oracle.com Thu Aug 8 15:24:36 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 09 Aug 2013 02:24:36 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52041965.3090808@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com>
<52041895.9010706@oracle.com> <52041965.3090808@oracle.com>
Message-ID: <52041AA4.2000406@oracle.com>
Thank you Michael!
On 09.08.2013 2:19, Michael McMahon wrote:
> Ivan,
>
> Right, it's not worth trying to do the equivalent, whatever it is, for
> Windows.
> The test is fine with me.
>
> Thanks
> Michael
>
> On 08/08/13 23:15, Ivan Gerasimov wrote:
>> Michael,
>>
>> The test uses /proc/self/stat file to detect changes in virtual
>> memory usage.
>> This approach is specific for Linux.
>> That's why I included the check of OS in the test.
>>
>> Sincerely yours,
>> Ivan
>>
>> On 09.08.2013 1:38, Michael McMahon wrote:
>>> Yes, definitely "othervm" would be required for the test. Also, why
>>> skip other OS'es?
>>> The fix is only for Linux, but it might catch future leaks on Windows.
>>>
>>> The trouble with tests like this, is they sometimes don't age well.
>>> Future changes in OS kernel behavior could cause problems but I
>>> guess 32MB is a fairly large difference.
>>> So, it should be okay
>>>
>>> Michael
>>>
>>> On 08/08/13 22:15, David Holmes wrote:
>>>> Main fix looks good to me.
>>>>
>>>> Regression test may need some tweaking eg I think othervm will be
>>>> needed.
>>>>
>>>> Also this:
>>>>
>>>> System.out.println("WARNING: Cannot perform memory leak detection
>>>> on this OS");
>>>>
>>>> should probably just say something like "Test skipped on this OS" -
>>>> there are other tests that do this so just check if there is common
>>>> terminology. (In the future we may have keyword tags to flag this
>>>> as linux only etc.)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>> fix.
>>>>>
>>>>> Here's webrev that includes the test:
>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>
>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101
>>>>> and jdk7
>>>>> as expected.
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>> Looks good to me. Thanks Ivan.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>> Hello Chris!
>>>>>>>
>>>>>>> Here's the update:
>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>
>>>>>>> Thanks for offering the sponsorship!
>>>>>>> Here's the hg-export
>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>
>>>>>>>> Can you please make the changes suggested by both David and Alan (
>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>> GetStringUTFChars
>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>> jdk8 for
>>>>>>>> you.
>>>>>>>>
>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>> Ivan,
>>>>>>>>>
>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>> David, Alan,
>>>>>>>>>>
>>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>>> necessary.
>>>>>>>>>
>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>
>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>
>>>>>>>>> Assuming a correct VM implementation if NULL is returned then
>>>>>>>>> an OOME
>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>> native
>>>>>>>>> code
>>>>>>>>> returns to Java.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>> indentation.
>>>>>>>>>>
>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>
>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>> cannot
>>>>>>>>>>>> return
>>>>>>>>>>>> NULL.
>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap()
>>>>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>> stops
>>>>>>>>>>>> VM.
>>>>>>>>>>>
>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed
>>>>>>>>>>> to throw
>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>
>>>>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>>> there) is
>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>>> returns
>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>
>
From xuelei.fan at oracle.com Thu Aug 8 17:41:23 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 Aug 2013 08:41:23 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <520264F1.1090802@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
Message-ID: <52043AB3.6060704@oracle.com>
Ping.
Thanks,
Xuelei
On 8/7/2013 11:17 PM, Xuelei Fan wrote:
> Please review the new update:
>
> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>
> With this update, "com." is valid (return "com."); "." and
> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>
> Thanks,
> Xuelei
>
> On 8/7/2013 10:18 PM, Michael McMahon wrote:
>> On 07/08/13 15:13, Xuelei Fan wrote:
>>> On 8/7/2013 10:05 PM, Michael McMahon wrote:
>>>> Resolvers seem to accept queries using trailing dots.
>>>>
>>>> eg nslookup www.oracle.com.
>>>>
>>>> or InetAddress.getByName("www.oracle.com.");
>>>>
>>>> The part of RFC3490 quoted below seems to me to be saying
>>>> that the empty label implied by the trailing dot is not regarded
>>>> as a label so that you don't end up calling toAscii() or toUnicode()
>>>> with an empty string. I don't think it's saying the trailing dot can't
>>>> be there.
>>>>
>>> It makes sense.
>>>
>>> What's your preference to return for IDN.toASCII("www.oracle.com."),
>>> "www.oracle.com." or "www.oracle.com"? The current returned value is
>>> "www.oracle.com". I would like to reserve the behavior in this update.
>>
>> My opinion is to keep it as at present ie. "www.oracle.com."
>>
>> Michael
>>
>>> I think we are on same page soon.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> Michael
>>>>
>>>> On 07/08/13 13:44, Xuelei Fan wrote:
>>>>> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>>>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>>>>>> and the single dot represents the root zone. So you have to be
>>>>>> careful making this sort of change to check the DNS RFCs first.
>>>>> That's the first question we need to answer, whether IDN allow tailling
>>>>> dots ("com."), zero-length root label ("."), and zero-length label ("",
>>>>> for example ""example..com")?
>>>>>
>>>>> Per the specification of IDN.toASCII():
>>>>> =======================================
>>>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
>>>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In
>>>>> this case, the input string should not be used in an internationalized
>>>>> domain name.
>>>>>
>>>>> A label is an individual part of a domain name. The original ToASCII
>>>>> operation, as defined in RFC 3490, only operates on a single label.
>>>>> This
>>>>> method can handle both label and entire domain name, by assuming that
>>>>> labels in a domain name are always separated by dots. ...
>>>>>
>>>>> Throws IllegalArgumentException - if the input string doesn't
>>>>> conform to
>>>>> RFC 3490 specification"
>>>>>
>>>>> Per the specification of RFC 3490:
>>>>> ==================================
>>>>> [section 2]
>>>>> "A label is an individual part of a domain name. Labels are usually
>>>>> shown separated by dots; for example, the domain name
>>>>> "www.example.com" is composed of three labels: "www", "example", and
>>>>> "com". (The zero-length root label described in [STD13], which can
>>>>> be explicit as in "www.example.com." or implicit as in
>>>>> "www.example.com", is not considered a label in this
>>>>> specification.)"
>>>>>
>>>>> "An "internationalized label" is a label to which the ToASCII
>>>>> operation (see section 4) can be applied without failing (with the
>>>>> UseSTD3ASCIIRules flag unset). ...
>>>>> Although most Unicode characters can appear in
>>>>> internationalized labels, ToASCII will fail for some input strings,
>>>>> and such strings are not valid internationalized labels."
>>>>>
>>>>> "An "internationalized domain name" (IDN) is a domain name in which
>>>>> every label is an internationalized label."
>>>>>
>>>>> [Section 4.1]
>>>>> "ToASCII consists of the following steps:
>>>>>
>>>>> ...
>>>>>
>>>>> 8. Verify that the number of code points is in the range 1 to 63
>>>>> inclusive."
>>>>>
>>>>>
>>>>> Here are the questions:
>>>>> 1. whether "example..com" is an valid IDN?
>>>>> As dot is used as label separators, there are three labels,
>>>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
>>>>> "example..com" is not a valid IDN.
>>>>>
>>>>> We need to address the issue in IDN.
>>>>>
>>>>> 2. whether "xyz." is an valid IDN?
>>>>> It's an gray area, I think. We can treat the trailing "." as root
>>>>> label, or a label separator.
>>>>> If the trailing "." is treated as label separator, "xyz." is
>>>>> invalid
>>>>> per RFC 3490.
>>>>> if the trailing "." is treated as root label, what's the expected
>>>>> return value of IDN.toASCII("xyz.")? I think the return value can be
>>>>> either "xyz." or "xyz". The current implementation returns "xyz".
>>>>>
>>>>> We may need not to update the implementation if tailing "." is
>>>>> treated as root label.
>>>>>
>>>>> 3. whether "." is an valid IDN?
>>>>> It's an gray area again, I think.
>>>>> As above, if the trailing "." is treated as root label, I think
>>>>> the
>>>>> return value can be either "." or "". The current implementation
>>>>> throws
>>>>> a StringIndexOutOfBoundsException.
>>>>>
>>>>> However, what empty domain name ("") really means? I would
>>>>> prefer to
>>>>> return "." for "." instead.
>>>>>
>>>>> We need to address the issue in IDN.
>>>>>
>>>>>
>>>>> Here comes the solution, the IDN.toASCII() returns:
>>>>> 1. "." for ".";
>>>>> 2. "xyz" for "xyz.";
>>>>> 3. IAE for "example..com".
>>>>>
>>>>> Does it make sense?
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>>
>>>>> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>>>>>> I don't really understand the reason for the restriction in
>>>>>> SNIHostName
>>>>>> But, I guess that is where it should be enforced if it is required.
>>>>>>
>>>>>> Michael.
>>>>>>
>>>>>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>>>>>> Xuelei,
>>>>>>>
>>>>>>> . (dot) is perfectly valid domain name and it means root domain so
>>>>>>> com.
>>>>>>> is valid domain name as well.
>>>>>>>
>>>>>>> It thinks to me that in context of methods your change we should
>>>>>>> ignore
>>>>>>> trailing dots, rather than throw exception.
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the bug fix to strict the illegal input checking in
>>>>>>>> IDN.
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>>>>>
>>>>>>>> Here is two test cases, which are expected to get IAE.
>>>>>>>>
>>>>>>>> Case 1:
>>>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>>>>>> Exception in thread "main"
>>>>>>>> java.lang.StringIndexOutOfBoundsException:
>>>>>>>> String index out of range: 0
>>>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>>>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>>>>>
>>>>>>>> Case 2:
>>>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Xuelei
>>>>>>>>
>>
>
From weijun.wang at oracle.com Thu Aug 8 18:22:53 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 09 Aug 2013 09:22:53 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52043AB3.6060704@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com>
Message-ID: <5204446D.7030603@oracle.com>
I tried nslookup. Those with ".." inside are illegal,
$ nslookup com..
nslookup: 'com..' is not a legal name (empty label)
but
$ nslookup .
Server: 192.168.10.1
Address: 192.168.10.1#53
Non-authoritative answer:
*** Can't find .: No answer
Also, since this bug was originally about SNIHostName, do you need to
add some extra restriction there to reject "oracle.com." things?
Thanks
Max
On 8/9/13 8:41 AM, Xuelei Fan wrote:
> Ping.
>
> Thanks,
> Xuelei
>
> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>> Please review the new update:
>>
>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>
>> With this update, "com." is valid (return "com."); "." and
>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>
>> Thanks,
>> Xuelei
>>
From xuelei.fan at oracle.com Thu Aug 8 18:37:01 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 Aug 2013 09:37:01 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5204446D.7030603@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
Message-ID: <520447BD.30206@oracle.com>
On 8/9/2013 9:22 AM, Weijun Wang wrote:
> I tried nslookup. Those with ".." inside are illegal,
>
> $ nslookup com..
> nslookup: 'com..' is not a legal name (empty label)
>
> but
>
> $ nslookup .
> Server: 192.168.10.1
> Address: 192.168.10.1#53
>
> Non-authoritative answer:
> *** Can't find .: No answer
>
Thanks for the testing. The behaviors are the same as this fix now.
Learn something new today to use nslookup.
> Also, since this bug was originally about SNIHostName, do you need to
> add some extra restriction there to reject "oracle.com." things?
>
No, we cannot restrict the format of IDN in SNIHostName more than in
IDN. However, we may need to rethink about the comparing of two IDN, for
example, "example.com." should equal to "example.com". I want to
consider it in another bug.
Can I push the changeset?
Thanks,
Xuelei
> Thanks
> Max
>
> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>> Ping.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>> Please review the new update:
>>>
>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>
>>> With this update, "com." is valid (return "com."); "." and
>>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>>
>>> Thanks,
>>> Xuelei
>>>
From weijun.wang at oracle.com Thu Aug 8 19:14:08 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 09 Aug 2013 10:14:08 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <520447BD.30206@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com>
Message-ID: <52045070.1000506@oracle.com>
On 8/9/13 9:37 AM, Xuelei Fan wrote:
> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>> I tried nslookup. Those with ".." inside are illegal,
>>
>> $ nslookup com..
>> nslookup: 'com..' is not a legal name (empty label)
>>
>> but
>>
>> $ nslookup .
>> Server: 192.168.10.1
>> Address: 192.168.10.1#53
>>
>> Non-authoritative answer:
>> *** Can't find .: No answer
>>
> Thanks for the testing. The behaviors are the same as this fix now.
No exactly. It seems nslookup still regards "." legal but just cannot
find an IP for it.
>
> Learn something new today to use nslookup.
>
>> Also, since this bug was originally about SNIHostName, do you need to
>> add some extra restriction there to reject "oracle.com." things?
>>
> No, we cannot restrict the format of IDN in SNIHostName more than in
> IDN. However, we may need to rethink about the comparing of two IDN, for
> example, "example.com." should equal to "example.com". I want to
> consider it in another bug.
Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And
it's not one is another's subset?
>
> Can I push the changeset?
I think it's better to ask someone in the networking team to make the
suggestion. From what I read Michael in this thread, he does not seem
totally agreed with your code changes (at least not the 00 version).
Thanks
Max
>
> Thanks,
> Xuelei
>
>> Thanks
>> Max
>>
>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>> Ping.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>> Please review the new update:
>>>>
>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>
>>>> With this update, "com." is valid (return "com."); "." and
>>>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>
From xuelei.fan at oracle.com Thu Aug 8 19:50:07 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 Aug 2013 10:50:07 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52045070.1000506@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
Message-ID: <520458DF.1030502@oracle.com>
On 8/9/2013 10:14 AM, Weijun Wang wrote:
>
>
> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>> I tried nslookup. Those with ".." inside are illegal,
>>>
>>> $ nslookup com..
>>> nslookup: 'com..' is not a legal name (empty label)
>>>
>>> but
>>>
>>> $ nslookup .
>>> Server: 192.168.10.1
>>> Address: 192.168.10.1#53
>>>
>>> Non-authoritative answer:
>>> *** Can't find .: No answer
>>>
>> Thanks for the testing. The behaviors are the same as this fix now.
>
> No exactly. It seems nslookup still regards "." legal but just cannot
> find an IP for it.
>
I'm not sure whether a root domain name can be stand alone. Root label
is not considered as a label in IDN. I think it is safe to regard that
"." is not a valid IDN as it contains no label. Anyway, it is a corner
case.
There are many online IDN conversion web services, some of them can
convert ".", some of the cannot. In the present implementation, we
cannot recognize ".", and IDN.toASCII(".") throws
StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
a better exception for IDN.toASCII(".").
>>
>> Learn something new today to use nslookup.
>>
>>> Also, since this bug was originally about SNIHostName, do you need to
>>> add some extra restriction there to reject "oracle.com." things?
>>>
>> No, we cannot restrict the format of IDN in SNIHostName more than in
>> IDN. However, we may need to rethink about the comparing of two IDN, for
>> example, "example.com." should equal to "example.com". I want to
>> consider it in another bug.
>
> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And
> it's not one is another's subset?
>
Per TLS specification, host name in SNI is an IDN. The spec of
SNIHostname says, "hostname is not a valid Internationalized Domain Name
(IDN) compliant with the RFC 3490 specification". The spec in
SNIHostName has the same means as IDN. I won't want to add additional
restrict beyond the specification of an IDN.
Xuelei
>>
>> Can I push the changeset?
>
> I think it's better to ask someone in the networking team to make the
> suggestion. From what I read Michael in this thread, he does not seem
> totally agreed with your code changes (at least not the 00 version).
>
> Thanks
> Max
>
>>
>> Thanks,
>> Xuelei
>>
>>> Thanks
>>> Max
>>>
>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>> Ping.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>> Please review the new update:
>>>>>
>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>
>>>>> With this update, "com." is valid (return "com."); "." and
>>>>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>
From mhall at mhcomputing.net Thu Aug 8 20:24:41 2013
From: mhall at mhcomputing.net (Matthew Hall)
Date: Thu, 08 Aug 2013 20:24:41 -0700
Subject: Code review request,
8020842 IDN do not throw IAE when hostname ends with a trailing dot
In-Reply-To: <520458DF.1030502@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com>
Message-ID:
But, DNS considers "." as the valid root zone...
--
Sent from my mobile device.
Xuelei Fan wrote:
>On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>
>>
>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>
>>>> $ nslookup com..
>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>
>>>> but
>>>>
>>>> $ nslookup .
>>>> Server: 192.168.10.1
>>>> Address: 192.168.10.1#53
>>>>
>>>> Non-authoritative answer:
>>>> *** Can't find .: No answer
>>>>
>>> Thanks for the testing. The behaviors are the same as this fix now.
>>
>> No exactly. It seems nslookup still regards "." legal but just cannot
>> find an IP for it.
>>
>I'm not sure whether a root domain name can be stand alone. Root label
>is not considered as a label in IDN. I think it is safe to regard that
>"." is not a valid IDN as it contains no label. Anyway, it is a corner
>case.
>
>There are many online IDN conversion web services, some of them can
>convert ".", some of the cannot. In the present implementation, we
>cannot recognize ".", and IDN.toASCII(".") throws
>StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
>a better exception for IDN.toASCII(".").
>
>>>
>>> Learn something new today to use nslookup.
>>>
>>>> Also, since this bug was originally about SNIHostName, do you need
>to
>>>> add some extra restriction there to reject "oracle.com." things?
>>>>
>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>> IDN. However, we may need to rethink about the comparing of two IDN,
>for
>>> example, "example.com." should equal to "example.com". I want to
>>> consider it in another bug.
>>
>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets?
>And
>> it's not one is another's subset?
>>
>Per TLS specification, host name in SNI is an IDN. The spec of
>SNIHostname says, "hostname is not a valid Internationalized Domain
>Name
>(IDN) compliant with the RFC 3490 specification". The spec in
>SNIHostName has the same means as IDN. I won't want to add additional
>restrict beyond the specification of an IDN.
>
>Xuelei
>
>>>
>>> Can I push the changeset?
>>
>> I think it's better to ask someone in the networking team to make the
>> suggestion. From what I read Michael in this thread, he does not seem
>> totally agreed with your code changes (at least not the 00 version).
>>
>> Thanks
>> Max
>>
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> Thanks
>>>> Max
>>>>
>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>> Ping.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>> Please review the new update:
>>>>>>
>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>
>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>> "example..com" are invalid. And IAE will be thrown for invalid
>IDN.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>
From weijun.wang at oracle.com Thu Aug 8 20:42:53 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 09 Aug 2013 03:42:53 +0000
Subject: hg: jdk8/tl/jdk: 8021788: JarInputStream doesn't provide certificates
for some file under META-INF
Message-ID: <20130809034314.C36B848735@hg.openjdk.java.net>
Changeset: 758e3117899c
Author: weijun
Date: 2013-08-09 11:41 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c
8021788: JarInputStream doesn't provide certificates for some file under META-INF
Reviewed-by: chegar, sherman
! src/share/classes/java/util/jar/JarVerifier.java
+ test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java
From xuelei.fan at oracle.com Thu Aug 8 20:45:18 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 Aug 2013 11:45:18 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To:
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com>
Message-ID: <520465CE.5020000@oracle.com>
On 8/9/2013 11:24 AM, Matthew Hall wrote:
> But, DNS considers "." as the valid root zone...
>
Good! Looks like that IDN.toASCII(".") should returns ".", so that a
general domain name can always use IDN.toASCII() conversion instead of
throwing runtime exception.
Xuelei
From xuelei.fan at oracle.com Thu Aug 8 21:28:35 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 Aug 2013 12:28:35 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <520458DF.1030502@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com>
Message-ID: <52046FF3.1040903@oracle.com>
Thanks for your feedback and suggestions.
Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
"." is regarded as valid IDN in this update.
Thanks,
Xuelei
On 8/9/2013 10:50 AM, Xuelei Fan wrote:
> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>
>>
>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>
>>>> $ nslookup com..
>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>
>>>> but
>>>>
>>>> $ nslookup .
>>>> Server: 192.168.10.1
>>>> Address: 192.168.10.1#53
>>>>
>>>> Non-authoritative answer:
>>>> *** Can't find .: No answer
>>>>
>>> Thanks for the testing. The behaviors are the same as this fix now.
>>
>> No exactly. It seems nslookup still regards "." legal but just cannot
>> find an IP for it.
>>
> I'm not sure whether a root domain name can be stand alone. Root label
> is not considered as a label in IDN. I think it is safe to regard that
> "." is not a valid IDN as it contains no label. Anyway, it is a corner
> case.
>
> There are many online IDN conversion web services, some of them can
> convert ".", some of the cannot. In the present implementation, we
> cannot recognize ".", and IDN.toASCII(".") throws
> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
> a better exception for IDN.toASCII(".").
>
>>>
>>> Learn something new today to use nslookup.
>>>
>>>> Also, since this bug was originally about SNIHostName, do you need to
>>>> add some extra restriction there to reject "oracle.com." things?
>>>>
>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>> IDN. However, we may need to rethink about the comparing of two IDN, for
>>> example, "example.com." should equal to "example.com". I want to
>>> consider it in another bug.
>>
>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And
>> it's not one is another's subset?
>>
> Per TLS specification, host name in SNI is an IDN. The spec of
> SNIHostname says, "hostname is not a valid Internationalized Domain Name
> (IDN) compliant with the RFC 3490 specification". The spec in
> SNIHostName has the same means as IDN. I won't want to add additional
> restrict beyond the specification of an IDN.
>
> Xuelei
>
>>>
>>> Can I push the changeset?
>>
>> I think it's better to ask someone in the networking team to make the
>> suggestion. From what I read Michael in this thread, he does not seem
>> totally agreed with your code changes (at least not the 00 version).
>>
>> Thanks
>> Max
>>
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> Thanks
>>>> Max
>>>>
>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>> Ping.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>> Please review the new update:
>>>>>>
>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>
>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>
>
From david.holmes at oracle.com Thu Aug 8 22:21:42 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 09 Aug 2013 15:21:42 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52041988.80705@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com> <52041988.80705@oracle.com>
Message-ID: <52047C66.2080001@oracle.com>
Thumbs up!
Thanks,
David
On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
> Thanks David!
>
> On 09.08.2013 1:15, David Holmes wrote:
>> Main fix looks good to me.
>>
>> Regression test may need some tweaking eg I think othervm will be needed.
>>
> Yes, it's a good point.
> Since there may be a memory leak in the test, it'd better not interfere
> with other tests in jtreg.
>
>> Also this:
>>
>> System.out.println("WARNING: Cannot perform memory leak detection on
>> this OS");
>>
>> should probably just say something like "Test skipped on this OS" -
>> there are other tests that do this so just check if there is common
>> terminology. (In the future we may have keyword tags to flag this as
>> linux only etc.)
>>
> OK, I changed the phrase to "Test only runs on Linux".
>
> Updated webrev is here:
> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>
> Updated export is at the same place:
> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>
>
> Sincerely yours,
> Ivan
>
>
>> Thanks,
>> David
>>
>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>> Chris, if it's not too late, I'd like to include a regtest in the fix.
>>>
>>> Here's webrev that includes the test:
>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>
>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7
>>> as expected.
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>> Looks good to me. Thanks Ivan.
>>>>
>>>> -Chris.
>>>>
>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>> Hello Chris!
>>>>>
>>>>> Here's the update:
>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>
>>>>> Thanks for offering the sponsorship!
>>>>> Here's the hg-export
>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>> Thanks for taking this Ivan.
>>>>>>
>>>>>> Can you please make the changes suggested by both David and Alan (
>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars
>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for
>>>>>> you.
>>>>>>
>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>> Ivan,
>>>>>>>
>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>> David, Alan,
>>>>>>>>
>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>> necessary.
>>>>>>>
>>>>>>> You don't need to throw it yourself:
>>>>>>>
>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>
>>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>>> OOME
>>>>>>> should already be pending and will be thrown as soon as your native
>>>>>>> code
>>>>>>> returns to Java.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> I've also added some spaces along the code to improve indentation.
>>>>>>>>
>>>>>>>> Would you please review the updated webrev?
>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>> Thanks Alan!
>>>>>>>>>>
>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>>>>>> return
>>>>>>>>>> NULL.
>>>>>>>>>> For allocation of the result string it calls AllocateHeap() with
>>>>>>>>>> the
>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops
>>>>>>>>>> VM.
>>>>>>>>>
>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>> throw
>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>
>>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>
>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>> there) is
>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>> returns
>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>
>>>>>>>>>>> -Alan.
>>>>>>>>>>>
>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>
>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>>> memory.
>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>> available.)
>>>>>>>>>>>>
>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>
>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>
>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>> unnecessary
>>>>>>>>>>>> allocation?
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
From david.holmes at oracle.com Thu Aug 8 22:47:21 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 09 Aug 2013 15:47:21 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52047C66.2080001@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com> <52041988.80705@oracle.com>
<52047C66.2080001@oracle.com>
Message-ID: <52048269.7000501@oracle.com>
Sorry I messed this up. The JNI book says GetStringUTFChars will return
NULL and post OOME but the JNI spec (latest version 6.0) does not - it
only says it will return NULL on failure.
So your previous version was the more correct. Given we just failed to
allocate C-heap I think we are on thin ice anyway, but better to at
least attempt to do the right thing.
FYI I filed 8022683 to fix GetStringUTFChars.
David
-----
On 9/08/2013 3:21 PM, David Holmes wrote:
> Thumbs up!
>
> Thanks,
> David
>
> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>> Thanks David!
>>
>> On 09.08.2013 1:15, David Holmes wrote:
>>> Main fix looks good to me.
>>>
>>> Regression test may need some tweaking eg I think othervm will be
>>> needed.
>>>
>> Yes, it's a good point.
>> Since there may be a memory leak in the test, it'd better not interfere
>> with other tests in jtreg.
>>
>>> Also this:
>>>
>>> System.out.println("WARNING: Cannot perform memory leak detection on
>>> this OS");
>>>
>>> should probably just say something like "Test skipped on this OS" -
>>> there are other tests that do this so just check if there is common
>>> terminology. (In the future we may have keyword tags to flag this as
>>> linux only etc.)
>>>
>> OK, I changed the phrase to "Test only runs on Linux".
>>
>> Updated webrev is here:
>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>
>> Updated export is at the same place:
>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>
>>
>>
>> Sincerely yours,
>> Ivan
>>
>>
>>> Thanks,
>>> David
>>>
>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>> Chris, if it's not too late, I'd like to include a regtest in the fix.
>>>>
>>>> Here's webrev that includes the test:
>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>
>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and
>>>> jdk7
>>>> as expected.
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>> Looks good to me. Thanks Ivan.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>> Hello Chris!
>>>>>>
>>>>>> Here's the update:
>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>
>>>>>> Thanks for offering the sponsorship!
>>>>>> Here's the hg-export
>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>> Thanks for taking this Ivan.
>>>>>>>
>>>>>>> Can you please make the changes suggested by both David and Alan (
>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>> GetStringUTFChars
>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8
>>>>>>> for
>>>>>>> you.
>>>>>>>
>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>> Ivan,
>>>>>>>>
>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>> David, Alan,
>>>>>>>>>
>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>> necessary.
>>>>>>>>
>>>>>>>> You don't need to throw it yourself:
>>>>>>>>
>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>
>>>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>>>> OOME
>>>>>>>> should already be pending and will be thrown as soon as your native
>>>>>>>> code
>>>>>>>> returns to Java.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> I've also added some spaces along the code to improve indentation.
>>>>>>>>>
>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>
>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot
>>>>>>>>>>> return
>>>>>>>>>>> NULL.
>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() with
>>>>>>>>>>> the
>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops
>>>>>>>>>>> VM.
>>>>>>>>>>
>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>>> throw
>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>
>>>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>> Ivan
>>>>>>>>>>>
>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>
>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>> there) is
>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>> returns
>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>
>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>
>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>>>> memory.
>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>
>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
From dmitry.samersoff at oracle.com Thu Aug 8 23:08:19 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 09 Aug 2013 10:08:19 +0400
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52043AB3.6060704@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com>
Message-ID: <52048753.4040208@oracle.com>
Xuelei,
119 p = q + 1;
120 if (p < input.length() || q == (input.length() - 1)) {
Could be simplified to:
q <= input.length()-1
-Dmitry
On 2013-08-09 04:41, Xuelei Fan wrote:
> Ping.
>
> Thanks,
> Xuelei
>
> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>> Please review the new update:
>>
>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>
>> With this update, "com." is valid (return "com."); "." and
>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/7/2013 10:18 PM, Michael McMahon wrote:
>>> On 07/08/13 15:13, Xuelei Fan wrote:
>>>> On 8/7/2013 10:05 PM, Michael McMahon wrote:
>>>>> Resolvers seem to accept queries using trailing dots.
>>>>>
>>>>> eg nslookup www.oracle.com.
>>>>>
>>>>> or InetAddress.getByName("www.oracle.com.");
>>>>>
>>>>> The part of RFC3490 quoted below seems to me to be saying
>>>>> that the empty label implied by the trailing dot is not regarded
>>>>> as a label so that you don't end up calling toAscii() or toUnicode()
>>>>> with an empty string. I don't think it's saying the trailing dot can't
>>>>> be there.
>>>>>
>>>> It makes sense.
>>>>
>>>> What's your preference to return for IDN.toASCII("www.oracle.com."),
>>>> "www.oracle.com." or "www.oracle.com"? The current returned value is
>>>> "www.oracle.com". I would like to reserve the behavior in this update.
>>>
>>> My opinion is to keep it as at present ie. "www.oracle.com."
>>>
>>> Michael
>>>
>>>> I think we are on same page soon.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>> Michael
>>>>>
>>>>> On 07/08/13 13:44, Xuelei Fan wrote:
>>>>>> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>>>>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>>>>>>> and the single dot represents the root zone. So you have to be
>>>>>>> careful making this sort of change to check the DNS RFCs first.
>>>>>> That's the first question we need to answer, whether IDN allow tailling
>>>>>> dots ("com."), zero-length root label ("."), and zero-length label ("",
>>>>>> for example ""example..com")?
>>>>>>
>>>>>> Per the specification of IDN.toASCII():
>>>>>> =======================================
>>>>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
>>>>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In
>>>>>> this case, the input string should not be used in an internationalized
>>>>>> domain name.
>>>>>>
>>>>>> A label is an individual part of a domain name. The original ToASCII
>>>>>> operation, as defined in RFC 3490, only operates on a single label.
>>>>>> This
>>>>>> method can handle both label and entire domain name, by assuming that
>>>>>> labels in a domain name are always separated by dots. ...
>>>>>>
>>>>>> Throws IllegalArgumentException - if the input string doesn't
>>>>>> conform to
>>>>>> RFC 3490 specification"
>>>>>>
>>>>>> Per the specification of RFC 3490:
>>>>>> ==================================
>>>>>> [section 2]
>>>>>> "A label is an individual part of a domain name. Labels are usually
>>>>>> shown separated by dots; for example, the domain name
>>>>>> "www.example.com" is composed of three labels: "www", "example", and
>>>>>> "com". (The zero-length root label described in [STD13], which can
>>>>>> be explicit as in "www.example.com." or implicit as in
>>>>>> "www.example.com", is not considered a label in this
>>>>>> specification.)"
>>>>>>
>>>>>> "An "internationalized label" is a label to which the ToASCII
>>>>>> operation (see section 4) can be applied without failing (with the
>>>>>> UseSTD3ASCIIRules flag unset). ...
>>>>>> Although most Unicode characters can appear in
>>>>>> internationalized labels, ToASCII will fail for some input strings,
>>>>>> and such strings are not valid internationalized labels."
>>>>>>
>>>>>> "An "internationalized domain name" (IDN) is a domain name in which
>>>>>> every label is an internationalized label."
>>>>>>
>>>>>> [Section 4.1]
>>>>>> "ToASCII consists of the following steps:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> 8. Verify that the number of code points is in the range 1 to 63
>>>>>> inclusive."
>>>>>>
>>>>>>
>>>>>> Here are the questions:
>>>>>> 1. whether "example..com" is an valid IDN?
>>>>>> As dot is used as label separators, there are three labels,
>>>>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
>>>>>> "example..com" is not a valid IDN.
>>>>>>
>>>>>> We need to address the issue in IDN.
>>>>>>
>>>>>> 2. whether "xyz." is an valid IDN?
>>>>>> It's an gray area, I think. We can treat the trailing "." as root
>>>>>> label, or a label separator.
>>>>>> If the trailing "." is treated as label separator, "xyz." is
>>>>>> invalid
>>>>>> per RFC 3490.
>>>>>> if the trailing "." is treated as root label, what's the expected
>>>>>> return value of IDN.toASCII("xyz.")? I think the return value can be
>>>>>> either "xyz." or "xyz". The current implementation returns "xyz".
>>>>>>
>>>>>> We may need not to update the implementation if tailing "." is
>>>>>> treated as root label.
>>>>>>
>>>>>> 3. whether "." is an valid IDN?
>>>>>> It's an gray area again, I think.
>>>>>> As above, if the trailing "." is treated as root label, I think
>>>>>> the
>>>>>> return value can be either "." or "". The current implementation
>>>>>> throws
>>>>>> a StringIndexOutOfBoundsException.
>>>>>>
>>>>>> However, what empty domain name ("") really means? I would
>>>>>> prefer to
>>>>>> return "." for "." instead.
>>>>>>
>>>>>> We need to address the issue in IDN.
>>>>>>
>>>>>>
>>>>>> Here comes the solution, the IDN.toASCII() returns:
>>>>>> 1. "." for ".";
>>>>>> 2. "xyz" for "xyz.";
>>>>>> 3. IAE for "example..com".
>>>>>>
>>>>>> Does it make sense?
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>>
>>>>>> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>>>>>>> I don't really understand the reason for the restriction in
>>>>>>> SNIHostName
>>>>>>> But, I guess that is where it should be enforced if it is required.
>>>>>>>
>>>>>>> Michael.
>>>>>>>
>>>>>>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>>>>>>> Xuelei,
>>>>>>>>
>>>>>>>> . (dot) is perfectly valid domain name and it means root domain so
>>>>>>>> com.
>>>>>>>> is valid domain name as well.
>>>>>>>>
>>>>>>>> It thinks to me that in context of methods your change we should
>>>>>>>> ignore
>>>>>>>> trailing dots, rather than throw exception.
>>>>>>>>
>>>>>>>> -Dmitry
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review the bug fix to strict the illegal input checking in
>>>>>>>>> IDN.
>>>>>>>>>
>>>>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>>>>>>
>>>>>>>>> Here is two test cases, which are expected to get IAE.
>>>>>>>>>
>>>>>>>>> Case 1:
>>>>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>>>>>>> Exception in thread "main"
>>>>>>>>> java.lang.StringIndexOutOfBoundsException:
>>>>>>>>> String index out of range: 0
>>>>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>>>>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>>>>>>
>>>>>>>>> Case 2:
>>>>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Xuelei
>>>>>>>>>
>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
From Xuelei.Fan at Oracle.Com Fri Aug 9 00:09:33 2013
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Fri, 9 Aug 2013 15:09:33 +0800
Subject: Code review request,
8020842 IDN do not throw IAE when hostname ends with a trailing dot
In-Reply-To: <52048753.4040208@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <52048753.4040208@oracle.com>
Message-ID:
On Aug 9, 2013, at 14:08, Dmitry Samersoff wrote:
> Xuelei,
>
> 119 p = q + 1;
> 120 if (p < input.length() || q == (input.length() - 1)) {
>
> Could be simplified to:
>
> q <= input.length()-1
>
It's cool!
Xuelei
> -Dmitry
>
> On 2013-08-09 04:41, Xuelei Fan wrote:
>> Ping.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>> Please review the new update:
>>>
>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>
>>> With this update, "com." is valid (return "com."); "." and
>>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 8/7/2013 10:18 PM, Michael McMahon wrote:
>>>> On 07/08/13 15:13, Xuelei Fan wrote:
>>>>> On 8/7/2013 10:05 PM, Michael McMahon wrote:
>>>>>> Resolvers seem to accept queries using trailing dots.
>>>>>>
>>>>>> eg nslookup www.oracle.com.
>>>>>>
>>>>>> or InetAddress.getByName("www.oracle.com.");
>>>>>>
>>>>>> The part of RFC3490 quoted below seems to me to be saying
>>>>>> that the empty label implied by the trailing dot is not regarded
>>>>>> as a label so that you don't end up calling toAscii() or toUnicode()
>>>>>> with an empty string. I don't think it's saying the trailing dot can't
>>>>>> be there.
>>>>> It makes sense.
>>>>>
>>>>> What's your preference to return for IDN.toASCII("www.oracle.com."),
>>>>> "www.oracle.com." or "www.oracle.com"? The current returned value is
>>>>> "www.oracle.com". I would like to reserve the behavior in this update.
>>>>
>>>> My opinion is to keep it as at present ie. "www.oracle.com."
>>>>
>>>> Michael
>>>>
>>>>> I think we are on same page soon.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>>> Michael
>>>>>>
>>>>>> On 07/08/13 13:44, Xuelei Fan wrote:
>>>>>>> On 8/7/2013 12:06 AM, Matthew Hall wrote:
>>>>>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN),
>>>>>>>> and the single dot represents the root zone. So you have to be
>>>>>>>> careful making this sort of change to check the DNS RFCs first.
>>>>>>> That's the first question we need to answer, whether IDN allow tailling
>>>>>>> dots ("com."), zero-length root label ("."), and zero-length label ("",
>>>>>>> for example ""example..com")?
>>>>>>>
>>>>>>> Per the specification of IDN.toASCII():
>>>>>>> =======================================
>>>>>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If
>>>>>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In
>>>>>>> this case, the input string should not be used in an internationalized
>>>>>>> domain name.
>>>>>>>
>>>>>>> A label is an individual part of a domain name. The original ToASCII
>>>>>>> operation, as defined in RFC 3490, only operates on a single label.
>>>>>>> This
>>>>>>> method can handle both label and entire domain name, by assuming that
>>>>>>> labels in a domain name are always separated by dots. ...
>>>>>>>
>>>>>>> Throws IllegalArgumentException - if the input string doesn't
>>>>>>> conform to
>>>>>>> RFC 3490 specification"
>>>>>>>
>>>>>>> Per the specification of RFC 3490:
>>>>>>> ==================================
>>>>>>> [section 2]
>>>>>>> "A label is an individual part of a domain name. Labels are usually
>>>>>>> shown separated by dots; for example, the domain name
>>>>>>> "www.example.com" is composed of three labels: "www", "example", and
>>>>>>> "com". (The zero-length root label described in [STD13], which can
>>>>>>> be explicit as in "www.example.com." or implicit as in
>>>>>>> "www.example.com", is not considered a label in this
>>>>>>> specification.)"
>>>>>>>
>>>>>>> "An "internationalized label" is a label to which the ToASCII
>>>>>>> operation (see section 4) can be applied without failing (with the
>>>>>>> UseSTD3ASCIIRules flag unset). ...
>>>>>>> Although most Unicode characters can appear in
>>>>>>> internationalized labels, ToASCII will fail for some input strings,
>>>>>>> and such strings are not valid internationalized labels."
>>>>>>>
>>>>>>> "An "internationalized domain name" (IDN) is a domain name in which
>>>>>>> every label is an internationalized label."
>>>>>>>
>>>>>>> [Section 4.1]
>>>>>>> "ToASCII consists of the following steps:
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> 8. Verify that the number of code points is in the range 1 to 63
>>>>>>> inclusive."
>>>>>>>
>>>>>>>
>>>>>>> Here are the questions:
>>>>>>> 1. whether "example..com" is an valid IDN?
>>>>>>> As dot is used as label separators, there are three labels,
>>>>>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence,
>>>>>>> "example..com" is not a valid IDN.
>>>>>>>
>>>>>>> We need to address the issue in IDN.
>>>>>>>
>>>>>>> 2. whether "xyz." is an valid IDN?
>>>>>>> It's an gray area, I think. We can treat the trailing "." as root
>>>>>>> label, or a label separator.
>>>>>>> If the trailing "." is treated as label separator, "xyz." is
>>>>>>> invalid
>>>>>>> per RFC 3490.
>>>>>>> if the trailing "." is treated as root label, what's the expected
>>>>>>> return value of IDN.toASCII("xyz.")? I think the return value can be
>>>>>>> either "xyz." or "xyz". The current implementation returns "xyz".
>>>>>>>
>>>>>>> We may need not to update the implementation if tailing "." is
>>>>>>> treated as root label.
>>>>>>>
>>>>>>> 3. whether "." is an valid IDN?
>>>>>>> It's an gray area again, I think.
>>>>>>> As above, if the trailing "." is treated as root label, I think
>>>>>>> the
>>>>>>> return value can be either "." or "". The current implementation
>>>>>>> throws
>>>>>>> a StringIndexOutOfBoundsException.
>>>>>>>
>>>>>>> However, what empty domain name ("") really means? I would
>>>>>>> prefer to
>>>>>>> return "." for "." instead.
>>>>>>>
>>>>>>> We need to address the issue in IDN.
>>>>>>>
>>>>>>>
>>>>>>> Here comes the solution, the IDN.toASCII() returns:
>>>>>>> 1. "." for ".";
>>>>>>> 2. "xyz" for "xyz.";
>>>>>>> 3. IAE for "example..com".
>>>>>>>
>>>>>>> Does it make sense?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>>>>>>>
>>>>>>> On 8/7/2013 1:35 AM, Michael McMahon wrote:
>>>>>>>> I don't really understand the reason for the restriction in
>>>>>>>> SNIHostName
>>>>>>>> But, I guess that is where it should be enforced if it is required.
>>>>>>>>
>>>>>>>> Michael.
>>>>>>>>
>>>>>>>> On 06/08/13 17:43, Dmitry Samersoff wrote:
>>>>>>>>> Xuelei,
>>>>>>>>>
>>>>>>>>> . (dot) is perfectly valid domain name and it means root domain so
>>>>>>>>> com.
>>>>>>>>> is valid domain name as well.
>>>>>>>>>
>>>>>>>>> It thinks to me that in context of methods your change we should
>>>>>>>>> ignore
>>>>>>>>> trailing dots, rather than throw exception.
>>>>>>>>>
>>>>>>>>> -Dmitry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2013-08-06 15:44, Xuelei Fan wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review the bug fix to strict the illegal input checking in
>>>>>>>>>> IDN.
>>>>>>>>>>
>>>>>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Here is two test cases, which are expected to get IAE.
>>>>>>>>>>
>>>>>>>>>> Case 1:
>>>>>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES);
>>>>>>>>>> Exception in thread "main"
>>>>>>>>>> java.lang.StringIndexOutOfBoundsException:
>>>>>>>>>> String index out of range: 0
>>>>>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204)
>>>>>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279)
>>>>>>>>>> at java.net.IDN.toASCII(IDN.java:118)
>>>>>>>>>>
>>>>>>>>>> Case 2:
>>>>>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES);
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Xuelei
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the source code.
From xueming.shen at oracle.com Thu Aug 8 23:39:17 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Fri, 09 Aug 2013 06:39:17 +0000
Subject: hg: jdk8/tl/jdk: 6614237: missing codepage Cp290 at java runtime
Message-ID: <20130809063942.0D9734873B@hg.openjdk.java.net>
Changeset: 54f0ccdd9ad7
Author: sherman
Date: 2013-08-08 23:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54f0ccdd9ad7
6614237: missing codepage Cp290 at java runtime
Summary: to add charset Cp290 and Cp300
Reviewed-by: okutsu
+ make/tools/CharsetMapping/IBM290.c2b
+ make/tools/CharsetMapping/IBM290.map
+ make/tools/CharsetMapping/IBM300.c2b
+ make/tools/CharsetMapping/IBM300.map
! make/tools/CharsetMapping/dbcs
! make/tools/CharsetMapping/extsbcs
! make/tools/src/build/tools/charsetmapping/DBCS.java
! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java
From chris.hegarty at oracle.com Fri Aug 9 00:25:47 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 09 Aug 2013 08:25:47 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52048269.7000501@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com>
Message-ID: <5204997B.3090601@oracle.com>
On 09/08/2013 06:47, David Holmes wrote:
> Sorry I messed this up. The JNI book says GetStringUTFChars will return
> NULL and post OOME but the JNI spec (latest version 6.0) does not - it
> only says it will return NULL on failure.
This is indeed strange. Most usages of this function in the jdk expect
the former. If this is not the case, then we may need to do an audit of
all usages.
> So your previous version was the more correct. Given we just failed to
> allocate C-heap I think we are on thin ice anyway, but better to at
> least attempt to do the right thing.
I'm not sure what the right thing to do here is? It seems a little unwieldy!
if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) {
if ((*env)->ExceptionOccurred(env)) {
return NULL/JNI_False/-1;
} else {
throwException(env, "java/lang/InternalError", "GetStringUTFChars
failed");
return NULL/JNI_False/-1;
}
Given we have no idea why GetStringUTFChars may have failed, what
exception do we throw?
Also worth noting is that this bug fix has moved away from the original
problem (memory leak), and is now focused on code cleanup.
If we cannot get agreement on the cleanup, or it looks like more
clarification is needed around the cleanup effort, then I would like to
suggest that we proceed with the original fix for the memory leak and
separate out the cleanup effort.
-Chris.
> FYI I filed 8022683 to fix GetStringUTFChars.
>
> David
> -----
>
> On 9/08/2013 3:21 PM, David Holmes wrote:
>> Thumbs up!
>>
>> Thanks,
>> David
>>
>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>> Thanks David!
>>>
>>> On 09.08.2013 1:15, David Holmes wrote:
>>>> Main fix looks good to me.
>>>>
>>>> Regression test may need some tweaking eg I think othervm will be
>>>> needed.
>>>>
>>> Yes, it's a good point.
>>> Since there may be a memory leak in the test, it'd better not interfere
>>> with other tests in jtreg.
>>>
>>>> Also this:
>>>>
>>>> System.out.println("WARNING: Cannot perform memory leak detection on
>>>> this OS");
>>>>
>>>> should probably just say something like "Test skipped on this OS" -
>>>> there are other tests that do this so just check if there is common
>>>> terminology. (In the future we may have keyword tags to flag this as
>>>> linux only etc.)
>>>>
>>> OK, I changed the phrase to "Test only runs on Linux".
>>>
>>> Updated webrev is here:
>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>
>>> Updated export is at the same place:
>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>
>>>
>>>
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>> Chris, if it's not too late, I'd like to include a regtest in the fix.
>>>>>
>>>>> Here's webrev that includes the test:
>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>
>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and
>>>>> jdk7
>>>>> as expected.
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>> Looks good to me. Thanks Ivan.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>> Hello Chris!
>>>>>>>
>>>>>>> Here's the update:
>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>
>>>>>>> Thanks for offering the sponsorship!
>>>>>>> Here's the hg-export
>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>
>>>>>>>> Can you please make the changes suggested by both David and Alan (
>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>> GetStringUTFChars
>>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8
>>>>>>>> for
>>>>>>>> you.
>>>>>>>>
>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>> Ivan,
>>>>>>>>>
>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>> David, Alan,
>>>>>>>>>>
>>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>>> necessary.
>>>>>>>>>
>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>
>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>
>>>>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>>>>> OOME
>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>> native
>>>>>>>>> code
>>>>>>>>> returns to Java.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>> indentation.
>>>>>>>>>>
>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>
>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>> cannot
>>>>>>>>>>>> return
>>>>>>>>>>>> NULL.
>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap()
>>>>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>> stops
>>>>>>>>>>>> VM.
>>>>>>>>>>>
>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>>>> throw
>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>
>>>>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>>> there) is
>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>>> returns
>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
From chris.hegarty at oracle.com Fri Aug 9 02:23:02 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 09 Aug 2013 10:23:02 +0100
Subject: RFR 8022661: InetAddress.writeObject() performs flush() on object
output stream
Message-ID: <5204B4F6.9090102@oracle.com>
This is a trivial change to remove the unnecessary flush from
InetAddress.writeObject(). The flush can have a negative affect if the
ObjectOutputStream is wrapping an underlying Socket stream.
diff -r 662115496d6b src/share/classes/java/net/InetAddress.java
--- a/src/share/classes/java/net/InetAddress.java Thu Aug 08
17:28:00 2013 +0400
+++ b/src/share/classes/java/net/InetAddress.java Fri Aug 09
10:17:11 2013 +0100
@@ -1601,7 +1601,6 @@ class InetAddress implements java.io.Ser
pf.put("address", holder().getAddress());
pf.put("family", holder().getFamily());
s.writeFields();
- s.flush();
}
}
-Chris.
From ivan.gerasimov at oracle.com Fri Aug 9 02:27:15 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 09 Aug 2013 13:27:15 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5204997B.3090601@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
Message-ID: <5204B5F3.6000506@oracle.com>
Chris,
I would use this
if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) {
JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
return NULL/JNI_False/-1;
}
If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
exception only if it hasn't been already thrown.
Sincerely yours,
Ivan
On 09.08.2013 11:25, Chris Hegarty wrote:
> On 09/08/2013 06:47, David Holmes wrote:
>> Sorry I messed this up. The JNI book says GetStringUTFChars will return
>> NULL and post OOME but the JNI spec (latest version 6.0) does not - it
>> only says it will return NULL on failure.
>
> This is indeed strange. Most usages of this function in the jdk expect
> the former. If this is not the case, then we may need to do an audit
> of all usages.
>
>> So your previous version was the more correct. Given we just failed to
>> allocate C-heap I think we are on thin ice anyway, but better to at
>> least attempt to do the right thing.
>
> I'm not sure what the right thing to do here is? It seems a little
> unwieldy!
>
> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
> NULL) {
> if ((*env)->ExceptionOccurred(env)) {
> return NULL/JNI_False/-1;
> } else {
> throwException(env, "java/lang/InternalError",
> "GetStringUTFChars failed");
> return NULL/JNI_False/-1;
> }
>
> Given we have no idea why GetStringUTFChars may have failed, what
> exception do we throw?
>
> Also worth noting is that this bug fix has moved away from the
> original problem (memory leak), and is now focused on code cleanup.
>
> If we cannot get agreement on the cleanup, or it looks like more
> clarification is needed around the cleanup effort, then I would like
> to suggest that we proceed with the original fix for the memory leak
> and separate out the cleanup effort.
>
> -Chris.
>
>> FYI I filed 8022683 to fix GetStringUTFChars.
>>
>> David
>> -----
>>
>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>> Thumbs up!
>>>
>>> Thanks,
>>> David
>>>
>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>> Thanks David!
>>>>
>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>> Main fix looks good to me.
>>>>>
>>>>> Regression test may need some tweaking eg I think othervm will be
>>>>> needed.
>>>>>
>>>> Yes, it's a good point.
>>>> Since there may be a memory leak in the test, it'd better not
>>>> interfere
>>>> with other tests in jtreg.
>>>>
>>>>> Also this:
>>>>>
>>>>> System.out.println("WARNING: Cannot perform memory leak detection on
>>>>> this OS");
>>>>>
>>>>> should probably just say something like "Test skipped on this OS" -
>>>>> there are other tests that do this so just check if there is common
>>>>> terminology. (In the future we may have keyword tags to flag this as
>>>>> linux only etc.)
>>>>>
>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>
>>>> Updated webrev is here:
>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>
>>>> Updated export is at the same place:
>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>>> fix.
>>>>>>
>>>>>> Here's webrev that includes the test:
>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>
>>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and
>>>>>> jdk7
>>>>>> as expected.
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>> Hello Chris!
>>>>>>>>
>>>>>>>> Here's the update:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>
>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>> Here's the hg-export
>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>
>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>> Alan (
>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>> GetStringUTFChars
>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8
>>>>>>>>> for
>>>>>>>>> you.
>>>>>>>>>
>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>
>>>>>>>>> -Chris.
>>>>>>>>>
>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>> Ivan,
>>>>>>>>>>
>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>> David, Alan,
>>>>>>>>>>>
>>>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>>>> necessary.
>>>>>>>>>>
>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>
>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>
>>>>>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>>>>>> OOME
>>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>>> native
>>>>>>>>>> code
>>>>>>>>>> returns to Java.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>> indentation.
>>>>>>>>>>>
>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>
>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>> Ivan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>>> cannot
>>>>>>>>>>>>> return
>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap()
>>>>>>>>>>>>> with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>>> stops
>>>>>>>>>>>>> VM.
>>>>>>>>>>>>
>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>>>>> throw
>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>>
>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>> exception.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to
>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>
>
From michael.x.mcmahon at oracle.com Fri Aug 9 02:56:29 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 09 Aug 2013 10:56:29 +0100
Subject: RFR 8022661: InetAddress.writeObject() performs flush() on object
output stream
In-Reply-To: <5204B4F6.9090102@oracle.com>
References: <5204B4F6.9090102@oracle.com>
Message-ID: <5204BCCD.7060105@oracle.com>
Looks fine to me.
- Michael.
On 09/08/13 10:23, Chris Hegarty wrote:
> This is a trivial change to remove the unnecessary flush from
> InetAddress.writeObject(). The flush can have a negative affect if the
> ObjectOutputStream is wrapping an underlying Socket stream.
>
> diff -r 662115496d6b src/share/classes/java/net/InetAddress.java
> --- a/src/share/classes/java/net/InetAddress.java Thu Aug 08
> 17:28:00 2013 +0400
> +++ b/src/share/classes/java/net/InetAddress.java Fri Aug 09
> 10:17:11 2013 +0100
> @@ -1601,7 +1601,6 @@ class InetAddress implements java.io.Ser
> pf.put("address", holder().getAddress());
> pf.put("family", holder().getFamily());
> s.writeFields();
> - s.flush();
> }
> }
>
>
> -Chris.
From paul.sandoz at oracle.com Fri Aug 9 02:55:25 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 09 Aug 2013 09:55:25 +0000
Subject: hg: jdk8/tl/jdk: 8022326: Spliterator for values of
j.u.c.ConcurrentSkipListMap does not report ORDERED
Message-ID: <20130809095620.E542848740@hg.openjdk.java.net>
Changeset: c29ca19cb816
Author: psandoz
Date: 2013-08-09 11:44 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c29ca19cb816
8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED
Reviewed-by: martin, chegar
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
From chris.hegarty at oracle.com Fri Aug 9 03:36:22 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 09 Aug 2013 11:36:22 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5204B5F3.6000506@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
<5204B5F3.6000506@oracle.com>
Message-ID: <5204C626.3000102@oracle.com>
Firstly, I think the memory leak issue should be moved forward
separately to this cleanup effort. They are unrelated, and I'm starting
to get the feeling that this could take some time to reach conclusion.
It seems reasonable to separate the issues.
On 09/08/2013 10:27, Ivan Gerasimov wrote:
> Chris,
>
> I would use this
>
> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) {
> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
> return NULL/JNI_False/-1;
> }
>
> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
> exception only if it hasn't been already thrown.
JNU_ThrowOutOfMemoryError is simply a convenience wrapper for
JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg);
...and JNU_ThrowByName [1] is defined as...
JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) {
class cls = (*env)->FindClass(env, name);
if (cls != 0) /* Otherwise an exception has already been thrown */
(*env)->ThrowNew(env, cls, msg);
}
}
Neither FindClass or ThrowNew is safe to call if there is a pending
exception [1].
Now the issue comes down to; could there ever be a pending exception if
GetStringUTFChars returns NULL? The latest specs doesn't indicate that
there could be, but every copy of "The Java Native Interface
Programmer's Guide and Specification" I can find does. There also
appears to be an assumption of this if you look at the usages in the JDK.
I would really like to get a definitive answer on the JNI specification
for GetStringUTFChars before making any changes here.
-Chris.
[1]
http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c
[2]
http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626
>
> Sincerely yours,
> Ivan
>
>
> On 09.08.2013 11:25, Chris Hegarty wrote:
>> On 09/08/2013 06:47, David Holmes wrote:
>>> Sorry I messed this up. The JNI book says GetStringUTFChars will return
>>> NULL and post OOME but the JNI spec (latest version 6.0) does not - it
>>> only says it will return NULL on failure.
>>
>> This is indeed strange. Most usages of this function in the jdk expect
>> the former. If this is not the case, then we may need to do an audit
>> of all usages.
>>
>>> So your previous version was the more correct. Given we just failed to
>>> allocate C-heap I think we are on thin ice anyway, but better to at
>>> least attempt to do the right thing.
>>
>> I'm not sure what the right thing to do here is? It seems a little
>> unwieldy!
>>
>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) {
>> if ((*env)->ExceptionOccurred(env)) {
>> return NULL/JNI_False/-1;
>> } else {
>> throwException(env, "java/lang/InternalError", "GetStringUTFChars
>> failed");
>> return NULL/JNI_False/-1;
>> }
>>
>> Given we have no idea why GetStringUTFChars may have failed, what
>> exception do we throw?
>>
>> Also worth noting is that this bug fix has moved away from the
>> original problem (memory leak), and is now focused on code cleanup.
>>
>> If we cannot get agreement on the cleanup, or it looks like more
>> clarification is needed around the cleanup effort, then I would like
>> to suggest that we proceed with the original fix for the memory leak
>> and separate out the cleanup effort.
>>
>> -Chris.
>>
>>> FYI I filed 8022683 to fix GetStringUTFChars.
>>>
>>> David
>>> -----
>>>
>>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>>> Thumbs up!
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>>> Thanks David!
>>>>>
>>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>>> Main fix looks good to me.
>>>>>>
>>>>>> Regression test may need some tweaking eg I think othervm will be
>>>>>> needed.
>>>>>>
>>>>> Yes, it's a good point.
>>>>> Since there may be a memory leak in the test, it'd better not
>>>>> interfere
>>>>> with other tests in jtreg.
>>>>>
>>>>>> Also this:
>>>>>>
>>>>>> System.out.println("WARNING: Cannot perform memory leak detection on
>>>>>> this OS");
>>>>>>
>>>>>> should probably just say something like "Test skipped on this OS" -
>>>>>> there are other tests that do this so just check if there is common
>>>>>> terminology. (In the future we may have keyword tags to flag this as
>>>>>> linux only etc.)
>>>>>>
>>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>>
>>>>> Updated webrev is here:
>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>>
>>>>> Updated export is at the same place:
>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>>>> fix.
>>>>>>>
>>>>>>> Here's webrev that includes the test:
>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>>
>>>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and
>>>>>>> jdk7
>>>>>>> as expected.
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>>> Hello Chris!
>>>>>>>>>
>>>>>>>>> Here's the update:
>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>>
>>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>>> Here's the hg-export
>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>>
>>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>>> Alan (
>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>>> GetStringUTFChars
>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8
>>>>>>>>>> for
>>>>>>>>>> you.
>>>>>>>>>>
>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>>
>>>>>>>>>> -Chris.
>>>>>>>>>>
>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>>> Ivan,
>>>>>>>>>>>
>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>> David, Alan,
>>>>>>>>>>>>
>>>>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>>>>> necessary.
>>>>>>>>>>>
>>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>>
>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>>
>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned then an
>>>>>>>>>>> OOME
>>>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>>>> native
>>>>>>>>>>> code
>>>>>>>>>>> returns to Java.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>>> indentation.
>>>>>>>>>>>>
>>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>> return
>>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap()
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>>>> stops
>>>>>>>>>>>>>> VM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>>>>>> throw
>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to
>>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>
From Alan.Bateman at oracle.com Fri Aug 9 03:59:34 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 09 Aug 2013 03:59:34 -0700
Subject: RFR 8022661: InetAddress.writeObject() performs flush() on object
output stream
In-Reply-To: <5204B4F6.9090102@oracle.com>
References: <5204B4F6.9090102@oracle.com>
Message-ID: <5204CB96.5050300@oracle.com>
On 09/08/2013 02:23, Chris Hegarty wrote:
> This is a trivial change to remove the unnecessary flush from
> InetAddress.writeObject(). The flush can have a negative affect if the
> ObjectOutputStream is wrapping an underlying Socket stream.
>
> diff -r 662115496d6b src/share/classes/java/net/InetAddress.java
> --- a/src/share/classes/java/net/InetAddress.java Thu Aug 08
> 17:28:00 2013 +0400
> +++ b/src/share/classes/java/net/InetAddress.java Fri Aug 09
> 10:17:11 2013 +0100
> @@ -1601,7 +1601,6 @@ class InetAddress implements java.io.Ser
> pf.put("address", holder().getAddress());
> pf.put("family", holder().getFamily());
> s.writeFields();
> - s.flush();
> }
> }
This looks okay to me, looks like the flush is completely unnecessary.
-Alan
From michael.x.mcmahon at oracle.com Fri Aug 9 04:31:30 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 09 Aug 2013 12:31:30 +0100
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52046FF3.1040903@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
Message-ID: <5204D312.4030209@oracle.com>
I don't see how this fixes the original problem as the SNIHostName spec
still doesn't like hostnames with a trailing '.'
I'd prefer to check first where that requirement is coming from, if it is
actually necessary, and if not consider removing it from SNIHostName.
If it is necessary, then the check should be implemented in SNIHostName.
Michael
On 09/08/13 05:28, Xuelei Fan wrote:
> Thanks for your feedback and suggestions.
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>
> "." is regarded as valid IDN in this update.
>
> Thanks,
> Xuelei
>
> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>
>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>
>>>>> $ nslookup com..
>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>
>>>>> but
>>>>>
>>>>> $ nslookup .
>>>>> Server: 192.168.10.1
>>>>> Address: 192.168.10.1#53
>>>>>
>>>>> Non-authoritative answer:
>>>>> *** Can't find .: No answer
>>>>>
>>>> Thanks for the testing. The behaviors are the same as this fix now.
>>> No exactly. It seems nslookup still regards "." legal but just cannot
>>> find an IP for it.
>>>
>> I'm not sure whether a root domain name can be stand alone. Root label
>> is not considered as a label in IDN. I think it is safe to regard that
>> "." is not a valid IDN as it contains no label. Anyway, it is a corner
>> case.
>>
>> There are many online IDN conversion web services, some of them can
>> convert ".", some of the cannot. In the present implementation, we
>> cannot recognize ".", and IDN.toASCII(".") throws
>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
>> a better exception for IDN.toASCII(".").
>>
>>>> Learn something new today to use nslookup.
>>>>
>>>>> Also, since this bug was originally about SNIHostName, do you need to
>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>
>>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>>> IDN. However, we may need to rethink about the comparing of two IDN, for
>>>> example, "example.com." should equal to "example.com". I want to
>>>> consider it in another bug.
>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And
>>> it's not one is another's subset?
>>>
>> Per TLS specification, host name in SNI is an IDN. The spec of
>> SNIHostname says, "hostname is not a valid Internationalized Domain Name
>> (IDN) compliant with the RFC 3490 specification". The spec in
>> SNIHostName has the same means as IDN. I won't want to add additional
>> restrict beyond the specification of an IDN.
>>
>> Xuelei
>>
>>>> Can I push the changeset?
>>> I think it's better to ask someone in the networking team to make the
>>> suggestion. From what I read Michael in this thread, he does not seem
>>> totally agreed with your code changes (at least not the 00 version).
>>>
>>> Thanks
>>> Max
>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>> Ping.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>> Please review the new update:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>
>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid IDN.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
From david.holmes at oracle.com Fri Aug 9 05:18:48 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 09 Aug 2013 22:18:48 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5204C626.3000102@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
<5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com>
Message-ID: <5204DE28.5090805@oracle.com>
Hi Chris,
On 9/08/2013 8:36 PM, Chris Hegarty wrote:
> Firstly, I think the memory leak issue should be moved forward
> separately to this cleanup effort. They are unrelated, and I'm starting
> to get the feeling that this could take some time to reach conclusion.
> It seems reasonable to separate the issues.
I agree. I'm sure when Alan suggested to check the return he didn't
expect it to unravel like this :) As we know hotspot will never actually
return NULL there is no urgency to add this in.
> On 09/08/2013 10:27, Ivan Gerasimov wrote:
>> Chris,
>>
>> I would use this
>>
>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) {
>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
>> return NULL/JNI_False/-1;
>> }
>>
>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
>> exception only if it hasn't been already thrown.
>
> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for
> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg);
>
> ...and JNU_ThrowByName [1] is defined as...
>
> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) {
> class cls = (*env)->FindClass(env, name);
> if (cls != 0) /* Otherwise an exception has already been thrown */
> (*env)->ThrowNew(env, cls, msg);
> }
> }
>
> Neither FindClass or ThrowNew is safe to call if there is a pending
> exception [1].
Right - we have to check for a pending exception before trying to throw one.
> Now the issue comes down to; could there ever be a pending exception if
> GetStringUTFChars returns NULL? The latest specs doesn't indicate that
> there could be, but every copy of "The Java Native Interface
> Programmer's Guide and Specification" I can find does. There also
> appears to be an assumption of this if you look at the usages in the JDK.
AFAIK there is only one version of the JNI spec book and it never got
updated. The official spec says no throw, but when people have the book
on their bookshelf that is what they tend to rely on. I looked at some
of the usages and they seem exception agnostic - many of them don't even
check for NULL :(
The implementation as it stands will not throw and will not return NULL.
> I would really like to get a definitive answer on the JNI specification
> for GetStringUTFChars before making any changes here.
The JNI spec (as opposed to the book) is definitive. If we don't like
what is there then it requires a spec change.
I can't find any reference to this particular issue being raised before.
Cheers,
David
> -Chris.
>
> [1]
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c
>
> [2]
> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626
>
>
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 09.08.2013 11:25, Chris Hegarty wrote:
>>> On 09/08/2013 06:47, David Holmes wrote:
>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will return
>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not - it
>>>> only says it will return NULL on failure.
>>>
>>> This is indeed strange. Most usages of this function in the jdk expect
>>> the former. If this is not the case, then we may need to do an audit
>>> of all usages.
>>>
>>>> So your previous version was the more correct. Given we just failed to
>>>> allocate C-heap I think we are on thin ice anyway, but better to at
>>>> least attempt to do the right thing.
>>>
>>> I'm not sure what the right thing to do here is? It seems a little
>>> unwieldy!
>>>
>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>> NULL) {
>>> if ((*env)->ExceptionOccurred(env)) {
>>> return NULL/JNI_False/-1;
>>> } else {
>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars
>>> failed");
>>> return NULL/JNI_False/-1;
>>> }
>>>
>>> Given we have no idea why GetStringUTFChars may have failed, what
>>> exception do we throw?
>>>
>>> Also worth noting is that this bug fix has moved away from the
>>> original problem (memory leak), and is now focused on code cleanup.
>>>
>>> If we cannot get agreement on the cleanup, or it looks like more
>>> clarification is needed around the cleanup effort, then I would like
>>> to suggest that we proceed with the original fix for the memory leak
>>> and separate out the cleanup effort.
>>>
>>> -Chris.
>>>
>>>> FYI I filed 8022683 to fix GetStringUTFChars.
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>>>> Thumbs up!
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>>>> Thanks David!
>>>>>>
>>>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>>>> Main fix looks good to me.
>>>>>>>
>>>>>>> Regression test may need some tweaking eg I think othervm will be
>>>>>>> needed.
>>>>>>>
>>>>>> Yes, it's a good point.
>>>>>> Since there may be a memory leak in the test, it'd better not
>>>>>> interfere
>>>>>> with other tests in jtreg.
>>>>>>
>>>>>>> Also this:
>>>>>>>
>>>>>>> System.out.println("WARNING: Cannot perform memory leak detection on
>>>>>>> this OS");
>>>>>>>
>>>>>>> should probably just say something like "Test skipped on this OS" -
>>>>>>> there are other tests that do this so just check if there is common
>>>>>>> terminology. (In the future we may have keyword tags to flag this as
>>>>>>> linux only etc.)
>>>>>>>
>>>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>>>
>>>>>> Updated webrev is here:
>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>>>
>>>>>> Updated export is at the same place:
>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>>>>> fix.
>>>>>>>>
>>>>>>>> Here's webrev that includes the test:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>>>
>>>>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and
>>>>>>>> jdk7
>>>>>>>> as expected.
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>>>
>>>>>>>>> -Chris.
>>>>>>>>>
>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>>>> Hello Chris!
>>>>>>>>>>
>>>>>>>>>> Here's the update:
>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>>>
>>>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>>>> Here's the hg-export
>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>>>
>>>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>>>> Alan (
>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>>>> GetStringUTFChars
>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>>>>> jdk8
>>>>>>>>>>> for
>>>>>>>>>>> you.
>>>>>>>>>>>
>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>>>
>>>>>>>>>>> -Chris.
>>>>>>>>>>>
>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>>> David, Alan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>
>>>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>>>
>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>>>
>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned
>>>>>>>>>>>> then an
>>>>>>>>>>>> OOME
>>>>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>>>>> native
>>>>>>>>>>>> code
>>>>>>>>>>>> returns to Java.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>>>> indentation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap()
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>>>>> stops
>>>>>>>>>>>>>>> VM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to
>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to
>>>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not
>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>
From chris.hegarty at oracle.com Fri Aug 9 05:50:52 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 09 Aug 2013 12:50:52 +0000
Subject: hg: jdk8/tl/jdk: 8022661: InetAddress.writeObject() performs flush()
on object output stream
Message-ID: <20130809125140.B289D48748@hg.openjdk.java.net>
Changeset: 84004d0e3fdd
Author: chegar
Date: 2013-08-09 13:50 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84004d0e3fdd
8022661: InetAddress.writeObject() performs flush() on object output stream
Reviewed-by: michaelm, alanb
! src/share/classes/java/net/InetAddress.java
From xuelei.fan at oracle.com Fri Aug 9 08:25:53 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 09 Aug 2013 23:25:53 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5204D312.4030209@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com>
Message-ID: <52050A01.3030503@oracle.com>
On 8/9/2013 7:31 PM, Michael McMahon wrote:
> I don't see how this fixes the original problem as the SNIHostName spec
> still doesn't like hostnames with a trailing '.'
>
The bug description did not reflect the IDN specification correctly. If
"com." is a valid IDN, SNIHostName should accept it an an valid
hostname. The host name in SNIHostName is nothing more or less than an
standard IDN.
I added a comment in the bug: "com." and "." are valid IDN according the
IDN and domain name specifications. I will contact the bug reporter
about this point.
Xuelei
> I'd prefer to check first where that requirement is coming from, if it is
> actually necessary, and if not consider removing it from SNIHostName.
> If it is necessary, then the check should be implemented in SNIHostName.
>
> Michael
>
> On 09/08/13 05:28, Xuelei Fan wrote:
>> Thanks for your feedback and suggestions.
>>
>> Here is the new webrev:
>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>
>> "." is regarded as valid IDN in this update.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>>
>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>>
>>>>>> $ nslookup com..
>>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>>
>>>>>> but
>>>>>>
>>>>>> $ nslookup .
>>>>>> Server: 192.168.10.1
>>>>>> Address: 192.168.10.1#53
>>>>>>
>>>>>> Non-authoritative answer:
>>>>>> *** Can't find .: No answer
>>>>>>
>>>>> Thanks for the testing. The behaviors are the same as this fix now.
>>>> No exactly. It seems nslookup still regards "." legal but just cannot
>>>> find an IP for it.
>>>>
>>> I'm not sure whether a root domain name can be stand alone. Root label
>>> is not considered as a label in IDN. I think it is safe to regard that
>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner
>>> case.
>>>
>>> There are many online IDN conversion web services, some of them can
>>> convert ".", some of the cannot. In the present implementation, we
>>> cannot recognize ".", and IDN.toASCII(".") throws
>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
>>> a better exception for IDN.toASCII(".").
>>>
>>>>> Learn something new today to use nslookup.
>>>>>
>>>>>> Also, since this bug was originally about SNIHostName, do you need to
>>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>>
>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>>>> IDN. However, we may need to rethink about the comparing of two
>>>>> IDN, for
>>>>> example, "example.com." should equal to "example.com". I want to
>>>>> consider it in another bug.
>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets?
>>>> And
>>>> it's not one is another's subset?
>>>>
>>> Per TLS specification, host name in SNI is an IDN. The spec of
>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name
>>> (IDN) compliant with the RFC 3490 specification". The spec in
>>> SNIHostName has the same means as IDN. I won't want to add additional
>>> restrict beyond the specification of an IDN.
>>>
>>> Xuelei
>>>
>>>>> Can I push the changeset?
>>>> I think it's better to ask someone in the networking team to make the
>>>> suggestion. From what I read Michael in this thread, he does not seem
>>>> totally agreed with your code changes (at least not the 00 version).
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>>> Ping.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>>> Please review the new update:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>>
>>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid
>>>>>>>> IDN.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Xuelei
>>>>>>>>
>
From sean.coffey at oracle.com Fri Aug 9 09:26:27 2013
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Fri, 09 Aug 2013 17:26:27 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <52041965.3090808@oracle.com>
References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com>
<5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com>
<520318F3.7080609@oracle.com> <52032625.3000501@oracle.com>
<52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com>
<5203A243.60505@oracle.com> <5203E642.40005@oracle.com>
<52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com>
<52041895.9010706@oracle.com> <52041965.3090808@oracle.com>
Message-ID: <52051833.5090204@oracle.com>
On the regression testcase theme, it got me thinking as to whether we've
any java APIs which can query what the native heap usage of the JVM. Is
that available over JMX ?
I tried the MBeanServer approach but didn't get the expected results.
Queried the "NonHeapMemoryUsage" object.
something like.
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
ObjectName memory = new ObjectName(MEMORY_MXBEAN_NAME);
Object ob = server.getAttribute(memory, "NonHeapMemoryUsage");
MemoryUsage mu = MemoryUsage.from((CompositeData) ob);
System.out.println("Nonheap : " + mu.getUsed());
What exactly is JMX measuring in "NonHeapMemoryUsage" mode ? Any pointers ?
regards,
Sean.
On 08/08/13 23:19, Michael McMahon wrote:
> Ivan,
>
> Right, it's not worth trying to do the equivalent, whatever it is, for
> Windows.
> The test is fine with me.
>
> Thanks
> Michael
>
> On 08/08/13 23:15, Ivan Gerasimov wrote:
>> Michael,
>>
>> The test uses /proc/self/stat file to detect changes in virtual
>> memory usage.
>> This approach is specific for Linux.
>> That's why I included the check of OS in the test.
>>
>> Sincerely yours,
>> Ivan
>>
>> On 09.08.2013 1:38, Michael McMahon wrote:
>>> Yes, definitely "othervm" would be required for the test. Also, why
>>> skip other OS'es?
>>> The fix is only for Linux, but it might catch future leaks on Windows.
>>>
>>> The trouble with tests like this, is they sometimes don't age well.
>>> Future changes in OS kernel behavior could cause problems but I
>>> guess 32MB is a fairly large difference.
>>> So, it should be okay
>>>
>>> Michael
>>>
>>> On 08/08/13 22:15, David Holmes wrote:
>>>> Main fix looks good to me.
>>>>
>>>> Regression test may need some tweaking eg I think othervm will be
>>>> needed.
>>>>
>>>> Also this:
>>>>
>>>> System.out.println("WARNING: Cannot perform memory leak detection
>>>> on this OS");
>>>>
>>>> should probably just say something like "Test skipped on this OS" -
>>>> there are other tests that do this so just check if there is common
>>>> terminology. (In the future we may have keyword tags to flag this
>>>> as linux only etc.)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>> fix.
>>>>>
>>>>> Here's webrev that includes the test:
>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>
>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101
>>>>> and jdk7
>>>>> as expected.
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>> Looks good to me. Thanks Ivan.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>> Hello Chris!
>>>>>>>
>>>>>>> Here's the update:
>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>
>>>>>>> Thanks for offering the sponsorship!
>>>>>>> Here's the hg-export
>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>
>>>>>>>> Can you please make the changes suggested by both David and Alan (
>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>> GetStringUTFChars
>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>> jdk8 for
>>>>>>>> you.
>>>>>>>>
>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>> Ivan,
>>>>>>>>>
>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>> David, Alan,
>>>>>>>>>>
>>>>>>>>>> I added checking for NULL results and throwing OOMException if
>>>>>>>>>> necessary.
>>>>>>>>>
>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>
>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>
>>>>>>>>> Assuming a correct VM implementation if NULL is returned then
>>>>>>>>> an OOME
>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>> native
>>>>>>>>> code
>>>>>>>>> returns to Java.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>> indentation.
>>>>>>>>>>
>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>
>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>> cannot
>>>>>>>>>>>> return
>>>>>>>>>>>> NULL.
>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap()
>>>>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>> stops
>>>>>>>>>>>> VM.
>>>>>>>>>>>
>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed
>>>>>>>>>>> to throw
>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>
>>>>>>>>>>> I recommend that you check for NULL and/or a pending exception.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are
>>>>>>>>>>>>> there) is
>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name
>>>>>>>>>>>>> returns
>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak
>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet
>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>
>
From chris.hegarty at oracle.com Fri Aug 9 09:57:08 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 09 Aug 2013 16:57:08 +0000
Subject: hg: jdk8/tl/jdk: 8022724: lint warnings in j.u.concurrent packages
Message-ID: <20130809165838.A48BB48759@hg.openjdk.java.net>
Changeset: ce1c874903cb
Author: dl
Date: 2013-08-09 17:56 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce1c874903cb
8022724: lint warnings in j.u.concurrent packages
Reviewed-by: chegar, lancea, darcy
! src/share/classes/java/util/concurrent/CompletableFuture.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/atomic/Striped64.java
From dan.xu at oracle.com Fri Aug 9 10:55:59 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Fri, 09 Aug 2013 17:55:59 +0000
Subject: hg: jdk8/tl/jdk: 8021977: Opening a file using java.io can throw
IOException on Windows
Message-ID: <20130809175620.B80534875C@hg.openjdk.java.net>
Changeset: 03822f2389bf
Author: dxu
Date: 2013-08-09 10:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03822f2389bf
8021977: Opening a file using java.io can throw IOException on Windows
Summary: Remove IOException related error-handling code for backward compatibility
Reviewed-by: alanb, lancea, mr
! src/windows/native/java/io/io_util_md.c
From xueming.shen at oracle.com Fri Aug 9 12:38:03 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Fri, 09 Aug 2013 19:38:03 +0000
Subject: hg: jdk8/tl/jdk: 8020054: (tz) Support tzdata2013d
Message-ID: <20130809193841.0F87148762@hg.openjdk.java.net>
Changeset: a7c341f30747
Author: sherman
Date: 2013-08-09 12:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7c341f30747
8020054: (tz) Support tzdata2013d
Summary: update the jdk8 tz data to version 2013d
Reviewed-by: coffeys, peytoia
! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/antarctica
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/etcetera
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/factory
! make/sun/javazic/tzdata/iso3166.tab
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/pacificnew
! make/sun/javazic/tzdata/solar87
! make/sun/javazic/tzdata/solar88
! make/sun/javazic/tzdata/solar89
! make/sun/javazic/tzdata/southamerica
! make/sun/javazic/tzdata/systemv
! make/sun/javazic/tzdata/zone.tab
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/etcetera
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/factory
! test/sun/util/calendar/zi/tzdata/iso3166.tab
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/pacificnew
! test/sun/util/calendar/zi/tzdata/solar87
! test/sun/util/calendar/zi/tzdata/solar88
! test/sun/util/calendar/zi/tzdata/solar89
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/systemv
! test/sun/util/calendar/zi/tzdata/zone.tab
From kumar.x.srinivasan at oracle.com Fri Aug 9 15:36:04 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Fri, 09 Aug 2013 22:36:04 +0000
Subject: hg: jdk8/tl/langtools: 8022161: javac Null Pointer Exception in
Enter.visitTopLevel
Message-ID: <20130809223615.468C748776@hg.openjdk.java.net>
Changeset: d601238641e6
Author: ksrini
Date: 2013-08-09 15:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d601238641e6
8022161: javac Null Pointer Exception in Enter.visitTopLevel
Reviewed-by: jjg, vromero, jlahoda
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! test/tools/javac/TestPkgInfo.java
From xuelei.fan at oracle.com Fri Aug 9 18:13:48 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 10 Aug 2013 09:13:48 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52050A01.3030503@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
Message-ID: <520593CC.4010608@oracle.com>
Hi Michael,
I plan to address this issue in SNIHostName. I have filled another two
the potential bugs in IDN.
Thank you, and other people, for the feedback.
Thanks,
Xuelei
On 8/9/2013 11:25 PM, Xuelei Fan wrote:
> On 8/9/2013 7:31 PM, Michael McMahon wrote:
>> I don't see how this fixes the original problem as the SNIHostName spec
>> still doesn't like hostnames with a trailing '.'
>>
> The bug description did not reflect the IDN specification correctly. If
> "com." is a valid IDN, SNIHostName should accept it an an valid
> hostname. The host name in SNIHostName is nothing more or less than an
> standard IDN.
>
> I added a comment in the bug: "com." and "." are valid IDN according the
> IDN and domain name specifications. I will contact the bug reporter
> about this point.
>
> Xuelei
>
>> I'd prefer to check first where that requirement is coming from, if it is
>> actually necessary, and if not consider removing it from SNIHostName.
>> If it is necessary, then the check should be implemented in SNIHostName.
>>
>> Michael
>>
>> On 09/08/13 05:28, Xuelei Fan wrote:
>>> Thanks for your feedback and suggestions.
>>>
>>> Here is the new webrev:
>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>
>>> "." is regarded as valid IDN in this update.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>>>
>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>>>
>>>>>>> $ nslookup com..
>>>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>>>
>>>>>>> but
>>>>>>>
>>>>>>> $ nslookup .
>>>>>>> Server: 192.168.10.1
>>>>>>> Address: 192.168.10.1#53
>>>>>>>
>>>>>>> Non-authoritative answer:
>>>>>>> *** Can't find .: No answer
>>>>>>>
>>>>>> Thanks for the testing. The behaviors are the same as this fix now.
>>>>> No exactly. It seems nslookup still regards "." legal but just cannot
>>>>> find an IP for it.
>>>>>
>>>> I'm not sure whether a root domain name can be stand alone. Root label
>>>> is not considered as a label in IDN. I think it is safe to regard that
>>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner
>>>> case.
>>>>
>>>> There are many online IDN conversion web services, some of them can
>>>> convert ".", some of the cannot. In the present implementation, we
>>>> cannot recognize ".", and IDN.toASCII(".") throws
>>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
>>>> a better exception for IDN.toASCII(".").
>>>>
>>>>>> Learn something new today to use nslookup.
>>>>>>
>>>>>>> Also, since this bug was originally about SNIHostName, do you need to
>>>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>>>
>>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>>>>> IDN. However, we may need to rethink about the comparing of two
>>>>>> IDN, for
>>>>>> example, "example.com." should equal to "example.com". I want to
>>>>>> consider it in another bug.
>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets?
>>>>> And
>>>>> it's not one is another's subset?
>>>>>
>>>> Per TLS specification, host name in SNI is an IDN. The spec of
>>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name
>>>> (IDN) compliant with the RFC 3490 specification". The spec in
>>>> SNIHostName has the same means as IDN. I won't want to add additional
>>>> restrict beyond the specification of an IDN.
>>>>
>>>> Xuelei
>>>>
>>>>>> Can I push the changeset?
>>>>> I think it's better to ask someone in the networking team to make the
>>>>> suggestion. From what I read Michael in this thread, he does not seem
>>>>> totally agreed with your code changes (at least not the 00 version).
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>>> Thanks
>>>>>>> Max
>>>>>>>
>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>>>> Ping.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Xuelei
>>>>>>>>
>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>>>> Please review the new update:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>>>
>>>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid
>>>>>>>>> IDN.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Xuelei
>>>>>>>>>
>>
>
From xuelei.fan at oracle.com Fri Aug 9 19:49:59 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 10 Aug 2013 10:49:59 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <520593CC.4010608@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com>
Message-ID: <5205AA57.6050704@oracle.com>
Hi Michael,
It is pretty hard to get the issue solved in SNIHostName in a good
sharp. Here is my try to state why we should fix the issue in IDN.
In SNIHostName, the following hostname are not accepted as valid hostname:
1. empty hostname
2. hostname ends with a trailing dot
3. hostname does not comply to RFC 3490.
The process in SNIHostName looks like:
1. call IDN.toASCII() to convert a string hostname
2. check that the return value of #1 is an valid hostname (non-empty,
non-end-with-tailing-dot).
At present, the IDN cannot handle the following IDN properly.
1. returns "com" for "com."
the trailing dot is swallowed.
2. throws StringIndexOutOfBoundsException for "."
If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() should
be able to handle it; otherwise, IDN.toASCII() should throw IAE as the
specification suggested. However, IDN.toASCII(".") throws
StringIndexOutOfBoundsException, this behavior does not comply the the
specification:
3. throws StringIndexOutOfBoundsException for "example...net"
As #2.
We can address #1 and #2 in SNIHostName, but the checking is overloaded
as IDN also need to address the issue. And SNIHostName has to know
what's the separators (".", "\u3002, etc) of IDN in order to check the
dot character. It is not a good encapsulation, and involved in too much
about the details of domain name, I think.
It is a little big hard to address #3 in SNIHostName.
Both all of above issue can be easily addressed in IDN. And once IDN
addressed these issues, the current SNIHostName is able to handle
invalid hostname (empty, trailing dot, etc) correctly. We won't need to
touch SNIHostName any more.
Please consider it.
The latest webrev is at:
http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
Thanks,
Xuelei
On 8/10/2013 9:13 AM, Xuelei Fan wrote:
> Hi Michael,
>
> I plan to address this issue in SNIHostName. I have filled another two
> the potential bugs in IDN.
>
> Thank you, and other people, for the feedback.
>
> Thanks,
> Xuelei
>
> On 8/9/2013 11:25 PM, Xuelei Fan wrote:
>> On 8/9/2013 7:31 PM, Michael McMahon wrote:
>>> I don't see how this fixes the original problem as the SNIHostName spec
>>> still doesn't like hostnames with a trailing '.'
>>>
>> The bug description did not reflect the IDN specification correctly. If
>> "com." is a valid IDN, SNIHostName should accept it an an valid
>> hostname. The host name in SNIHostName is nothing more or less than an
>> standard IDN.
>>
>> I added a comment in the bug: "com." and "." are valid IDN according the
>> IDN and domain name specifications. I will contact the bug reporter
>> about this point.
>>
>> Xuelei
>>
>>> I'd prefer to check first where that requirement is coming from, if it is
>>> actually necessary, and if not consider removing it from SNIHostName.
>>> If it is necessary, then the check should be implemented in SNIHostName.
>>>
>>> Michael
>>>
>>> On 09/08/13 05:28, Xuelei Fan wrote:
>>>> Thanks for your feedback and suggestions.
>>>>
>>>> Here is the new webrev:
>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>>
>>>> "." is regarded as valid IDN in this update.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>>>>
>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>>>>
>>>>>>>> $ nslookup com..
>>>>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>>>>
>>>>>>>> but
>>>>>>>>
>>>>>>>> $ nslookup .
>>>>>>>> Server: 192.168.10.1
>>>>>>>> Address: 192.168.10.1#53
>>>>>>>>
>>>>>>>> Non-authoritative answer:
>>>>>>>> *** Can't find .: No answer
>>>>>>>>
>>>>>>> Thanks for the testing. The behaviors are the same as this fix now.
>>>>>> No exactly. It seems nslookup still regards "." legal but just cannot
>>>>>> find an IP for it.
>>>>>>
>>>>> I'm not sure whether a root domain name can be stand alone. Root label
>>>>> is not considered as a label in IDN. I think it is safe to regard that
>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner
>>>>> case.
>>>>>
>>>>> There are many online IDN conversion web services, some of them can
>>>>> convert ".", some of the cannot. In the present implementation, we
>>>>> cannot recognize ".", and IDN.toASCII(".") throws
>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
>>>>> a better exception for IDN.toASCII(".").
>>>>>
>>>>>>> Learn something new today to use nslookup.
>>>>>>>
>>>>>>>> Also, since this bug was originally about SNIHostName, do you need to
>>>>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>>>>
>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>>>>>> IDN. However, we may need to rethink about the comparing of two
>>>>>>> IDN, for
>>>>>>> example, "example.com." should equal to "example.com". I want to
>>>>>>> consider it in another bug.
>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets?
>>>>>> And
>>>>>> it's not one is another's subset?
>>>>>>
>>>>> Per TLS specification, host name in SNI is an IDN. The spec of
>>>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name
>>>>> (IDN) compliant with the RFC 3490 specification". The spec in
>>>>> SNIHostName has the same means as IDN. I won't want to add additional
>>>>> restrict beyond the specification of an IDN.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>>> Can I push the changeset?
>>>>>> I think it's better to ask someone in the networking team to make the
>>>>>> suggestion. From what I read Michael in this thread, he does not seem
>>>>>> totally agreed with your code changes (at least not the 00 version).
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Max
>>>>>>>>
>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>>>>> Ping.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Xuelei
>>>>>>>>>
>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>>>>> Please review the new update:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>>>>
>>>>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid
>>>>>>>>>> IDN.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Xuelei
>>>>>>>>>>
>>>
>>
>
From vicente.romero at oracle.com Sat Aug 10 05:28:55 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 10 Aug 2013 12:28:55 +0000
Subject: hg: jdk8/tl/langtools: 8009640: -profile does not work when
-bootclasspath specified
Message-ID: <20130810122858.15F1748789@hg.openjdk.java.net>
Changeset: 0d9bc764cac7
Author: vromero
Date: 2013-08-10 13:27 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d9bc764cac7
8009640: -profile does not work when -bootclasspath specified
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/resources/javac.properties
+ test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java
From vicente.romero at oracle.com Sat Aug 10 08:27:28 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 10 Aug 2013 15:27:28 +0000
Subject: hg: jdk8/tl/langtools: 8022622: javac,
two tests are failing with compile time error after class Collector
was modified
Message-ID: <20130810152735.353B74878B@hg.openjdk.java.net>
Changeset: 8f282dc58dfc
Author: vromero
Date: 2013-08-10 16:26 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8f282dc58dfc
8022622: javac, two tests are failing with compile time error after class Collector was modified
Reviewed-by: mcimadamore
! test/tools/javac/lambda/TargetType59.java
! test/tools/javac/lambda/TargetType62.java
From vicente.romero at oracle.com Sat Aug 10 08:30:27 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 10 Aug 2013 15:30:27 +0000
Subject: hg: jdk8/tl/langtools: 6983297: methods missing from NewArrayTree
Message-ID: <20130810153030.01FCA4878C@hg.openjdk.java.net>
Changeset: aa6c6f8b5622
Author: vromero
Date: 2013-08-10 16:29 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aa6c6f8b5622
6983297: methods missing from NewArrayTree
Reviewed-by: jjg
! src/share/classes/com/sun/source/tree/NewArrayTree.java
! src/share/classes/com/sun/source/util/TreeScanner.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! test/tools/javac/tree/SourceTreeScannerTest.java
From xuelei.fan at oracle.com Sun Aug 11 18:09:33 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 12 Aug 2013 09:09:33 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5205AA57.6050704@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
Message-ID: <520835CD.5090402@oracle.com>
new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/
Added a new test to test illegal hostname in SNIHostName.
Xuelei
On 8/10/2013 10:49 AM, Xuelei Fan wrote:
> Hi Michael,
>
> It is pretty hard to get the issue solved in SNIHostName in a good
> sharp. Here is my try to state why we should fix the issue in IDN.
>
> In SNIHostName, the following hostname are not accepted as valid hostname:
> 1. empty hostname
> 2. hostname ends with a trailing dot
> 3. hostname does not comply to RFC 3490.
>
> The process in SNIHostName looks like:
> 1. call IDN.toASCII() to convert a string hostname
> 2. check that the return value of #1 is an valid hostname (non-empty,
> non-end-with-tailing-dot).
>
> At present, the IDN cannot handle the following IDN properly.
> 1. returns "com" for "com."
> the trailing dot is swallowed.
>
> 2. throws StringIndexOutOfBoundsException for "."
> If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() should
> be able to handle it; otherwise, IDN.toASCII() should throw IAE as the
> specification suggested. However, IDN.toASCII(".") throws
> StringIndexOutOfBoundsException, this behavior does not comply the the
> specification:
>
> 3. throws StringIndexOutOfBoundsException for "example...net"
> As #2.
>
> We can address #1 and #2 in SNIHostName, but the checking is overloaded
> as IDN also need to address the issue. And SNIHostName has to know
> what's the separators (".", "\u3002, etc) of IDN in order to check the
> dot character. It is not a good encapsulation, and involved in too much
> about the details of domain name, I think.
>
> It is a little big hard to address #3 in SNIHostName.
>
> Both all of above issue can be easily addressed in IDN. And once IDN
> addressed these issues, the current SNIHostName is able to handle
> invalid hostname (empty, trailing dot, etc) correctly. We won't need to
> touch SNIHostName any more.
>
> Please consider it.
>
> The latest webrev is at:
> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>
> Thanks,
> Xuelei
>
> On 8/10/2013 9:13 AM, Xuelei Fan wrote:
>> Hi Michael,
>>
>> I plan to address this issue in SNIHostName. I have filled another two
>> the potential bugs in IDN.
>>
>> Thank you, and other people, for the feedback.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/9/2013 11:25 PM, Xuelei Fan wrote:
>>> On 8/9/2013 7:31 PM, Michael McMahon wrote:
>>>> I don't see how this fixes the original problem as the SNIHostName spec
>>>> still doesn't like hostnames with a trailing '.'
>>>>
>>> The bug description did not reflect the IDN specification correctly. If
>>> "com." is a valid IDN, SNIHostName should accept it an an valid
>>> hostname. The host name in SNIHostName is nothing more or less than an
>>> standard IDN.
>>>
>>> I added a comment in the bug: "com." and "." are valid IDN according the
>>> IDN and domain name specifications. I will contact the bug reporter
>>> about this point.
>>>
>>> Xuelei
>>>
>>>> I'd prefer to check first where that requirement is coming from, if it is
>>>> actually necessary, and if not consider removing it from SNIHostName.
>>>> If it is necessary, then the check should be implemented in SNIHostName.
>>>>
>>>> Michael
>>>>
>>>> On 09/08/13 05:28, Xuelei Fan wrote:
>>>>> Thanks for your feedback and suggestions.
>>>>>
>>>>> Here is the new webrev:
>>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>>>
>>>>> "." is regarded as valid IDN in this update.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>>>>>
>>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>>>>>
>>>>>>>>> $ nslookup com..
>>>>>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>>>>>
>>>>>>>>> but
>>>>>>>>>
>>>>>>>>> $ nslookup .
>>>>>>>>> Server: 192.168.10.1
>>>>>>>>> Address: 192.168.10.1#53
>>>>>>>>>
>>>>>>>>> Non-authoritative answer:
>>>>>>>>> *** Can't find .: No answer
>>>>>>>>>
>>>>>>>> Thanks for the testing. The behaviors are the same as this fix now.
>>>>>>> No exactly. It seems nslookup still regards "." legal but just cannot
>>>>>>> find an IP for it.
>>>>>>>
>>>>>> I'm not sure whether a root domain name can be stand alone. Root label
>>>>>> is not considered as a label in IDN. I think it is safe to regard that
>>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner
>>>>>> case.
>>>>>>
>>>>>> There are many online IDN conversion web services, some of them can
>>>>>> convert ".", some of the cannot. In the present implementation, we
>>>>>> cannot recognize ".", and IDN.toASCII(".") throws
>>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
>>>>>> a better exception for IDN.toASCII(".").
>>>>>>
>>>>>>>> Learn something new today to use nslookup.
>>>>>>>>
>>>>>>>>> Also, since this bug was originally about SNIHostName, do you need to
>>>>>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>>>>>
>>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>>>>>>> IDN. However, we may need to rethink about the comparing of two
>>>>>>>> IDN, for
>>>>>>>> example, "example.com." should equal to "example.com". I want to
>>>>>>>> consider it in another bug.
>>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets?
>>>>>>> And
>>>>>>> it's not one is another's subset?
>>>>>>>
>>>>>> Per TLS specification, host name in SNI is an IDN. The spec of
>>>>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name
>>>>>> (IDN) compliant with the RFC 3490 specification". The spec in
>>>>>> SNIHostName has the same means as IDN. I won't want to add additional
>>>>>> restrict beyond the specification of an IDN.
>>>>>>
>>>>>> Xuelei
>>>>>>
>>>>>>>> Can I push the changeset?
>>>>>>> I think it's better to ask someone in the networking team to make the
>>>>>>> suggestion. From what I read Michael in this thread, he does not seem
>>>>>>> totally agreed with your code changes (at least not the 00 version).
>>>>>>>
>>>>>>> Thanks
>>>>>>> Max
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Xuelei
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>>>>>> Ping.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Xuelei
>>>>>>>>>>
>>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>>>>>> Please review the new update:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid
>>>>>>>>>>> IDN.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Xuelei
>>>>>>>>>>>
>>>>
>>>
>>
>
From xuelei.fan at oracle.com Sun Aug 11 18:22:09 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Mon, 12 Aug 2013 01:22:09 +0000
Subject: hg: jdk8/tl/jdk: 8022487: DEREncodedKeyValue.supportedKeyTypes should
be private
Message-ID: <20130812012258.BACF2487A1@hg.openjdk.java.net>
Changeset: ea4f4164422e
Author: xuelei
Date: 2013-08-11 18:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea4f4164422e
8022487: DEREncodedKeyValue.supportedKeyTypes should be private
Reviewed-by: mullan
! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java
From weijun.wang at oracle.com Sun Aug 11 20:11:42 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 12 Aug 2013 11:11:42 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <520835CD.5090402@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com>
Message-ID: <5208526E.5020808@oracle.com>
I think the fix is adequate and necessary.
One problem: lines 367-373 adds a new IAE to ToUnicode but the method
should not fail forever.
And some small comments on styles etc.
On 8/12/13 9:09 AM, Xuelei Fan wrote:
> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/
Lines 123 and 185:
184 p = q + 1;
185 if (p < input.length() || q == (input.length() - 1)) {
186 // has more labels, or keep the trailing dot as at
present
187 out.append('.');
188 }
I prefer
if (q < input.length()) { // Ah, a dot!
out.append('.');
}
p = q + 1;
Lines 282, 335, 270: Insert a blank after "if".
Lines 284 and 372: nslookup uses "empty label", which I like better.
Lines 453 and 460: Personally I don't like the parenthesis for the whole
return value, but you have your choice.
Lines 280 and 333: How about we call them steps 8a and 8b?
>
> Added a new test to test illegal hostname in SNIHostName.
Excellent. Otherwise I will be wondering why the fix in IDN could solve
the problem as described in the bug description.
Thanks
Max
>
> Xuelei
>
> On 8/10/2013 10:49 AM, Xuelei Fan wrote:
>> Hi Michael,
>>
>> It is pretty hard to get the issue solved in SNIHostName in a good
>> sharp. Here is my try to state why we should fix the issue in IDN.
>>
>> In SNIHostName, the following hostname are not accepted as valid hostname:
>> 1. empty hostname
>> 2. hostname ends with a trailing dot
>> 3. hostname does not comply to RFC 3490.
>>
>> The process in SNIHostName looks like:
>> 1. call IDN.toASCII() to convert a string hostname
>> 2. check that the return value of #1 is an valid hostname (non-empty,
>> non-end-with-tailing-dot).
>>
>> At present, the IDN cannot handle the following IDN properly.
>> 1. returns "com" for "com."
>> the trailing dot is swallowed.
>>
>> 2. throws StringIndexOutOfBoundsException for "."
>> If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() should
>> be able to handle it; otherwise, IDN.toASCII() should throw IAE as the
>> specification suggested. However, IDN.toASCII(".") throws
>> StringIndexOutOfBoundsException, this behavior does not comply the the
>> specification:
>>
>> 3. throws StringIndexOutOfBoundsException for "example...net"
>> As #2.
>>
>> We can address #1 and #2 in SNIHostName, but the checking is overloaded
>> as IDN also need to address the issue. And SNIHostName has to know
>> what's the separators (".", "\u3002, etc) of IDN in order to check the
>> dot character. It is not a good encapsulation, and involved in too much
>> about the details of domain name, I think.
>>
>> It is a little big hard to address #3 in SNIHostName.
>>
>> Both all of above issue can be easily addressed in IDN. And once IDN
>> addressed these issues, the current SNIHostName is able to handle
>> invalid hostname (empty, trailing dot, etc) correctly. We won't need to
>> touch SNIHostName any more.
>>
>> Please consider it.
>>
>> The latest webrev is at:
>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>
>> Thanks,
>> Xuelei
>>
>> On 8/10/2013 9:13 AM, Xuelei Fan wrote:
>>> Hi Michael,
>>>
>>> I plan to address this issue in SNIHostName. I have filled another two
>>> the potential bugs in IDN.
>>>
>>> Thank you, and other people, for the feedback.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 8/9/2013 11:25 PM, Xuelei Fan wrote:
>>>> On 8/9/2013 7:31 PM, Michael McMahon wrote:
>>>>> I don't see how this fixes the original problem as the SNIHostName spec
>>>>> still doesn't like hostnames with a trailing '.'
>>>>>
>>>> The bug description did not reflect the IDN specification correctly. If
>>>> "com." is a valid IDN, SNIHostName should accept it an an valid
>>>> hostname. The host name in SNIHostName is nothing more or less than an
>>>> standard IDN.
>>>>
>>>> I added a comment in the bug: "com." and "." are valid IDN according the
>>>> IDN and domain name specifications. I will contact the bug reporter
>>>> about this point.
>>>>
>>>> Xuelei
>>>>
>>>>> I'd prefer to check first where that requirement is coming from, if it is
>>>>> actually necessary, and if not consider removing it from SNIHostName.
>>>>> If it is necessary, then the check should be implemented in SNIHostName.
>>>>>
>>>>> Michael
>>>>>
>>>>> On 09/08/13 05:28, Xuelei Fan wrote:
>>>>>> Thanks for your feedback and suggestions.
>>>>>>
>>>>>> Here is the new webrev:
>>>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>>>>
>>>>>> "." is regarded as valid IDN in this update.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>>>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>>>>>>
>>>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>>>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>>>>>>
>>>>>>>>>> $ nslookup com..
>>>>>>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>>>>>>
>>>>>>>>>> but
>>>>>>>>>>
>>>>>>>>>> $ nslookup .
>>>>>>>>>> Server: 192.168.10.1
>>>>>>>>>> Address: 192.168.10.1#53
>>>>>>>>>>
>>>>>>>>>> Non-authoritative answer:
>>>>>>>>>> *** Can't find .: No answer
>>>>>>>>>>
>>>>>>>>> Thanks for the testing. The behaviors are the same as this fix now.
>>>>>>>> No exactly. It seems nslookup still regards "." legal but just cannot
>>>>>>>> find an IP for it.
>>>>>>>>
>>>>>>> I'm not sure whether a root domain name can be stand alone. Root label
>>>>>>> is not considered as a label in IDN. I think it is safe to regard that
>>>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner
>>>>>>> case.
>>>>>>>
>>>>>>> There are many online IDN conversion web services, some of them can
>>>>>>> convert ".", some of the cannot. In the present implementation, we
>>>>>>> cannot recognize ".", and IDN.toASCII(".") throws
>>>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is
>>>>>>> a better exception for IDN.toASCII(".").
>>>>>>>
>>>>>>>>> Learn something new today to use nslookup.
>>>>>>>>>
>>>>>>>>>> Also, since this bug was originally about SNIHostName, do you need to
>>>>>>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>>>>>>
>>>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in
>>>>>>>>> IDN. However, we may need to rethink about the comparing of two
>>>>>>>>> IDN, for
>>>>>>>>> example, "example.com." should equal to "example.com". I want to
>>>>>>>>> consider it in another bug.
>>>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets?
>>>>>>>> And
>>>>>>>> it's not one is another's subset?
>>>>>>>>
>>>>>>> Per TLS specification, host name in SNI is an IDN. The spec of
>>>>>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name
>>>>>>> (IDN) compliant with the RFC 3490 specification". The spec in
>>>>>>> SNIHostName has the same means as IDN. I won't want to add additional
>>>>>>> restrict beyond the specification of an IDN.
>>>>>>>
>>>>>>> Xuelei
>>>>>>>
>>>>>>>>> Can I push the changeset?
>>>>>>>> I think it's better to ask someone in the networking team to make the
>>>>>>>> suggestion. From what I read Michael in this thread, he does not seem
>>>>>>>> totally agreed with your code changes (at least not the 00 version).
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Max
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Xuelei
>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Max
>>>>>>>>>>
>>>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>>>>>>> Ping.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Xuelei
>>>>>>>>>>>
>>>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>>>>>>> Please review the new update:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid
>>>>>>>>>>>> IDN.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Xuelei
>>>>>>>>>>>>
>>>>>
>>>>
>>>
>>
>
From weijun.wang at oracle.com Sun Aug 11 20:15:13 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 12 Aug 2013 11:15:13 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5208526E.5020808@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
Message-ID: <52085341.5070603@oracle.com>
> if (q < input.length()) { // Ah, a dot!
> out.append('.');
> }
> p = q + 1;
Using
if (q != input.length())
should be even better. The searchDots method clearly specifies that "or
if there is no dots, return the length of input string".
--Max
From xuelei.fan at oracle.com Sun Aug 11 22:45:12 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 12 Aug 2013 13:45:12 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5208526E.5020808@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
Message-ID: <52087668.9080500@oracle.com>
new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
> Lines 280 and 333: How about we call them steps 8a and 8b?
Step 8 is referring to the steps in RFC 3490. Let's use "step 8".
Thanks,
Xuelei
On 8/12/2013 11:11 AM, Weijun Wang wrote:
> I think the fix is adequate and necessary.
>
> One problem: lines 367-373 adds a new IAE to ToUnicode but the method
> should not fail forever.
>
> And some small comments on styles etc.
>
> On 8/12/13 9:09 AM, Xuelei Fan wrote:
>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/
>
> Lines 123 and 185:
>
> 184 p = q + 1;
> 185 if (p < input.length() || q == (input.length() - 1)) {
> 186 // has more labels, or keep the trailing dot as at
> present
> 187 out.append('.');
> 188 }
>
> I prefer
>
> if (q < input.length()) { // Ah, a dot!
> out.append('.');
> }
> p = q + 1;
>
> Lines 282, 335, 270: Insert a blank after "if".
>
> Lines 284 and 372: nslookup uses "empty label", which I like better.
>
> Lines 453 and 460: Personally I don't like the parenthesis for the whole
> return value, but you have your choice.
>
> Lines 280 and 333: How about we call them steps 8a and 8b?
>
>>
>> Added a new test to test illegal hostname in SNIHostName.
>
> Excellent. Otherwise I will be wondering why the fix in IDN could solve
> the problem as described in the bug description.
>
> Thanks
> Max
>
>>
>> Xuelei
>>
>> On 8/10/2013 10:49 AM, Xuelei Fan wrote:
>>> Hi Michael,
>>>
>>> It is pretty hard to get the issue solved in SNIHostName in a good
>>> sharp. Here is my try to state why we should fix the issue in IDN.
>>>
>>> In SNIHostName, the following hostname are not accepted as valid
>>> hostname:
>>> 1. empty hostname
>>> 2. hostname ends with a trailing dot
>>> 3. hostname does not comply to RFC 3490.
>>>
>>> The process in SNIHostName looks like:
>>> 1. call IDN.toASCII() to convert a string hostname
>>> 2. check that the return value of #1 is an valid hostname (non-empty,
>>> non-end-with-tailing-dot).
>>>
>>> At present, the IDN cannot handle the following IDN properly.
>>> 1. returns "com" for "com."
>>> the trailing dot is swallowed.
>>>
>>> 2. throws StringIndexOutOfBoundsException for "."
>>> If "." is an valid IDN that comply to RFC 3490, IDN.toASCII()
>>> should
>>> be able to handle it; otherwise, IDN.toASCII() should throw IAE as the
>>> specification suggested. However, IDN.toASCII(".") throws
>>> StringIndexOutOfBoundsException, this behavior does not comply the the
>>> specification:
>>>
>>> 3. throws StringIndexOutOfBoundsException for "example...net"
>>> As #2.
>>>
>>> We can address #1 and #2 in SNIHostName, but the checking is overloaded
>>> as IDN also need to address the issue. And SNIHostName has to know
>>> what's the separators (".", "\u3002, etc) of IDN in order to check the
>>> dot character. It is not a good encapsulation, and involved in too much
>>> about the details of domain name, I think.
>>>
>>> It is a little big hard to address #3 in SNIHostName.
>>>
>>> Both all of above issue can be easily addressed in IDN. And once IDN
>>> addressed these issues, the current SNIHostName is able to handle
>>> invalid hostname (empty, trailing dot, etc) correctly. We won't need to
>>> touch SNIHostName any more.
>>>
>>> Please consider it.
>>>
>>> The latest webrev is at:
>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 8/10/2013 9:13 AM, Xuelei Fan wrote:
>>>> Hi Michael,
>>>>
>>>> I plan to address this issue in SNIHostName. I have filled another two
>>>> the potential bugs in IDN.
>>>>
>>>> Thank you, and other people, for the feedback.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 8/9/2013 11:25 PM, Xuelei Fan wrote:
>>>>> On 8/9/2013 7:31 PM, Michael McMahon wrote:
>>>>>> I don't see how this fixes the original problem as the SNIHostName
>>>>>> spec
>>>>>> still doesn't like hostnames with a trailing '.'
>>>>>>
>>>>> The bug description did not reflect the IDN specification
>>>>> correctly. If
>>>>> "com." is a valid IDN, SNIHostName should accept it an an valid
>>>>> hostname. The host name in SNIHostName is nothing more or less
>>>>> than an
>>>>> standard IDN.
>>>>>
>>>>> I added a comment in the bug: "com." and "." are valid IDN
>>>>> according the
>>>>> IDN and domain name specifications. I will contact the bug reporter
>>>>> about this point.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>> I'd prefer to check first where that requirement is coming from,
>>>>>> if it is
>>>>>> actually necessary, and if not consider removing it from SNIHostName.
>>>>>> If it is necessary, then the check should be implemented in
>>>>>> SNIHostName.
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>> On 09/08/13 05:28, Xuelei Fan wrote:
>>>>>>> Thanks for your feedback and suggestions.
>>>>>>>
>>>>>>> Here is the new webrev:
>>>>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>>>>>
>>>>>>> "." is regarded as valid IDN in this update.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>>>>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>>>>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>>>>>>>
>>>>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>>>>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>>>>>>>
>>>>>>>>>>> $ nslookup com..
>>>>>>>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>>>>>>>
>>>>>>>>>>> but
>>>>>>>>>>>
>>>>>>>>>>> $ nslookup .
>>>>>>>>>>> Server: 192.168.10.1
>>>>>>>>>>> Address: 192.168.10.1#53
>>>>>>>>>>>
>>>>>>>>>>> Non-authoritative answer:
>>>>>>>>>>> *** Can't find .: No answer
>>>>>>>>>>>
>>>>>>>>>> Thanks for the testing. The behaviors are the same as this
>>>>>>>>>> fix now.
>>>>>>>>> No exactly. It seems nslookup still regards "." legal but just
>>>>>>>>> cannot
>>>>>>>>> find an IP for it.
>>>>>>>>>
>>>>>>>> I'm not sure whether a root domain name can be stand alone.
>>>>>>>> Root label
>>>>>>>> is not considered as a label in IDN. I think it is safe to
>>>>>>>> regard that
>>>>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a
>>>>>>>> corner
>>>>>>>> case.
>>>>>>>>
>>>>>>>> There are many online IDN conversion web services, some of them can
>>>>>>>> convert ".", some of the cannot. In the present implementation, we
>>>>>>>> cannot recognize ".", and IDN.toASCII(".") throws
>>>>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering
>>>>>>>> IAE is
>>>>>>>> a better exception for IDN.toASCII(".").
>>>>>>>>
>>>>>>>>>> Learn something new today to use nslookup.
>>>>>>>>>>
>>>>>>>>>>> Also, since this bug was originally about SNIHostName, do you
>>>>>>>>>>> need to
>>>>>>>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>>>>>>>
>>>>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more
>>>>>>>>>> than in
>>>>>>>>>> IDN. However, we may need to rethink about the comparing of two
>>>>>>>>>> IDN, for
>>>>>>>>>> example, "example.com." should equal to "example.com". I want to
>>>>>>>>>> consider it in another bug.
>>>>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent
>>>>>>>>> sets?
>>>>>>>>> And
>>>>>>>>> it's not one is another's subset?
>>>>>>>>>
>>>>>>>> Per TLS specification, host name in SNI is an IDN. The spec of
>>>>>>>> SNIHostname says, "hostname is not a valid Internationalized
>>>>>>>> Domain Name
>>>>>>>> (IDN) compliant with the RFC 3490 specification". The spec in
>>>>>>>> SNIHostName has the same means as IDN. I won't want to add
>>>>>>>> additional
>>>>>>>> restrict beyond the specification of an IDN.
>>>>>>>>
>>>>>>>> Xuelei
>>>>>>>>
>>>>>>>>>> Can I push the changeset?
>>>>>>>>> I think it's better to ask someone in the networking team to
>>>>>>>>> make the
>>>>>>>>> suggestion. From what I read Michael in this thread, he does
>>>>>>>>> not seem
>>>>>>>>> totally agreed with your code changes (at least not the 00
>>>>>>>>> version).
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Xuelei
>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Max
>>>>>>>>>>>
>>>>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>>>>>>>> Ping.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Xuelei
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>>>>>>>> Please review the new update:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>>>>>>>
>>>>>>>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for
>>>>>>>>>>>>> invalid
>>>>>>>>>>>>> IDN.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Xuelei
>>>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
From weijun.wang at oracle.com Sun Aug 11 23:07:08 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 12 Aug 2013 14:07:08 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52087668.9080500@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
<52087668.9080500@oracle.com>
Message-ID: <52087B8C.5080105@oracle.com>
On 8/12/13 1:45 PM, Xuelei Fan wrote:
> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
>
>> Lines 280 and 333: How about we call them steps 8a and 8b?
>
> Step 8 is referring to the steps in RFC 3490. Let's use "step 8".
You break the 1 <= len <= 63 check into two parts, that's why I say 8a
and 8b.
--Max
>
> Thanks,
> Xuelei
>
> On 8/12/2013 11:11 AM, Weijun Wang wrote:
>> I think the fix is adequate and necessary.
>>
>> One problem: lines 367-373 adds a new IAE to ToUnicode but the method
>> should not fail forever.
>>
>> And some small comments on styles etc.
>>
>> On 8/12/13 9:09 AM, Xuelei Fan wrote:
>>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/
>>
>> Lines 123 and 185:
>>
>> 184 p = q + 1;
>> 185 if (p < input.length() || q == (input.length() - 1)) {
>> 186 // has more labels, or keep the trailing dot as at
>> present
>> 187 out.append('.');
>> 188 }
>>
>> I prefer
>>
>> if (q < input.length()) { // Ah, a dot!
>> out.append('.');
>> }
>> p = q + 1;
>>
>> Lines 282, 335, 270: Insert a blank after "if".
>>
>> Lines 284 and 372: nslookup uses "empty label", which I like better.
>>
>> Lines 453 and 460: Personally I don't like the parenthesis for the whole
>> return value, but you have your choice.
>>
>> Lines 280 and 333: How about we call them steps 8a and 8b?
>>
>>>
>>> Added a new test to test illegal hostname in SNIHostName.
>>
>> Excellent. Otherwise I will be wondering why the fix in IDN could solve
>> the problem as described in the bug description.
>>
>> Thanks
>> Max
>>
>>>
>>> Xuelei
>>>
>>> On 8/10/2013 10:49 AM, Xuelei Fan wrote:
>>>> Hi Michael,
>>>>
>>>> It is pretty hard to get the issue solved in SNIHostName in a good
>>>> sharp. Here is my try to state why we should fix the issue in IDN.
>>>>
>>>> In SNIHostName, the following hostname are not accepted as valid
>>>> hostname:
>>>> 1. empty hostname
>>>> 2. hostname ends with a trailing dot
>>>> 3. hostname does not comply to RFC 3490.
>>>>
>>>> The process in SNIHostName looks like:
>>>> 1. call IDN.toASCII() to convert a string hostname
>>>> 2. check that the return value of #1 is an valid hostname (non-empty,
>>>> non-end-with-tailing-dot).
>>>>
>>>> At present, the IDN cannot handle the following IDN properly.
>>>> 1. returns "com" for "com."
>>>> the trailing dot is swallowed.
>>>>
>>>> 2. throws StringIndexOutOfBoundsException for "."
>>>> If "." is an valid IDN that comply to RFC 3490, IDN.toASCII()
>>>> should
>>>> be able to handle it; otherwise, IDN.toASCII() should throw IAE as the
>>>> specification suggested. However, IDN.toASCII(".") throws
>>>> StringIndexOutOfBoundsException, this behavior does not comply the the
>>>> specification:
>>>>
>>>> 3. throws StringIndexOutOfBoundsException for "example...net"
>>>> As #2.
>>>>
>>>> We can address #1 and #2 in SNIHostName, but the checking is overloaded
>>>> as IDN also need to address the issue. And SNIHostName has to know
>>>> what's the separators (".", "\u3002, etc) of IDN in order to check the
>>>> dot character. It is not a good encapsulation, and involved in too much
>>>> about the details of domain name, I think.
>>>>
>>>> It is a little big hard to address #3 in SNIHostName.
>>>>
>>>> Both all of above issue can be easily addressed in IDN. And once IDN
>>>> addressed these issues, the current SNIHostName is able to handle
>>>> invalid hostname (empty, trailing dot, etc) correctly. We won't need to
>>>> touch SNIHostName any more.
>>>>
>>>> Please consider it.
>>>>
>>>> The latest webrev is at:
>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 8/10/2013 9:13 AM, Xuelei Fan wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I plan to address this issue in SNIHostName. I have filled another two
>>>>> the potential bugs in IDN.
>>>>>
>>>>> Thank you, and other people, for the feedback.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>> On 8/9/2013 11:25 PM, Xuelei Fan wrote:
>>>>>> On 8/9/2013 7:31 PM, Michael McMahon wrote:
>>>>>>> I don't see how this fixes the original problem as the SNIHostName
>>>>>>> spec
>>>>>>> still doesn't like hostnames with a trailing '.'
>>>>>>>
>>>>>> The bug description did not reflect the IDN specification
>>>>>> correctly. If
>>>>>> "com." is a valid IDN, SNIHostName should accept it an an valid
>>>>>> hostname. The host name in SNIHostName is nothing more or less
>>>>>> than an
>>>>>> standard IDN.
>>>>>>
>>>>>> I added a comment in the bug: "com." and "." are valid IDN
>>>>>> according the
>>>>>> IDN and domain name specifications. I will contact the bug reporter
>>>>>> about this point.
>>>>>>
>>>>>> Xuelei
>>>>>>
>>>>>>> I'd prefer to check first where that requirement is coming from,
>>>>>>> if it is
>>>>>>> actually necessary, and if not consider removing it from SNIHostName.
>>>>>>> If it is necessary, then the check should be implemented in
>>>>>>> SNIHostName.
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>> On 09/08/13 05:28, Xuelei Fan wrote:
>>>>>>>> Thanks for your feedback and suggestions.
>>>>>>>>
>>>>>>>> Here is the new webrev:
>>>>>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
>>>>>>>>
>>>>>>>> "." is regarded as valid IDN in this update.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Xuelei
>>>>>>>>
>>>>>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote:
>>>>>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>>>>>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>>>>>>>>>>> I tried nslookup. Those with ".." inside are illegal,
>>>>>>>>>>>>
>>>>>>>>>>>> $ nslookup com..
>>>>>>>>>>>> nslookup: 'com..' is not a legal name (empty label)
>>>>>>>>>>>>
>>>>>>>>>>>> but
>>>>>>>>>>>>
>>>>>>>>>>>> $ nslookup .
>>>>>>>>>>>> Server: 192.168.10.1
>>>>>>>>>>>> Address: 192.168.10.1#53
>>>>>>>>>>>>
>>>>>>>>>>>> Non-authoritative answer:
>>>>>>>>>>>> *** Can't find .: No answer
>>>>>>>>>>>>
>>>>>>>>>>> Thanks for the testing. The behaviors are the same as this
>>>>>>>>>>> fix now.
>>>>>>>>>> No exactly. It seems nslookup still regards "." legal but just
>>>>>>>>>> cannot
>>>>>>>>>> find an IP for it.
>>>>>>>>>>
>>>>>>>>> I'm not sure whether a root domain name can be stand alone.
>>>>>>>>> Root label
>>>>>>>>> is not considered as a label in IDN. I think it is safe to
>>>>>>>>> regard that
>>>>>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a
>>>>>>>>> corner
>>>>>>>>> case.
>>>>>>>>>
>>>>>>>>> There are many online IDN conversion web services, some of them can
>>>>>>>>> convert ".", some of the cannot. In the present implementation, we
>>>>>>>>> cannot recognize ".", and IDN.toASCII(".") throws
>>>>>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering
>>>>>>>>> IAE is
>>>>>>>>> a better exception for IDN.toASCII(".").
>>>>>>>>>
>>>>>>>>>>> Learn something new today to use nslookup.
>>>>>>>>>>>
>>>>>>>>>>>> Also, since this bug was originally about SNIHostName, do you
>>>>>>>>>>>> need to
>>>>>>>>>>>> add some extra restriction there to reject "oracle.com." things?
>>>>>>>>>>>>
>>>>>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more
>>>>>>>>>>> than in
>>>>>>>>>>> IDN. However, we may need to rethink about the comparing of two
>>>>>>>>>>> IDN, for
>>>>>>>>>>> example, "example.com." should equal to "example.com". I want to
>>>>>>>>>>> consider it in another bug.
>>>>>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent
>>>>>>>>>> sets?
>>>>>>>>>> And
>>>>>>>>>> it's not one is another's subset?
>>>>>>>>>>
>>>>>>>>> Per TLS specification, host name in SNI is an IDN. The spec of
>>>>>>>>> SNIHostname says, "hostname is not a valid Internationalized
>>>>>>>>> Domain Name
>>>>>>>>> (IDN) compliant with the RFC 3490 specification". The spec in
>>>>>>>>> SNIHostName has the same means as IDN. I won't want to add
>>>>>>>>> additional
>>>>>>>>> restrict beyond the specification of an IDN.
>>>>>>>>>
>>>>>>>>> Xuelei
>>>>>>>>>
>>>>>>>>>>> Can I push the changeset?
>>>>>>>>>> I think it's better to ask someone in the networking team to
>>>>>>>>>> make the
>>>>>>>>>> suggestion. From what I read Michael in this thread, he does
>>>>>>>>>> not seem
>>>>>>>>>> totally agreed with your code changes (at least not the 00
>>>>>>>>>> version).
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Max
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Xuelei
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Max
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>>>>>>>>>>>>> Ping.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Xuelei
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>>>>>>>>>>>>> Please review the new update:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With this update, "com." is valid (return "com."); "." and
>>>>>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for
>>>>>>>>>>>>>> invalid
>>>>>>>>>>>>>> IDN.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Xuelei
>>>>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
From ivan.gerasimov at oracle.com Mon Aug 12 05:33:48 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 12 Aug 2013 16:33:48 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5204DE28.5090805@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
<5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com>
<5204DE28.5090805@oracle.com>
Message-ID: <5208D62C.3030107@oracle.com>
David, Chris,
I reverted back NULL-checking.
Now the change consists of one line removal and a regression test.
Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/
Hg export:
http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
Sincerely yours,
Ivan
On 09.08.2013 16:18, David Holmes wrote:
> Hi Chris,
>
> On 9/08/2013 8:36 PM, Chris Hegarty wrote:
>> Firstly, I think the memory leak issue should be moved forward
>> separately to this cleanup effort. They are unrelated, and I'm starting
>> to get the feeling that this could take some time to reach conclusion.
>> It seems reasonable to separate the issues.
>
> I agree. I'm sure when Alan suggested to check the return he didn't
> expect it to unravel like this :) As we know hotspot will never
> actually return NULL there is no urgency to add this in.
>
>> On 09/08/2013 10:27, Ivan Gerasimov wrote:
>>> Chris,
>>>
>>> I would use this
>>>
>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>> NULL) {
>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
>>> return NULL/JNI_False/-1;
>>> }
>>>
>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
>>> exception only if it hasn't been already thrown.
>>
>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for
>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg);
>>
>> ...and JNU_ThrowByName [1] is defined as...
>>
>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) {
>> class cls = (*env)->FindClass(env, name);
>> if (cls != 0) /* Otherwise an exception has already been thrown */
>> (*env)->ThrowNew(env, cls, msg);
>> }
>> }
>>
>> Neither FindClass or ThrowNew is safe to call if there is a pending
>> exception [1].
>
> Right - we have to check for a pending exception before trying to
> throw one.
>
>> Now the issue comes down to; could there ever be a pending exception if
>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that
>> there could be, but every copy of "The Java Native Interface
>> Programmer's Guide and Specification" I can find does. There also
>> appears to be an assumption of this if you look at the usages in the
>> JDK.
>
> AFAIK there is only one version of the JNI spec book and it never got
> updated. The official spec says no throw, but when people have the
> book on their bookshelf that is what they tend to rely on. I looked at
> some of the usages and they seem exception agnostic - many of them
> don't even check for NULL :(
>
> The implementation as it stands will not throw and will not return NULL.
>
>> I would really like to get a definitive answer on the JNI specification
>> for GetStringUTFChars before making any changes here.
>
> The JNI spec (as opposed to the book) is definitive. If we don't like
> what is there then it requires a spec change.
>
> I can't find any reference to this particular issue being raised before.
>
> Cheers,
> David
>
>> -Chris.
>>
>> [1]
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c
>>
>>
>> [2]
>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626
>>
>>
>>
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>> On 09.08.2013 11:25, Chris Hegarty wrote:
>>>> On 09/08/2013 06:47, David Holmes wrote:
>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will
>>>>> return
>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not
>>>>> - it
>>>>> only says it will return NULL on failure.
>>>>
>>>> This is indeed strange. Most usages of this function in the jdk expect
>>>> the former. If this is not the case, then we may need to do an audit
>>>> of all usages.
>>>>
>>>>> So your previous version was the more correct. Given we just
>>>>> failed to
>>>>> allocate C-heap I think we are on thin ice anyway, but better to at
>>>>> least attempt to do the right thing.
>>>>
>>>> I'm not sure what the right thing to do here is? It seems a little
>>>> unwieldy!
>>>>
>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>> NULL) {
>>>> if ((*env)->ExceptionOccurred(env)) {
>>>> return NULL/JNI_False/-1;
>>>> } else {
>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars
>>>> failed");
>>>> return NULL/JNI_False/-1;
>>>> }
>>>>
>>>> Given we have no idea why GetStringUTFChars may have failed, what
>>>> exception do we throw?
>>>>
>>>> Also worth noting is that this bug fix has moved away from the
>>>> original problem (memory leak), and is now focused on code cleanup.
>>>>
>>>> If we cannot get agreement on the cleanup, or it looks like more
>>>> clarification is needed around the cleanup effort, then I would like
>>>> to suggest that we proceed with the original fix for the memory leak
>>>> and separate out the cleanup effort.
>>>>
>>>> -Chris.
>>>>
>>>>> FYI I filed 8022683 to fix GetStringUTFChars.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>>>>> Thumbs up!
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>>>>> Thanks David!
>>>>>>>
>>>>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>>>>> Main fix looks good to me.
>>>>>>>>
>>>>>>>> Regression test may need some tweaking eg I think othervm will be
>>>>>>>> needed.
>>>>>>>>
>>>>>>> Yes, it's a good point.
>>>>>>> Since there may be a memory leak in the test, it'd better not
>>>>>>> interfere
>>>>>>> with other tests in jtreg.
>>>>>>>
>>>>>>>> Also this:
>>>>>>>>
>>>>>>>> System.out.println("WARNING: Cannot perform memory leak
>>>>>>>> detection on
>>>>>>>> this OS");
>>>>>>>>
>>>>>>>> should probably just say something like "Test skipped on this
>>>>>>>> OS" -
>>>>>>>> there are other tests that do this so just check if there is
>>>>>>>> common
>>>>>>>> terminology. (In the future we may have keyword tags to flag
>>>>>>>> this as
>>>>>>>> linux only etc.)
>>>>>>>>
>>>>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>>>>
>>>>>>> Updated webrev is here:
>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>>>>
>>>>>>> Updated export is at the same place:
>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>>>>>> fix.
>>>>>>>>>
>>>>>>>>> Here's webrev that includes the test:
>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>>>>
>>>>>>>>> The test gets past with the fixed jdk8 and fails with
>>>>>>>>> jdk8-b101 and
>>>>>>>>> jdk7
>>>>>>>>> as expected.
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>>>>
>>>>>>>>>> -Chris.
>>>>>>>>>>
>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>>>>> Hello Chris!
>>>>>>>>>>>
>>>>>>>>>>> Here's the update:
>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>>>>
>>>>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>>>>> Here's the hg-export
>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>> Ivan
>>>>>>>>>>>
>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>>>>
>>>>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>>>>> Alan (
>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>>>>> GetStringUTFChars
>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>>>>>> jdk8
>>>>>>>>>>>> for
>>>>>>>>>>>> you.
>>>>>>>>>>>>
>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>>>>
>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>> David, Alan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I added checking for NULL results and throwing
>>>>>>>>>>>>>> OOMException if
>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>>>>
>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned
>>>>>>>>>>>>> then an
>>>>>>>>>>>>> OOME
>>>>>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>>>>>> native
>>>>>>>>>>>>> code
>>>>>>>>>>>>> returns to Java.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>>>>> indentation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>>>>> For allocation of the result string it calls
>>>>>>>>>>>>>>>> AllocateHeap()
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>>>>>> stops
>>>>>>>>>>>>>>>> VM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is
>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the
>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to
>>>>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not
>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>
>
From chris.hegarty at oracle.com Mon Aug 12 05:43:09 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 12 Aug 2013 13:43:09 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5208D62C.3030107@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
<5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com>
<5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com>
Message-ID: <5208D85D.1090606@oracle.com>
Thank you Ivan. This looks good to me.
-Chris.
P.S. I will give others a chance to comment. If no objections, I will
push this tomorrow for you.
On 12/08/2013 13:33, Ivan Gerasimov wrote:
> David, Chris,
>
> I reverted back NULL-checking.
> Now the change consists of one line removal and a regression test.
>
> Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/
> Hg export:
> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>
>
> Sincerely yours,
> Ivan
>
> On 09.08.2013 16:18, David Holmes wrote:
>> Hi Chris,
>>
>> On 9/08/2013 8:36 PM, Chris Hegarty wrote:
>>> Firstly, I think the memory leak issue should be moved forward
>>> separately to this cleanup effort. They are unrelated, and I'm starting
>>> to get the feeling that this could take some time to reach conclusion.
>>> It seems reasonable to separate the issues.
>>
>> I agree. I'm sure when Alan suggested to check the return he didn't
>> expect it to unravel like this :) As we know hotspot will never
>> actually return NULL there is no urgency to add this in.
>>
>>> On 09/08/2013 10:27, Ivan Gerasimov wrote:
>>>> Chris,
>>>>
>>>> I would use this
>>>>
>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>> NULL) {
>>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
>>>> return NULL/JNI_False/-1;
>>>> }
>>>>
>>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
>>>> exception only if it hasn't been already thrown.
>>>
>>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for
>>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg);
>>>
>>> ...and JNU_ThrowByName [1] is defined as...
>>>
>>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) {
>>> class cls = (*env)->FindClass(env, name);
>>> if (cls != 0) /* Otherwise an exception has already been thrown */
>>> (*env)->ThrowNew(env, cls, msg);
>>> }
>>> }
>>>
>>> Neither FindClass or ThrowNew is safe to call if there is a pending
>>> exception [1].
>>
>> Right - we have to check for a pending exception before trying to
>> throw one.
>>
>>> Now the issue comes down to; could there ever be a pending exception if
>>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that
>>> there could be, but every copy of "The Java Native Interface
>>> Programmer's Guide and Specification" I can find does. There also
>>> appears to be an assumption of this if you look at the usages in the
>>> JDK.
>>
>> AFAIK there is only one version of the JNI spec book and it never got
>> updated. The official spec says no throw, but when people have the
>> book on their bookshelf that is what they tend to rely on. I looked at
>> some of the usages and they seem exception agnostic - many of them
>> don't even check for NULL :(
>>
>> The implementation as it stands will not throw and will not return NULL.
>>
>>> I would really like to get a definitive answer on the JNI specification
>>> for GetStringUTFChars before making any changes here.
>>
>> The JNI spec (as opposed to the book) is definitive. If we don't like
>> what is there then it requires a spec change.
>>
>> I can't find any reference to this particular issue being raised before.
>>
>> Cheers,
>> David
>>
>>> -Chris.
>>>
>>> [1]
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c
>>>
>>>
>>> [2]
>>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626
>>>
>>>
>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>> On 09.08.2013 11:25, Chris Hegarty wrote:
>>>>> On 09/08/2013 06:47, David Holmes wrote:
>>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will
>>>>>> return
>>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not
>>>>>> - it
>>>>>> only says it will return NULL on failure.
>>>>>
>>>>> This is indeed strange. Most usages of this function in the jdk expect
>>>>> the former. If this is not the case, then we may need to do an audit
>>>>> of all usages.
>>>>>
>>>>>> So your previous version was the more correct. Given we just
>>>>>> failed to
>>>>>> allocate C-heap I think we are on thin ice anyway, but better to at
>>>>>> least attempt to do the right thing.
>>>>>
>>>>> I'm not sure what the right thing to do here is? It seems a little
>>>>> unwieldy!
>>>>>
>>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>>> NULL) {
>>>>> if ((*env)->ExceptionOccurred(env)) {
>>>>> return NULL/JNI_False/-1;
>>>>> } else {
>>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars
>>>>> failed");
>>>>> return NULL/JNI_False/-1;
>>>>> }
>>>>>
>>>>> Given we have no idea why GetStringUTFChars may have failed, what
>>>>> exception do we throw?
>>>>>
>>>>> Also worth noting is that this bug fix has moved away from the
>>>>> original problem (memory leak), and is now focused on code cleanup.
>>>>>
>>>>> If we cannot get agreement on the cleanup, or it looks like more
>>>>> clarification is needed around the cleanup effort, then I would like
>>>>> to suggest that we proceed with the original fix for the memory leak
>>>>> and separate out the cleanup effort.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> FYI I filed 8022683 to fix GetStringUTFChars.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>>>>>> Thumbs up!
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>>>>>> Thanks David!
>>>>>>>>
>>>>>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>>>>>> Main fix looks good to me.
>>>>>>>>>
>>>>>>>>> Regression test may need some tweaking eg I think othervm will be
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>> Yes, it's a good point.
>>>>>>>> Since there may be a memory leak in the test, it'd better not
>>>>>>>> interfere
>>>>>>>> with other tests in jtreg.
>>>>>>>>
>>>>>>>>> Also this:
>>>>>>>>>
>>>>>>>>> System.out.println("WARNING: Cannot perform memory leak
>>>>>>>>> detection on
>>>>>>>>> this OS");
>>>>>>>>>
>>>>>>>>> should probably just say something like "Test skipped on this
>>>>>>>>> OS" -
>>>>>>>>> there are other tests that do this so just check if there is
>>>>>>>>> common
>>>>>>>>> terminology. (In the future we may have keyword tags to flag
>>>>>>>>> this as
>>>>>>>>> linux only etc.)
>>>>>>>>>
>>>>>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>>>>>
>>>>>>>> Updated webrev is here:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>>>>>
>>>>>>>> Updated export is at the same place:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>>>>>>> fix.
>>>>>>>>>>
>>>>>>>>>> Here's webrev that includes the test:
>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>>>>>
>>>>>>>>>> The test gets past with the fixed jdk8 and fails with
>>>>>>>>>> jdk8-b101 and
>>>>>>>>>> jdk7
>>>>>>>>>> as expected.
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>>>>>
>>>>>>>>>>> -Chris.
>>>>>>>>>>>
>>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>> Hello Chris!
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the update:
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>>>>>> Here's the hg-export
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>>>>>> Alan (
>>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>>>>>> GetStringUTFChars
>>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>>>>>>> jdk8
>>>>>>>>>>>>> for
>>>>>>>>>>>>> you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>> David, Alan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added checking for NULL results and throwing
>>>>>>>>>>>>>>> OOMException if
>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned
>>>>>>>>>>>>>> then an
>>>>>>>>>>>>>> OOME
>>>>>>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>>>>>>> native
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> returns to Java.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>>>>>> indentation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>>>>>> For allocation of the result string it calls
>>>>>>>>>>>>>>>>> AllocateHeap()
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>>>>>>> stops
>>>>>>>>>>>>>>>>> VM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is
>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the
>>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to
>>>>>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not
>>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
From ivan.gerasimov at oracle.com Mon Aug 12 05:44:26 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 12 Aug 2013 16:44:26 +0400
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5208D85D.1090606@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
<5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com>
<5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com>
<5208D85D.1090606@oracle.com>
Message-ID: <5208D8AA.5090302@oracle.com>
Thank you Chris!
On 12.08.2013 16:43, Chris Hegarty wrote:
> Thank you Ivan. This looks good to me.
>
> -Chris.
>
> P.S. I will give others a chance to comment. If no objections, I will
> push this tomorrow for you.
>
> On 12/08/2013 13:33, Ivan Gerasimov wrote:
>> David, Chris,
>>
>> I reverted back NULL-checking.
>> Now the change consists of one line removal and a regression test.
>>
>> Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/
>> Hg export:
>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>
>>
>>
>> Sincerely yours,
>> Ivan
>>
>> On 09.08.2013 16:18, David Holmes wrote:
>>> Hi Chris,
>>>
>>> On 9/08/2013 8:36 PM, Chris Hegarty wrote:
>>>> Firstly, I think the memory leak issue should be moved forward
>>>> separately to this cleanup effort. They are unrelated, and I'm
>>>> starting
>>>> to get the feeling that this could take some time to reach conclusion.
>>>> It seems reasonable to separate the issues.
>>>
>>> I agree. I'm sure when Alan suggested to check the return he didn't
>>> expect it to unravel like this :) As we know hotspot will never
>>> actually return NULL there is no urgency to add this in.
>>>
>>>> On 09/08/2013 10:27, Ivan Gerasimov wrote:
>>>>> Chris,
>>>>>
>>>>> I would use this
>>>>>
>>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>>> NULL) {
>>>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
>>>>> return NULL/JNI_False/-1;
>>>>> }
>>>>>
>>>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
>>>>> exception only if it hasn't been already thrown.
>>>>
>>>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for
>>>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg);
>>>>
>>>> ...and JNU_ThrowByName [1] is defined as...
>>>>
>>>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) {
>>>> class cls = (*env)->FindClass(env, name);
>>>> if (cls != 0) /* Otherwise an exception has already been thrown */
>>>> (*env)->ThrowNew(env, cls, msg);
>>>> }
>>>> }
>>>>
>>>> Neither FindClass or ThrowNew is safe to call if there is a pending
>>>> exception [1].
>>>
>>> Right - we have to check for a pending exception before trying to
>>> throw one.
>>>
>>>> Now the issue comes down to; could there ever be a pending
>>>> exception if
>>>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that
>>>> there could be, but every copy of "The Java Native Interface
>>>> Programmer's Guide and Specification" I can find does. There also
>>>> appears to be an assumption of this if you look at the usages in the
>>>> JDK.
>>>
>>> AFAIK there is only one version of the JNI spec book and it never got
>>> updated. The official spec says no throw, but when people have the
>>> book on their bookshelf that is what they tend to rely on. I looked at
>>> some of the usages and they seem exception agnostic - many of them
>>> don't even check for NULL :(
>>>
>>> The implementation as it stands will not throw and will not return
>>> NULL.
>>>
>>>> I would really like to get a definitive answer on the JNI
>>>> specification
>>>> for GetStringUTFChars before making any changes here.
>>>
>>> The JNI spec (as opposed to the book) is definitive. If we don't like
>>> what is there then it requires a spec change.
>>>
>>> I can't find any reference to this particular issue being raised
>>> before.
>>>
>>> Cheers,
>>> David
>>>
>>>> -Chris.
>>>>
>>>> [1]
>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c
>>>>
>>>>
>>>>
>>>> [2]
>>>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>>
>>>>> On 09.08.2013 11:25, Chris Hegarty wrote:
>>>>>> On 09/08/2013 06:47, David Holmes wrote:
>>>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will
>>>>>>> return
>>>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not
>>>>>>> - it
>>>>>>> only says it will return NULL on failure.
>>>>>>
>>>>>> This is indeed strange. Most usages of this function in the jdk
>>>>>> expect
>>>>>> the former. If this is not the case, then we may need to do an audit
>>>>>> of all usages.
>>>>>>
>>>>>>> So your previous version was the more correct. Given we just
>>>>>>> failed to
>>>>>>> allocate C-heap I think we are on thin ice anyway, but better to at
>>>>>>> least attempt to do the right thing.
>>>>>>
>>>>>> I'm not sure what the right thing to do here is? It seems a little
>>>>>> unwieldy!
>>>>>>
>>>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>>>> NULL) {
>>>>>> if ((*env)->ExceptionOccurred(env)) {
>>>>>> return NULL/JNI_False/-1;
>>>>>> } else {
>>>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars
>>>>>> failed");
>>>>>> return NULL/JNI_False/-1;
>>>>>> }
>>>>>>
>>>>>> Given we have no idea why GetStringUTFChars may have failed, what
>>>>>> exception do we throw?
>>>>>>
>>>>>> Also worth noting is that this bug fix has moved away from the
>>>>>> original problem (memory leak), and is now focused on code cleanup.
>>>>>>
>>>>>> If we cannot get agreement on the cleanup, or it looks like more
>>>>>> clarification is needed around the cleanup effort, then I would like
>>>>>> to suggest that we proceed with the original fix for the memory leak
>>>>>> and separate out the cleanup effort.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>>> FYI I filed 8022683 to fix GetStringUTFChars.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>>>>>>> Thumbs up!
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>>>>>>> Thanks David!
>>>>>>>>>
>>>>>>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>>>>>>> Main fix looks good to me.
>>>>>>>>>>
>>>>>>>>>> Regression test may need some tweaking eg I think othervm
>>>>>>>>>> will be
>>>>>>>>>> needed.
>>>>>>>>>>
>>>>>>>>> Yes, it's a good point.
>>>>>>>>> Since there may be a memory leak in the test, it'd better not
>>>>>>>>> interfere
>>>>>>>>> with other tests in jtreg.
>>>>>>>>>
>>>>>>>>>> Also this:
>>>>>>>>>>
>>>>>>>>>> System.out.println("WARNING: Cannot perform memory leak
>>>>>>>>>> detection on
>>>>>>>>>> this OS");
>>>>>>>>>>
>>>>>>>>>> should probably just say something like "Test skipped on this
>>>>>>>>>> OS" -
>>>>>>>>>> there are other tests that do this so just check if there is
>>>>>>>>>> common
>>>>>>>>>> terminology. (In the future we may have keyword tags to flag
>>>>>>>>>> this as
>>>>>>>>>> linux only etc.)
>>>>>>>>>>
>>>>>>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>>>>>>
>>>>>>>>> Updated webrev is here:
>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>>>>>>
>>>>>>>>> Updated export is at the same place:
>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest
>>>>>>>>>>> in the
>>>>>>>>>>> fix.
>>>>>>>>>>>
>>>>>>>>>>> Here's webrev that includes the test:
>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>>>>>>
>>>>>>>>>>> The test gets past with the fixed jdk8 and fails with
>>>>>>>>>>> jdk8-b101 and
>>>>>>>>>>> jdk7
>>>>>>>>>>> as expected.
>>>>>>>>>>>
>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>> Ivan
>>>>>>>>>>>
>>>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>>>>>>
>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>>> Hello Chris!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's the update:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>>>>>>> Here's the hg-export
>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>>>>>>> Alan (
>>>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>>>>>>> GetStringUTFChars
>>>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>>>>>>>> jdk8
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>> David, Alan,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I added checking for NULL results and throwing
>>>>>>>>>>>>>>>> OOMException if
>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned
>>>>>>>>>>>>>>> then an
>>>>>>>>>>>>>>> OOME
>>>>>>>>>>>>>>> should already be pending and will be thrown as soon as
>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>> native
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> returns to Java.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>>>>>>> indentation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I've checked that and it turns out that
>>>>>>>>>>>>>>>>>> GetStringUTFChars
>>>>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>>>>>>> For allocation of the result string it calls
>>>>>>>>>>>>>>>>>> AllocateHeap()
>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it
>>>>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>>>>> stops
>>>>>>>>>>>>>>>>>> VM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is
>>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort
>>>>>>>>>>>>>>>>> the VM!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the
>>>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were
>>>>>>>>>>>>>>>>>>>> reported to
>>>>>>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584
>>>>>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
>
From sean.mullan at oracle.com Mon Aug 12 06:54:59 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 12 Aug 2013 13:54:59 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130812135553.CEA46487BD@hg.openjdk.java.net>
Changeset: ffacf3e7a130
Author: mullan
Date: 2013-08-12 09:03 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffacf3e7a130
8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles
Summary: Change the default value of the "login.configuration.provider" security property to sun.security.provider.ConfigFile
Reviewed-by: xuelei
! src/share/classes/com/sun/security/auth/login/ConfigFile.java
! src/share/classes/javax/security/auth/login/Configuration.java
+ src/share/classes/sun/security/provider/ConfigFile.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
Changeset: d73fbf005f5f
Author: mullan
Date: 2013-08-12 09:29 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d73fbf005f5f
Merge
- src/share/classes/java/net/package.html
- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
From maurizio.cimadamore at oracle.com Mon Aug 12 09:29:08 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 12 Aug 2013 16:29:08 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20130812162917.4FA16487C5@hg.openjdk.java.net>
Changeset: f7f271bd74a2
Author: mcimadamore
Date: 2013-08-12 17:25 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f7f271bd74a2
6537020: JCK tests: a compile-time error should be given in case of ambiguously imported fields (types, methods)
Summary: Hiding check does not support interface multiple inheritance
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/tools/javac/4980495/static/Test.out
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java
! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java
+ test/tools/javac/staticImport/6537020/T6537020.java
+ test/tools/javac/staticImport/6537020/T6537020.out
Changeset: af80273f630a
Author: mcimadamore
Date: 2013-08-12 17:28 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/af80273f630a
8021567: Javac doesn't report \"java: reference to method is ambiguous\" any more
Summary: Javac incorrectly forgets about constant folding results within lambdas
Reviewed-by: jjg, vromero
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/8021567/T8021567.java
+ test/tools/javac/lambda/8021567/T8021567.out
+ test/tools/javac/lambda/8021567/T8021567b.java
From Alan.Bateman at oracle.com Mon Aug 12 09:32:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Aug 2013 17:32:37 +0100
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5204DE28.5090805@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
<5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com>
<5204DE28.5090805@oracle.com>
Message-ID: <52090E25.6050300@oracle.com>
On 09/08/2013 13:18, David Holmes wrote:
>
> I agree. I'm sure when Alan suggested to check the return he didn't
> expect it to unravel like this :) As we know hotspot will never
> actually return NULL there is no urgency to add this in.
Sorry about this, I wasn't aware of the issue in the JNI spec, we should
follow up on that.
Ivan's latest webrev (which limits the change to just removing the
GetStringUTFChars is fine). The test is okay but it might need time to
bed down.
-Alan
From vicente.romero at oracle.com Mon Aug 12 09:41:24 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Mon, 12 Aug 2013 16:41:24 +0000
Subject: hg: jdk8/tl/jdk: 8015780:
java/lang/reflect/Method/GenericStringTest.java failing
Message-ID: <20130812164149.C5B8B487C9@hg.openjdk.java.net>
Changeset: 70c8f4a4b8d6
Author: vromero
Date: 2013-08-12 17:40 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70c8f4a4b8d6
8015780: java/lang/reflect/Method/GenericStringTest.java failing
Reviewed-by: darcy, jfranck
! test/ProblemList.txt
! test/java/lang/reflect/Method/GenericStringTest.java
From lance.andersen at oracle.com Mon Aug 12 13:09:57 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Mon, 12 Aug 2013 20:09:57 +0000
Subject: hg: jdk8/tl/jdk: 8022753: SQLXML javadoc example typo
Message-ID: <20130812201011.0221F487E1@hg.openjdk.java.net>
Changeset: cc64a05836a7
Author: lancea
Date: 2013-08-12 16:09 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc64a05836a7
8022753: SQLXML javadoc example typo
Reviewed-by: alanb, mchung
! src/share/classes/java/sql/SQLXML.java
From david.holmes at oracle.com Mon Aug 12 22:33:04 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Aug 2013 15:33:04 +1000
Subject: RFR [8022584] Memory leak in some NetworkInterface methods
In-Reply-To: <5208D62C.3030107@oracle.com>
References: <5202EA83.70207@oracle.com>
<5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com>
<5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com>
<52032625.3000501@oracle.com> <52035A18.8020803@oracle.com>
<52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com>
<5203E642.40005@oracle.com> <52040A76.3060602@oracle.com>
<52041988.80705@oracle.com> <52047C66.2080001@oracle.com>
<52048269.7000501@oracle.com> <5204997B.3090601@oracle.com>
<5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com>
<5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com>
Message-ID: <5209C510.5000001@oracle.com>
Thanks Ivan.
David
On 12/08/2013 10:33 PM, Ivan Gerasimov wrote:
> David, Chris,
>
> I reverted back NULL-checking.
> Now the change consists of one line removal and a regression test.
>
> Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/
> Hg export:
> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>
>
> Sincerely yours,
> Ivan
>
> On 09.08.2013 16:18, David Holmes wrote:
>> Hi Chris,
>>
>> On 9/08/2013 8:36 PM, Chris Hegarty wrote:
>>> Firstly, I think the memory leak issue should be moved forward
>>> separately to this cleanup effort. They are unrelated, and I'm starting
>>> to get the feeling that this could take some time to reach conclusion.
>>> It seems reasonable to separate the issues.
>>
>> I agree. I'm sure when Alan suggested to check the return he didn't
>> expect it to unravel like this :) As we know hotspot will never
>> actually return NULL there is no urgency to add this in.
>>
>>> On 09/08/2013 10:27, Ivan Gerasimov wrote:
>>>> Chris,
>>>>
>>>> I would use this
>>>>
>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>> NULL) {
>>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed");
>>>> return NULL/JNI_False/-1;
>>>> }
>>>>
>>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an
>>>> exception only if it hasn't been already thrown.
>>>
>>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for
>>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg);
>>>
>>> ...and JNU_ThrowByName [1] is defined as...
>>>
>>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) {
>>> class cls = (*env)->FindClass(env, name);
>>> if (cls != 0) /* Otherwise an exception has already been thrown */
>>> (*env)->ThrowNew(env, cls, msg);
>>> }
>>> }
>>>
>>> Neither FindClass or ThrowNew is safe to call if there is a pending
>>> exception [1].
>>
>> Right - we have to check for a pending exception before trying to
>> throw one.
>>
>>> Now the issue comes down to; could there ever be a pending exception if
>>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that
>>> there could be, but every copy of "The Java Native Interface
>>> Programmer's Guide and Specification" I can find does. There also
>>> appears to be an assumption of this if you look at the usages in the
>>> JDK.
>>
>> AFAIK there is only one version of the JNI spec book and it never got
>> updated. The official spec says no throw, but when people have the
>> book on their bookshelf that is what they tend to rely on. I looked at
>> some of the usages and they seem exception agnostic - many of them
>> don't even check for NULL :(
>>
>> The implementation as it stands will not throw and will not return NULL.
>>
>>> I would really like to get a definitive answer on the JNI specification
>>> for GetStringUTFChars before making any changes here.
>>
>> The JNI spec (as opposed to the book) is definitive. If we don't like
>> what is there then it requires a spec change.
>>
>> I can't find any reference to this particular issue being raised before.
>>
>> Cheers,
>> David
>>
>>> -Chris.
>>>
>>> [1]
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c
>>>
>>>
>>> [2]
>>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626
>>>
>>>
>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>> On 09.08.2013 11:25, Chris Hegarty wrote:
>>>>> On 09/08/2013 06:47, David Holmes wrote:
>>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will
>>>>>> return
>>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not
>>>>>> - it
>>>>>> only says it will return NULL on failure.
>>>>>
>>>>> This is indeed strange. Most usages of this function in the jdk expect
>>>>> the former. If this is not the case, then we may need to do an audit
>>>>> of all usages.
>>>>>
>>>>>> So your previous version was the more correct. Given we just
>>>>>> failed to
>>>>>> allocate C-heap I think we are on thin ice anyway, but better to at
>>>>>> least attempt to do the right thing.
>>>>>
>>>>> I'm not sure what the right thing to do here is? It seems a little
>>>>> unwieldy!
>>>>>
>>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) ==
>>>>> NULL) {
>>>>> if ((*env)->ExceptionOccurred(env)) {
>>>>> return NULL/JNI_False/-1;
>>>>> } else {
>>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars
>>>>> failed");
>>>>> return NULL/JNI_False/-1;
>>>>> }
>>>>>
>>>>> Given we have no idea why GetStringUTFChars may have failed, what
>>>>> exception do we throw?
>>>>>
>>>>> Also worth noting is that this bug fix has moved away from the
>>>>> original problem (memory leak), and is now focused on code cleanup.
>>>>>
>>>>> If we cannot get agreement on the cleanup, or it looks like more
>>>>> clarification is needed around the cleanup effort, then I would like
>>>>> to suggest that we proceed with the original fix for the memory leak
>>>>> and separate out the cleanup effort.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> FYI I filed 8022683 to fix GetStringUTFChars.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 9/08/2013 3:21 PM, David Holmes wrote:
>>>>>>> Thumbs up!
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote:
>>>>>>>> Thanks David!
>>>>>>>>
>>>>>>>> On 09.08.2013 1:15, David Holmes wrote:
>>>>>>>>> Main fix looks good to me.
>>>>>>>>>
>>>>>>>>> Regression test may need some tweaking eg I think othervm will be
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>> Yes, it's a good point.
>>>>>>>> Since there may be a memory leak in the test, it'd better not
>>>>>>>> interfere
>>>>>>>> with other tests in jtreg.
>>>>>>>>
>>>>>>>>> Also this:
>>>>>>>>>
>>>>>>>>> System.out.println("WARNING: Cannot perform memory leak
>>>>>>>>> detection on
>>>>>>>>> this OS");
>>>>>>>>>
>>>>>>>>> should probably just say something like "Test skipped on this
>>>>>>>>> OS" -
>>>>>>>>> there are other tests that do this so just check if there is
>>>>>>>>> common
>>>>>>>>> terminology. (In the future we may have keyword tags to flag
>>>>>>>>> this as
>>>>>>>>> linux only etc.)
>>>>>>>>>
>>>>>>>> OK, I changed the phrase to "Test only runs on Linux".
>>>>>>>>
>>>>>>>> Updated webrev is here:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/
>>>>>>>>
>>>>>>>> Updated export is at the same place:
>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote:
>>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the
>>>>>>>>>> fix.
>>>>>>>>>>
>>>>>>>>>> Here's webrev that includes the test:
>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/
>>>>>>>>>>
>>>>>>>>>> The test gets past with the fixed jdk8 and fails with
>>>>>>>>>> jdk8-b101 and
>>>>>>>>>> jdk7
>>>>>>>>>> as expected.
>>>>>>>>>>
>>>>>>>>>> Sincerely yours,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote:
>>>>>>>>>>> Looks good to me. Thanks Ivan.
>>>>>>>>>>>
>>>>>>>>>>> -Chris.
>>>>>>>>>>>
>>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>> Hello Chris!
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the update:
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for offering the sponsorship!
>>>>>>>>>>>> Here's the hg-export
>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>> Ivan
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote:
>>>>>>>>>>>>> Thanks for taking this Ivan.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you please make the changes suggested by both David and
>>>>>>>>>>>>> Alan (
>>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if
>>>>>>>>>>>>> GetStringUTFChars
>>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into
>>>>>>>>>>>>> jdk8
>>>>>>>>>>>>> for
>>>>>>>>>>>>> you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Chris.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote:
>>>>>>>>>>>>>> Ivan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>> David, Alan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added checking for NULL results and throwing
>>>>>>>>>>>>>>> OOMException if
>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You don't need to throw it yourself:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned
>>>>>>>>>>>>>> then an
>>>>>>>>>>>>>> OOME
>>>>>>>>>>>>>> should already be pending and will be thrown as soon as your
>>>>>>>>>>>>>> native
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> returns to Java.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've also added some spaces along the code to improve
>>>>>>>>>>>>>>> indentation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would you please review the updated webrev?
>>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote:
>>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>> Thanks Alan!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars
>>>>>>>>>>>>>>>>> cannot
>>>>>>>>>>>>>>>>> return
>>>>>>>>>>>>>>>>> NULL.
>>>>>>>>>>>>>>>>> For allocation of the result string it calls
>>>>>>>>>>>>>>>>> AllocateHeap()
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy.
>>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply
>>>>>>>>>>>>>>>>> stops
>>>>>>>>>>>>>>>>> VM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is
>>>>>>>>>>>>>>>> supposed to
>>>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending
>>>>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote:
>>>>>>>>>>>>>>>>>> (cc'ing net-dev).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> there) is
>>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the
>>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>>> when it fails with NULL.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Alan.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote:
>>>>>>>>>>>>>>>>>>> Hello everybody!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to
>>>>>>>>>>>>>>>>>>> leak
>>>>>>>>>>>>>>>>>>> memory.
>>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not
>>>>>>>>>>>>>>>>>>> yet
>>>>>>>>>>>>>>>>>>> available.)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback().
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the
>>>>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>>>>> allocation?
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sincerely yours,
>>>>>>>>>>>>>>>>>>> Ivan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
From xuelei.fan at oracle.com Tue Aug 13 01:29:32 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 13 Aug 2013 16:29:32 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <52087B8C.5080105@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
<52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com>
Message-ID: <5209EE6C.3050604@oracle.com>
Can I get an additional code review from networking team?
Thanks,
Xuelei
On 8/12/2013 2:07 PM, Weijun Wang wrote:
> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
From sean.mullan at oracle.com Tue Aug 13 06:05:47 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 13 Aug 2013 13:05:47 +0000
Subject: hg: jdk8/tl/jdk: 8020081: Cipher with OAEPPadding and
OAEPParameterSpec can't be created
Message-ID: <20130813130623.337D448806@hg.openjdk.java.net>
Changeset: 5b14d702b0b8
Author: ascarpino
Date: 2013-08-12 11:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b14d702b0b8
8020081: Cipher with OAEPPadding and OAEPParameterSpec can't be created
Reviewed-by: mullan
! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java
From vincent.x.ryan at oracle.com Tue Aug 13 06:19:13 2013
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Tue, 13 Aug 2013 13:19:13 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130813131940.272B248807@hg.openjdk.java.net>
Changeset: 818c3f82269c
Author: vinnie
Date: 2013-08-13 14:15 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/818c3f82269c
8013170: Spec for PBEParameterSpec does not specify behavior when paramSpec is null
Reviewed-by: mullan
! src/share/classes/javax/crypto/spec/PBEParameterSpec.java
Changeset: 26753a05859a
Author: vinnie
Date: 2013-08-13 14:18 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26753a05859a
Merge
From alan.bateman at oracle.com Tue Aug 13 06:46:41 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 13 Aug 2013 13:46:41 +0000
Subject: hg: jdk8/tl/jdk: 8022180: BigInteger Burnikel-Ziegler quotient and
remainder calculation assumes quotient parameter is zero
Message-ID: <20130813134655.5EFA14880A@hg.openjdk.java.net>
Changeset: 834faf2081b3
Author: bpb
Date: 2013-08-12 16:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/834faf2081b3
8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero
Summary: Clear the quotient in divideAndRemainderBurnikelZiegler() if the divisor is larger than the dividend.
Reviewed-by: alanb, bpb
Contributed-by: Timothy Buktu
! src/share/classes/java/math/MutableBigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java
From daniel.fuchs at oracle.com Tue Aug 13 07:01:14 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Tue, 13 Aug 2013 14:01:14 +0000
Subject: hg: jdk8/tl/jdk: 8019948:
java/util/logging/bundlesearch/ResourceBundleSearchTest.java is
failing intermittently
Message-ID: <20130813140126.A06E14880E@hg.openjdk.java.net>
Changeset: 78c102c3eefc
Author: dfuchs
Date: 2013-08-13 16:00 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78c102c3eefc
8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermittently
Reviewed-by: mchung, dholmes
! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java
From sean.mullan at oracle.com Tue Aug 13 07:10:00 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 13 Aug 2013 14:10:00 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130813141024.7A95E4880F@hg.openjdk.java.net>
Changeset: 412b2f0950a9
Author: mullan
Date: 2013-08-13 10:06 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/412b2f0950a9
8022897: Add test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java to ProblemList
Reviewed-by: vinnie, chegar
! test/ProblemList.txt
Changeset: 19133b3af95f
Author: mullan
Date: 2013-08-13 10:07 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19133b3af95f
Merge
! test/ProblemList.txt
From chris.hegarty at oracle.com Tue Aug 13 06:57:59 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 13 Aug 2013 13:57:59 +0000
Subject: hg: jdk8/tl/jdk: 8022779: ProblemList.txt updates (8/2013)
Message-ID: <20130813135811.2FB3A4880C@hg.openjdk.java.net>
Changeset: 18e15d92610b
Author: chegar
Date: 2013-08-13 14:57 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18e15d92610b
8022779: ProblemList.txt updates (8/2013)
Summary: Update ProblemList and remove AggressiveOpts MOAT test run
Reviewed-by: chegar, alanb
Contributed-by: Amy Lu
! test/ProblemList.txt
! test/java/util/Collection/MOAT.java
From joe.darcy at oracle.com Tue Aug 13 10:12:46 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 13 Aug 2013 17:12:46 +0000
Subject: hg: jdk8/tl/jdk: 8022959: Fix new doclint issues in java.util.zip
Message-ID: <20130813171336.4A95548827@hg.openjdk.java.net>
Changeset: cd9379e348d0
Author: darcy
Date: 2013-08-13 10:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd9379e348d0
8022959: Fix new doclint issues in java.util.zip
Reviewed-by: chegar
! src/share/classes/java/util/zip/ZipEntry.java
From rob.mckenna at oracle.com Tue Aug 13 11:09:34 2013
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Tue, 13 Aug 2013 18:09:34 +0000
Subject: hg: jdk8/tl/jdk: 5049299: (process) Use posix_spawn, not fork,
on S10 to avoid swap exhaustion
Message-ID: <20130813181025.5211F4882B@hg.openjdk.java.net>
Changeset: a4b0be7341ef
Author: robm
Date: 2013-08-13 19:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4b0be7341ef
5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Reviewed-by: alanb, dholmes, martin, erikj, coffeys
! make/java/java/Exportedfiles.gmk
! make/java/java/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/native/java/lang/UNIXProcess_md.c
+ src/solaris/native/java/lang/childproc.c
+ src/solaris/native/java/lang/childproc.h
+ src/solaris/native/java/lang/jspawnhelper.c
! test/java/lang/ProcessBuilder/Basic.java
From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/nashorn: 3 new changesets
Message-ID: <20130814024719.4B06448856@hg.openjdk.java.net>
Changeset: 795cff5c1b5c
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/795cff5c1b5c
Added tag jdk8-b102 for changeset e966ff0a3ffe
! .hgtags
Changeset: 414203de4374
Author: lana
Date: 2013-08-13 10:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/414203de4374
Merge
Changeset: 8ecf68b292d0
Author: lana
Date: 2013-08-13 18:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8ecf68b292d0
Merge
From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20130814024727.1676748858@hg.openjdk.java.net>
Changeset: b1ceab582fc6
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b1ceab582fc6
Added tag jdk8-b102 for changeset 7cffafa606e9
! .hgtags
Changeset: 9800647936dd
Author: lana
Date: 2013-08-13 18:28 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9800647936dd
Merge
From lana.steuck at oracle.com Tue Aug 13 19:47:03 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:03 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20130814024709.852E048855@hg.openjdk.java.net>
Changeset: f8ed09af1df6
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f8ed09af1df6
Added tag jdk8-b102 for changeset 528c7e76eaee
! .hgtags
Changeset: 49c4a777fdfd
Author: lana
Date: 2013-08-13 10:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/49c4a777fdfd
Merge
From lana.steuck at oracle.com Tue Aug 13 19:47:08 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:08 +0000
Subject: hg: jdk8/tl: Added tag jdk8-b102 for changeset 5eb3c1dc348f
Message-ID: <20130814024709.7C73148854@hg.openjdk.java.net>
Changeset: b7e64be81c8a
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/b7e64be81c8a
Added tag jdk8-b102 for changeset 5eb3c1dc348f
! .hgtags
From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20130814024733.007B548859@hg.openjdk.java.net>
Changeset: 6718df4cd616
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6718df4cd616
Added tag jdk8-b102 for changeset 453a305e1165
! .hgtags
Changeset: 76cfe7c61f25
Author: lana
Date: 2013-08-13 10:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/76cfe7c61f25
Merge
Changeset: 32b6a99cc74e
Author: lana
Date: 2013-08-13 18:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/32b6a99cc74e
Merge
From lana.steuck at oracle.com Tue Aug 13 19:47:20 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:20 +0000
Subject: hg: jdk8/tl/hotspot: 25 new changesets
Message-ID: <20130814024823.802374885A@hg.openjdk.java.net>
Changeset: b9a927798f12
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9a927798f12
Added tag jdk8-b102 for changeset c4697c1c4484
! .hgtags
Changeset: 79ce055063e9
Author: amurillo
Date: 2013-08-02 03:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79ce055063e9
8022124: new hotspot build - hs25-b45
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: 9bd314787fad
Author: mseledtsov
Date: 2013-08-01 22:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9bd314787fad
8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Reviewed-by: kvn, ctornqvi, dholmes
+ test/testlibrary/OutputAnalyzerReportingTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java
Changeset: c01913206da5
Author: ctornqvi
Date: 2013-08-01 22:20 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c01913206da5
8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle
Reviewed-by: coleenp, sspitsyn
! src/share/vm/services/management.cpp
Changeset: 81e0f17ade64
Author: ctornqvi
Date: 2013-08-01 22:25 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81e0f17ade64
8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config
Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config
Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel
- test/runtime/8000968/Test8000968.sh
+ test/runtime/CompressedOops/CompressedKlassPointerAndOops.java
Changeset: 32e3bada0978
Author: kevinw
Date: 2013-08-02 12:26 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32e3bada0978
8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str()
Reviewed-by: mgerdin, fparain, dcubed
! src/share/vm/services/gcNotifier.cpp
Changeset: dee4c330acd4
Author: dcubed
Date: 2013-08-02 08:32 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dee4c330acd4
Merge
- test/runtime/8000968/Test8000968.sh
Changeset: fa57c8104b76
Author: ctornqvi
Date: 2013-08-02 18:12 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa57c8104b76
8009585: test/runtime/7196045 times out
Summary: test/runtime/7196045 times out
Reviewed-by: dholmes, mseledtsov
- test/runtime/7196045/Test7196045.java
+ test/runtime/InternalApi/ThreadCpuTimesDeadlock.java
Changeset: 0f209afdfcf8
Author: ctornqvi
Date: 2013-08-02 18:26 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f209afdfcf8
Merge
Changeset: d02de8cac823
Author: ctornqvi
Date: 2013-08-02 22:34 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d02de8cac823
Merge
- test/runtime/7196045/Test7196045.java
Changeset: e0379d5ba5d2
Author: kevinw
Date: 2013-08-05 10:27 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0379d5ba5d2
8021444: SA: ClassDump.run() should not ignore existing ClassFilter.
Reviewed-by: minqi, poonam
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
Changeset: b67604b59546
Author: hseigel
Date: 2013-08-04 16:30 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b67604b59546
7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65
Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java
Reviewed-by: dholmes, ctornqvi
! test/testlibrary/com/oracle/java/testlibrary/Platform.java
Changeset: 9064e3a19525
Author: hseigel
Date: 2013-08-05 08:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9064e3a19525
Merge
- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh
Changeset: 22a5aff0df0b
Author: dsamersoff
Date: 2013-08-06 14:28 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22a5aff0df0b
8019396: SA-JDI OSThread class initialization throws an exception
Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException
Reviewed-by: dholmes, mgerdin
! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java
Changeset: cd25d3be91c5
Author: vladidan
Date: 2013-08-06 20:01 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd25d3be91c5
8012144: multiple SIGSEGVs fails on staxf
Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms
Reviewed-by: dholmes, kvn
! src/share/vm/utilities/taskqueue.hpp
Changeset: f5bed20f2492
Author: dholmes
Date: 2013-08-08 08:29 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f5bed20f2492
Merge
Changeset: 79a5283f4595
Author: iignatyev
Date: 2013-07-29 11:54 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79a5283f4595
8021120: TieredCompilation can be enabled even if TIERED is undefined
Reviewed-by: kvn, dholmes
! src/share/vm/runtime/arguments.cpp
Changeset: 8d77d02828d9
Author: twisti
Date: 2013-07-29 16:32 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d77d02828d9
8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get
Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer.
Reviewed-by: iveresov, kvn
! src/share/vm/c1/c1_LIRGenerator.cpp
+ test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java
Changeset: 446cb5d25d03
Author: anoll
Date: 2013-08-01 16:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/446cb5d25d03
8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited
Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m
Reviewed-by: kvn, rbackman
! test/compiler/codecache/CheckUpperLimit.java
Changeset: 6e04c193845f
Author: anoll
Date: 2013-08-02 10:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e04c193845f
8021301: better event messages
Summary: made event messages better readable
Reviewed-by: kvn, rbackman
! src/share/vm/classfile/classLoader.cpp
! src/share/vm/utilities/exceptions.cpp
Changeset: 5e0b3d7df485
Author: rbackman
Date: 2013-08-05 17:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e0b3d7df485
Merge
! src/share/vm/runtime/arguments.cpp
Changeset: 71526a36ebb4
Author: twisti
Date: 2013-08-05 15:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71526a36ebb4
8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32'
Reviewed-by: kvn
! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java
Changeset: dadf62510ae4
Author: rbackman
Date: 2013-08-08 23:49 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dadf62510ae4
Merge
Changeset: 7f55137d6aa8
Author: amurillo
Date: 2013-08-09 01:32 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f55137d6aa8
Merge
- test/runtime/7196045/Test7196045.java
- test/runtime/8000968/Test8000968.sh
Changeset: 6f9be7f87b96
Author: amurillo
Date: 2013-08-09 01:32 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f9be7f87b96
Added tag hs25-b45 for changeset 7f55137d6aa8
! .hgtags
From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:47:11 +0000
Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b102 for changeset 988a5f2ac559
Message-ID: <20130814024722.7F86B48857@hg.openjdk.java.net>
Changeset: 6cdc6ed98780
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6cdc6ed98780
Added tag jdk8-b102 for changeset 988a5f2ac559
! .hgtags
From lana.steuck at oracle.com Tue Aug 13 19:48:48 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 14 Aug 2013 02:48:48 +0000
Subject: hg: jdk8/tl/jdk: 21 new changesets
Message-ID: <20130814025338.ABC014885B@hg.openjdk.java.net>
Changeset: e057cddf0d6c
Author: cl
Date: 2013-08-08 10:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e057cddf0d6c
Added tag jdk8-b102 for changeset 8ed8e2b4b90e
! .hgtags
Changeset: 1c6bfb303ffc
Author: prr
Date: 2013-08-06 13:38 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c6bfb303ffc
8022175: Fix doclint warnings in javax.print
Reviewed-by: darcy
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/MultiDocPrintJob.java
! src/share/classes/javax/print/PrintService.java
! src/share/classes/javax/print/ServiceUI.java
! src/share/classes/javax/print/ServiceUIFactory.java
! src/share/classes/javax/print/attribute/AttributeSet.java
! src/share/classes/javax/print/attribute/DateTimeSyntax.java
! src/share/classes/javax/print/attribute/DocAttributeSet.java
! src/share/classes/javax/print/attribute/EnumSyntax.java
! src/share/classes/javax/print/attribute/HashAttributeSet.java
! src/share/classes/javax/print/attribute/IntegerSyntax.java
! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java
! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java
! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java
! src/share/classes/javax/print/attribute/ResolutionSyntax.java
! src/share/classes/javax/print/attribute/Size2DSyntax.java
! src/share/classes/javax/print/attribute/standard/Chromaticity.java
! src/share/classes/javax/print/attribute/standard/Compression.java
! src/share/classes/javax/print/attribute/standard/Finishings.java
! src/share/classes/javax/print/attribute/standard/JobKOctets.java
! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java
! src/share/classes/javax/print/attribute/standard/MediaSize.java
! src/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
! src/share/classes/javax/print/attribute/standard/PrinterResolution.java
Changeset: c3b91dc2504a
Author: jgodinez
Date: 2013-08-06 14:22 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3b91dc2504a
8021583: test/javax/print/autosense/PrintAutoSenseData.java throwing NPE
Reviewed-by: jchen, prr
! src/solaris/classes/sun/print/UnixPrintJob.java
! src/windows/classes/sun/print/Win32PrintJob.java
! test/javax/print/attribute/autosense/PrintAutoSenseData.java
+ test/javax/print/attribute/autosense/sample.txt
Changeset: fe04f40cf469
Author: prr
Date: 2013-08-06 17:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe04f40cf469
8022455: Fix doclint warnings in javax.imageio
Reviewed-by: darcy
! src/share/classes/javax/imageio/ImageIO.java
! src/share/classes/javax/imageio/ImageReadParam.java
! src/share/classes/javax/imageio/ImageReader.java
! src/share/classes/javax/imageio/ImageTypeSpecifier.java
! src/share/classes/javax/imageio/ImageWriteParam.java
! src/share/classes/javax/imageio/ImageWriter.java
! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java
! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java
! src/share/classes/javax/imageio/spi/ImageReaderSpi.java
! src/share/classes/javax/imageio/spi/ImageWriterSpi.java
! src/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/share/classes/javax/imageio/stream/ImageInputStream.java
! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/share/classes/javax/imageio/stream/ImageOutputStream.java
Changeset: c827ad8c1101
Author: prr
Date: 2013-08-06 17:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c827ad8c1101
8022447: Fix doclint warnings in java.awt.image
Reviewed-by: darcy
! src/share/classes/java/awt/image/BufferStrategy.java
! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/java/awt/image/ByteLookupTable.java
! src/share/classes/java/awt/image/ColorModel.java
! src/share/classes/java/awt/image/DirectColorModel.java
! src/share/classes/java/awt/image/ImageProducer.java
! src/share/classes/java/awt/image/IndexColorModel.java
! src/share/classes/java/awt/image/MemoryImageSource.java
! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/share/classes/java/awt/image/PixelGrabber.java
! src/share/classes/java/awt/image/RGBImageFilter.java
! src/share/classes/java/awt/image/ShortLookupTable.java
! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/share/classes/java/awt/image/WritableRaster.java
Changeset: 9314c199003d
Author: lana
Date: 2013-08-06 22:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9314c199003d
Merge
- src/share/classes/java/net/package.html
Changeset: ab64c138d5bd
Author: prr
Date: 2013-08-07 18:24 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab64c138d5bd
8014883: java.awt.container.add(component comp object constraints) doesn't work as expected on some linux platforms
Reviewed-by: jgodinez
! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/sun/java2d/x11/XRBackendNative.c
Changeset: 645a37a3559f
Author: leonidr
Date: 2013-08-01 01:26 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/645a37a3559f
8021815: Add regression test for JDK-8007267
Reviewed-by: serb
+ test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java
Changeset: 495ca130cbde
Author: alexsch
Date: 2013-08-01 17:09 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/495ca130cbde
7161568: [macosx] api/javax_swing/JTabbedPane/index2.html#varios fails
Reviewed-by: malenkov, serb
! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java
! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
+ test/javax/swing/JTabbedPane/4361477/bug4361477.java
+ test/javax/swing/JTabbedPane/6495408/bug6495408.java
+ test/javax/swing/JTabbedPane/7161568/bug7161568.java
Changeset: e76b1568d002
Author: leonidr
Date: 2013-08-02 15:42 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76b1568d002
8021381: JavaFX scene included in Swing JDialog not starting from Web Start
Reviewed-by: art, dcherepanov
! src/share/classes/sun/awt/AppContext.java
Changeset: 07abddc1d7f2
Author: leonidr
Date: 2013-08-06 17:07 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07abddc1d7f2
8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE
Reviewed-by: art
! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java
Changeset: 27d1bdf2f7d9
Author: mcherkas
Date: 2013-08-06 17:29 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27d1bdf2f7d9
8016833: Underlines and strikethrough not rendering correctly
Reviewed-by: alexsch, serb
Contributed-by: anton.nashatyrev at oracle.com
! src/share/classes/javax/swing/text/GlyphView.java
+ test/javax/swing/text/StyledEditorKit/8016833/bug8016833.java
Changeset: f8ed88f5ed87
Author: alexsch
Date: 2013-08-07 18:32 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8ed88f5ed87
8022532: [parfait] Potential memory leak in gtk2_interface.c
Reviewed-by: art, serb
! src/solaris/native/sun/awt/gtk2_interface.c
Changeset: 7706a622d35f
Author: alexsch
Date: 2013-08-07 18:58 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7706a622d35f
8013849: Awt assert on Hashtable.cpp:124
Reviewed-by: serb
! src/windows/native/sun/windows/awt_Component.cpp
+ test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java
Changeset: f70492d969e7
Author: serb
Date: 2013-08-07 19:57 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f70492d969e7
7124339: [macosx] setIconImage is not endlessly tolerant to the broken image-arguments
Reviewed-by: alexsch, leonidr
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
Changeset: 540192229a69
Author: art
Date: 2013-08-07 21:31 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/540192229a69
6551589: ContainerListener Documentation may be incorrect
Reviewed-by: serb
! src/share/classes/java/awt/event/ContainerListener.java
Changeset: 9bcc3f2af980
Author: lana
Date: 2013-08-07 12:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bcc3f2af980
Merge
- src/share/classes/java/net/package.html
Changeset: e193c4ad940a
Author: lana
Date: 2013-08-07 19:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e193c4ad940a
Merge
Changeset: 23e68a8e4b91
Author: lana
Date: 2013-08-07 19:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23e68a8e4b91
Merge
- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
Changeset: e0f6039c0290
Author: lana
Date: 2013-08-13 10:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f6039c0290
Merge
Changeset: 18ce880b5fb4
Author: lana
Date: 2013-08-13 18:33 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18ce880b5fb4
Merge
! makefiles/CompileNativeLibraries.gmk
From vicente.romero at oracle.com Wed Aug 14 02:56:50 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 14 Aug 2013 09:56:50 +0000
Subject: hg: jdk8/tl/langtools: 8013394: compile of iterator use fails with
error \"defined in an inaccessible class or interface\"
Message-ID: <20130814095656.1A4184886E@hg.openjdk.java.net>
Changeset: 0ad781399706
Author: vromero
Date: 2013-08-14 10:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0ad781399706
8013394: compile of iterator use fails with error \"defined in an inaccessible class or interface\"
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8013394/CompileErrorWithIteratorTest.java
From kumar.x.srinivasan at oracle.com Wed Aug 14 07:12:00 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 14 Aug 2013 14:12:00 +0000
Subject: hg: jdk8/tl/langtools: 8007517: DefaultMethodRegressionTests.java
fail in TL
Message-ID: <20130814141207.40C9548882@hg.openjdk.java.net>
Changeset: 3ab468194f11
Author: ksrini
Date: 2013-08-14 07:07 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ab468194f11
8007517: DefaultMethodRegressionTests.java fail in TL
Reviewed-by: jjg, vromero
- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
From kumar.x.srinivasan at oracle.com Wed Aug 14 08:14:11 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 14 Aug 2013 15:14:11 +0000
Subject: hg: jdk8/tl/jdk: 8022547: [verifier] move
DefaultMethodRegressionTests.java to jdk
Message-ID: <20130814151438.4906648890@hg.openjdk.java.net>
Changeset: bc3cafb17c09
Author: ksrini
Date: 2013-08-14 08:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc3cafb17c09
8022547: [verifier] move DefaultMethodRegressionTests.java to jdk
Reviewed-by: acorn
+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java
+ test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java
From xueming.shen at oracle.com Wed Aug 14 11:40:18 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 14 Aug 2013 18:40:18 +0000
Subject: hg: jdk8/tl/jdk: 8022178: System.console() throws IOE on some Windows
Message-ID: <20130814184030.A190B48897@hg.openjdk.java.net>
Changeset: c138d1b608e0
Author: sherman
Date: 2013-08-14 11:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c138d1b608e0
8022178: System.console() throws IOE on some Windows
Summary: to remove the IOE throwing code
Reviewed-by: alanb
! src/windows/native/java/io/Console_md.c
From joe.darcy at oracle.com Wed Aug 14 11:27:21 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 14 Aug 2013 18:27:21 +0000
Subject: hg: jdk8/tl/jdk: 8022990: Fix dep_ann lint warnings in swing code
Message-ID: <20130814182745.46DDC48895@hg.openjdk.java.net>
Changeset: 444a7edcf367
Author: darcy
Date: 2013-08-14 11:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/444a7edcf367
8022990: Fix dep_ann lint warnings in swing code
Reviewed-by: alexsch
! src/share/classes/com/sun/java/swing/Painter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java
From mike.duigou at oracle.com Wed Aug 14 13:38:36 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 14 Aug 2013 20:38:36 +0000
Subject: hg: jdk8/tl/jdk: 8022109: Evaluate adding incrementExact,
decrementExact, negateExact to java.lang.Math
Message-ID: <20130814203859.9BC0F4889C@hg.openjdk.java.net>
Changeset: 17dfbb3f60d3
Author: bpb
Date: 2013-08-12 10:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17dfbb3f60d3
8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math
Summary: Add the methods for parameter types int and long.
Reviewed-by: mduigou
Contributed-by: Brian Burkhalter
! src/share/classes/java/lang/Math.java
! test/java/lang/Math/ExactArithTests.java
From jonathan.gibbons at oracle.com Wed Aug 14 16:41:29 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 14 Aug 2013 23:41:29 +0000
Subject: hg: jdk8/tl/langtools: 8017191: Javadoc is confused by @link to
imported classes outside of the set of generated packages
Message-ID: <20130814234134.907F4488A5@hg.openjdk.java.net>
Changeset: 14faef2b51eb
Author: jjg
Date: 2013-08-14 16:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/14faef2b51eb
8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
+ test/com/sun/javadoc/testSeeTag/TestSeeTag.java
+ test/com/sun/javadoc/testSeeTag/pkg/Test.java
From kumar.x.srinivasan at oracle.com Wed Aug 14 18:59:33 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Thu, 15 Aug 2013 01:59:33 +0000
Subject: hg: jdk8/tl/langtools: 6840442: JavaCompiler.getTask() has incomplete
specification for IllegalArgumentException
Message-ID: <20130815015938.49FDB488A8@hg.openjdk.java.net>
Changeset: fac0d1bb87f2
Author: ksrini
Date: 2013-08-14 18:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fac0d1bb87f2
6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException
Reviewed-by: jjg
! src/share/classes/javax/tools/JavaCompiler.java
From bradford.wetmore at oracle.com Wed Aug 14 19:21:36 2013
From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com)
Date: Thu, 15 Aug 2013 02:21:36 +0000
Subject: hg: jdk8/tl/jdk: 8023075: JDK-5049299 has broken old make in jdk8
Message-ID: <20130815022202.8E3A8488AA@hg.openjdk.java.net>
Changeset: f8af3499c1fb
Author: wetmore
Date: 2013-08-14 19:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8af3499c1fb
8023075: JDK-5049299 has broken old make in jdk8
Reviewed-by: katleman
! make/java/java/Makefile
From chris.hegarty at oracle.com Thu Aug 15 02:46:02 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 15 Aug 2013 10:46:02 +0100
Subject: RFR 8023090: Additional debug info for
java/net/NetworkInterface/Equals.java
Message-ID: <520CA35A.3090405@oracle.com>
Another NetworkInterface test failed for an unexplainable reason, and is
not readily reproducible on the same machine. Similar to IndexTest.java
I would like to add some additional diagnostic information so we can try
to determine the cause of the failure, if seen again.
Additionaly, this test captures all the network interface configuration
and displays it, along with the failure, only if the test fails. There
are no functional changes to the test itself.
diff -r bca19fdd875a test/java/net/NetworkInterface/Equals.java
--- a/test/java/net/NetworkInterface/Equals.java Tue Aug 13
13:04:21 2013 +0400
+++ b/test/java/net/NetworkInterface/Equals.java Thu Aug 15
10:38:17 2013 +0100
@@ -25,41 +25,82 @@
* @bug 7003398
* @run main/othervm Equals
*/
+
+import java.io.ByteArrayOutputStream;
+import java.io.PrintStream;
+import java.net.InetAddress;
import java.net.NetworkInterface;
-import java.net.InetAddress;
+import java.net.SocketException;
+import java.util.Arrays;
+import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
public class Equals {
public static void main(String args[]) throws Exception {
+ ByteArrayOutputStream baos = new ByteArrayOutputStream();
+ PrintStream bufferedOut = new PrintStream(baos);
- Enumeration nifs1 = NetworkInterface.getNetworkInterfaces();
+ Enumeration nifs1 =
NetworkInterface.getNetworkInterfaces();
HashMap hashes = new HashMap<>();
HashMap nicMap = new HashMap<>();
while (nifs1.hasMoreElements()) {
- NetworkInterface ni = (NetworkInterface)nifs1.nextElement();
+ NetworkInterface ni = nifs1.nextElement();
hashes.put(ni.getName(),ni.hashCode());
nicMap.put(ni.getName(),ni);
+ displayInterfaceInformation(ni, bufferedOut);
+ bufferedOut.flush();
}
System.setSecurityManager(new SecurityManager());
- Enumeration nifs2 = NetworkInterface.getNetworkInterfaces();
+ Enumeration nifs2 =
NetworkInterface.getNetworkInterfaces();
while (nifs2.hasMoreElements()) {
- NetworkInterface ni = (NetworkInterface)nifs2.nextElement();
+ NetworkInterface ni = nifs2.nextElement();
NetworkInterface niOrig = nicMap.get(ni.getName());
- int h = hashes.get(ni.getName());
- if (h != ni.hashCode()) {
+ int h = ni.hashCode();
+ if (h == hashes.get(ni.getName())) {
+ System.out.printf("%nSystem information:%n");
+ System.out.printf("%s", baos.toString("UTF8"));
+ System.out.printf("%nni.hashCode() returned %d,
expected %d, for:%n",
+ h, hashes.get(ni.getName()));
+ displayInterfaceInformation(ni,System.out);
throw new RuntimeException ("Hashcodes different for " +
ni.getName());
}
if (!ni.equals(niOrig)) {
+ System.out.printf("%nSystem information:%n");
+ System.out.printf("%s", baos.toString("UTF8"));
+ System.out.printf("%nExpected the following interfaces
to be the same:%n");
+ displayInterfaceInformation(niOrig, System.out);
+ displayInterfaceInformation(ni,System.out);
throw new RuntimeException ("equality different for " +
ni.getName());
}
}
}
+
+ static void displayInterfaceInformation(NetworkInterface netint,
+ PrintStream out) throws
SocketException {
+ out.printf("Display name: %s%n", netint.getDisplayName());
+ out.printf("Name: %s%n", netint.getName());
+ Enumeration inetAddresses = netint.getInetAddresses();
+
+ for (InetAddress inetAddress : Collections.list(inetAddresses))
+ out.printf("InetAddress: %s%n", inetAddress);
+
+ out.printf("Up? %s%n", netint.isUp());
+ out.printf("Loopback? %s%n", netint.isLoopback());
+ out.printf("PointToPoint? %s%n", netint.isPointToPoint());
+ out.printf("Supports multicast? %s%n", netint.supportsMulticast());
+ out.printf("Virtual? %s%n", netint.isVirtual());
+ out.printf("Hardware address: %s%n",
+ Arrays.toString(netint.getHardwareAddress()));
+ out.printf("MTU: %s%n", netint.getMTU());
+ out.printf("Index: %s%n", netint.getIndex());
+ out.printf("%n");
+ }
}
-Chris.
From Alan.Bateman at oracle.com Thu Aug 15 03:05:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 15 Aug 2013 11:05:22 +0100
Subject: RFR 8023090: Additional debug info for
java/net/NetworkInterface/Equals.java
In-Reply-To: <520CA35A.3090405@oracle.com>
References: <520CA35A.3090405@oracle.com>
Message-ID: <520CA7E2.1050807@oracle.com>
On 15/08/2013 10:46, Chris Hegarty wrote:
> Another NetworkInterface test failed for an unexplainable reason, and
> is not readily reproducible on the same machine. Similar to
> IndexTest.java I would like to add some additional diagnostic
> information so we can try to determine the cause of the failure, if
> seen again.
>
> Additionaly, this test captures all the network interface
> configuration and displays it, along with the failure, only if the
> test fails. There are no functional changes to the test itself.
Looks okay, I've often wondered if wifi interfaces on a test machines
might contribute to problems with these tests.
-Alan.
From alan.bateman at oracle.com Thu Aug 15 03:59:11 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 15 Aug 2013 10:59:11 +0000
Subject: hg: jdk8/tl/jdk: 8022921: Remove experimental Profile attribute
Message-ID: <20130815105950.DE270488BB@hg.openjdk.java.net>
Changeset: 5ff3b55df2d4
Author: alanb
Date: 2013-08-15 11:54 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ff3b55df2d4
8022921: Remove experimental Profile attribute
Reviewed-by: mchung, chegar
! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/util/jar/Attributes.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
! src/share/classes/sun/launcher/LauncherHelper.java
! src/share/classes/sun/launcher/resources/launcher.properties
! src/share/classes/sun/misc/JavaUtilJarAccess.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/classes/sun/misc/Version.java.template
! src/share/classes/sun/tools/jar/Main.java
! src/share/classes/sun/tools/jar/resources/jar.properties
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java
From alan.bateman at oracle.com Thu Aug 15 05:47:15 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 15 Aug 2013 12:47:15 +0000
Subject: hg: jdk8/tl/jdk: 8015765: TEST_BUG:
java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
failing intermittently
Message-ID: <20130815124748.AA4E2488BC@hg.openjdk.java.net>
Changeset: b7b0beef5ded
Author: alanb
Date: 2013-08-15 13:42 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7b0beef5ded
8015765: TEST_BUG: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failing intermittently
Reviewed-by: chegar, dholmes, alanb
Contributed-by: yiming.wang at oracle.com
! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
From chris.hegarty at oracle.com Thu Aug 15 06:52:27 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 13:52:27 +0000
Subject: hg: jdk8/tl/jdk: 8022584: Memory leak in some NetworkInterface methods
Message-ID: <20130815135302.BDDF0488C0@hg.openjdk.java.net>
Changeset: 7d7d553a8c61
Author: igerasim
Date: 2013-08-13 13:04 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7d553a8c61
8022584: Memory leak in some NetworkInterface methods
Reviewed-by: alanb, dholmes, chegar, michaelm
! src/solaris/native/java/net/NetworkInterface.c
+ test/java/net/NetworkInterface/MemLeakTest.java
From chris.hegarty at oracle.com Thu Aug 15 07:01:52 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 14:01:52 +0000
Subject: hg: jdk8/tl/jdk: 8023103: FJ parallelism zero; ...
Message-ID: <20130815140204.0D5EE488C1@hg.openjdk.java.net>
Changeset: 3223342fb76e
Author: dl
Date: 2013-08-15 15:01 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3223342fb76e
8023103: FJ parallelism zero
8020537: java/util/concurrent/forkjoin/ThrowingRunnable.java
Reviewed-by: chegar, mduigou, alanb
! src/share/classes/java/util/concurrent/ForkJoinPool.java
From chris.hegarty at oracle.com Thu Aug 15 07:05:14 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 14:05:14 +0000
Subject: hg: jdk8/tl/jdk: 8023104: ConcurrentHashMap typo
Message-ID: <20130815140526.9587B488C2@hg.openjdk.java.net>
Changeset: b07b19182e40
Author: dl
Date: 2013-08-15 15:04 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b07b19182e40
8023104: ConcurrentHashMap typo
Reviewed-by: chegar, mduigou
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
From chris.hegarty at oracle.com Thu Aug 15 07:16:47 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 15 Aug 2013 14:16:47 +0000
Subject: hg: jdk8/tl/jdk: 8022126: Remove throws SocketException from
DatagramPacket constructors accepting SocketAddress
Message-ID: <20130815141659.619C8488C3@hg.openjdk.java.net>
Changeset: e7137695dce3
Author: chegar
Date: 2013-08-15 15:16 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7137695dce3
8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress
Reviewed-by: smarks, alanb, michaelm, darcy
! src/share/classes/java/net/DatagramPacket.java
From mike.duigou at oracle.com Thu Aug 15 10:08:35 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 15 Aug 2013 10:08:35 -0700
Subject: Code review request,
8020842 IDN do not throw IAE when hostname ends with a trailing dot
In-Reply-To: <5209EE6C.3050604@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
<52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com>
<5209EE6C.3050604@oracle.com>
Message-ID:
I've been confused through this discussion as to why a trailing dot would be regarded as illegal.
Historically a trailing dot has been frequently (though not universally) used to denote a fully qualified domain name.
https://en.wikipedia.org/wiki/Fully_qualified_domain_name
Is this use now illegal/unsupported/invalid? Does having a trailing dot conflict with other parts of the IDN specification?
Mike
On Aug 13 2013, at 01:29 , Xuelei Fan wrote:
> Can I get an additional code review from networking team?
>
> Thanks,
> Xuelei
>
> On 8/12/2013 2:07 PM, Weijun Wang wrote:
>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
>
From xueming.shen at oracle.com Thu Aug 15 10:39:16 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Thu, 15 Aug 2013 17:39:16 +0000
Subject: hg: jdk8/tl/jdk: 7154662: {CRC32, Adler32}.update(byte[] b, int off,
int len): undocumented ArrayIndexOutOfBoundsException
Message-ID: <20130815173953.E887D488DF@hg.openjdk.java.net>
Changeset: 6c307b4d0dd8
Author: sherman
Date: 2013-08-15 10:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c307b4d0dd8
7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException
Summary: to add the throws clause
Reviewed-by: alanb, chegar
! src/share/classes/java/util/zip/Adler32.java
! src/share/classes/java/util/zip/CRC32.java
From Xuelei.Fan at Oracle.Com Thu Aug 15 10:40:27 2013
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Fri, 16 Aug 2013 01:40:27 +0800
Subject: Code review request,
8020842 IDN do not throw IAE when hostname ends with a trailing dot
In-Reply-To:
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
<52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com>
<5209EE6C.3050604@oracle.com>
Message-ID:
On Aug 16, 2013, at 1:08, Mike Duigou wrote:
> I've been confused through this discussion as to why a trailing dot would be regarded as illegal.
>
The discussion is too long to find the final decision easily. A IDN with trailing dot should be regarded as legal IDN. This update is trying to fix this. For example, "." and "example.com." are legal IDN, and IDN.toASCII() should be return the legal name accordingly.
However, per the specification of Server Name Indication of TLS extension, a hostname should not end with trailing dot. So in SNIHostName, we will check the return value of IDN.toASCII() to filter out hostnames with trailing dots.
This fix is trying to have IDN working with tailing dot and empty label correctly. The previous code of SNIHostName will work as expected if IDN can handle trailing dot properly.
Thanks,
Xuelei
> Historically a trailing dot has been frequently (though not universally) used to denote a fully qualified domain name.
>
> https://en.wikipedia.org/wiki/Fully_qualified_domain_name
>
> Is this use now illegal/unsupported/invalid? Does having a trailing dot conflict with other parts of the IDN specification?
>
> Mike
>
> On Aug 13 2013, at 01:29 , Xuelei Fan wrote:
>
>> Can I get an additional code review from networking team?
>>
>> Thanks,
>> Xuelei
>>
>> On 8/12/2013 2:07 PM, Weijun Wang wrote:
>>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
>
From mhall at mhcomputing.net Thu Aug 15 10:40:19 2013
From: mhall at mhcomputing.net (Matthew Hall)
Date: Thu, 15 Aug 2013 10:40:19 -0700
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To:
References: <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
<52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com>
<5209EE6C.3050604@oracle.com>
Message-ID: <20130815174019.GA21965@mhcomputing.net>
On Thu, Aug 15, 2013 at 10:08:35AM -0700, Mike Duigou wrote:
> I've been confused through this discussion as to why a trailing dot would be regarded as illegal.
>
> Historically a trailing dot has been frequently (though not universally) used to denote a fully qualified domain name.
>
> https://en.wikipedia.org/wiki/Fully_qualified_domain_name
>
> Is this use now illegal/unsupported/invalid? Does having a trailing dot conflict with other parts of the IDN specification?
>
> Mike
This is why some of us were protesting the code which disallowed the trailing
'.', and eventually the code was changed to allow it to be present.
Matthew.
From vincent.x.ryan at oracle.com Thu Aug 15 11:57:28 2013
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Thu, 15 Aug 2013 18:57:28 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130815185828.D4AEB488F8@hg.openjdk.java.net>
Changeset: b4645069238a
Author: vinnie
Date: 2013-08-15 19:49 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4645069238a
8023108: Remove ShortRSAKey1024.sh from ProblemList.txt
Reviewed-by: mullan
! test/ProblemList.txt
Changeset: 3211caab58ba
Author: vinnie
Date: 2013-08-15 19:56 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3211caab58ba
Merge
From dan.xu at oracle.com Thu Aug 15 12:37:01 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 15 Aug 2013 19:37:01 +0000
Subject: hg: jdk8/tl/jdk: 4858457: File.getCanonicalPath() throws IOException
when invoked with "nul" (win)
Message-ID: <20130815193727.9F60848905@hg.openjdk.java.net>
Changeset: 5bb196aa183c
Author: dxu
Date: 2013-08-15 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bb196aa183c
4858457: File.getCanonicalPath() throws IOException when invoked with "nul" (win)
Reviewed-by: alanb
! src/windows/native/java/io/canonicalize_md.c
! test/java/io/File/WinDeviceName.java
From dan.xu at oracle.com Thu Aug 15 14:11:34 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 15 Aug 2013 21:11:34 +0000
Subject: hg: jdk8/tl/jdk: 8017109: Cleanup overrides warning in
src/solaris/classes/sun/print/AttributeClass.java
Message-ID: <20130815211147.0FDCE48913@hg.openjdk.java.net>
Changeset: 0d27309a87e0
Author: dxu
Date: 2013-08-15 14:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d27309a87e0
8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java
Reviewed-by: jgodinez
! src/solaris/classes/sun/print/AttributeClass.java
From vicente.romero at oracle.com Fri Aug 16 02:33:30 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 16 Aug 2013 09:33:30 +0000
Subject: hg: jdk8/tl/langtools: 8022053: javac generates unverifiable
initializer for nested subclass of local class
Message-ID: <20130816093341.F3A3D48927@hg.openjdk.java.net>
Changeset: a6378c19836b
Author: vromero
Date: 2013-08-16 10:32 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a6378c19836b
8022053: javac generates unverifiable initializer for nested subclass of local class
Reviewed-by: jjg, mcimadamore
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8022053/UnverifiableInitForNestedLocalClassTest.java
From paul.sandoz at oracle.com Fri Aug 16 03:41:09 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 16 Aug 2013 10:41:09 +0000
Subject: hg: jdk8/tl/jdk: 8023150: java/util/stream tests no longer compiling
following JDK-8019401
Message-ID: <20130816104126.AC1FD4892A@hg.openjdk.java.net>
Changeset: 5fe19566b6f0
Author: psandoz
Date: 2013-08-16 12:29 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe19566b6f0
8023150: java/util/stream tests no longer compiling following JDK-8019401
Reviewed-by: alanb
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
From paul.sandoz at oracle.com Fri Aug 16 03:50:51 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 16 Aug 2013 10:50:51 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130816105116.052784892B@hg.openjdk.java.net>
Changeset: 2eebaff52a94
Author: psandoz
Date: 2013-08-16 12:46 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2eebaff52a94
8012940: More than 50 tests failed in Serialization/DeSerialization testing (test-mangled)
Reviewed-by: ksrini
+ test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java
Changeset: 02ce5a0e4b98
Author: psandoz
Date: 2013-08-16 12:46 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02ce5a0e4b98
8022898: java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider
Reviewed-by: henryjen, alanb, rriggs
! test/java/util/Spliterator/SpliteratorCollisions.java
From maurizio.cimadamore at oracle.com Fri Aug 16 04:02:10 2013
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 16 Aug 2013 11:02:10 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20130816110219.73A474892C@hg.openjdk.java.net>
Changeset: ec77c7b46c37
Author: jlahoda
Date: 2013-08-15 22:33 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec77c7b46c37
8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression
Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.java
+ test/tools/javac/lambda/ExceptionsInLambda.out
! test/tools/javac/lambda/TargetType21.out
Changeset: f657d400c736
Author: jlahoda
Date: 2013-08-15 22:36 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f657d400c736
8022508: javac crashes if the generics arity of a base class is wrong
Reviewed-by: mcimadamore, vromero
! src/share/classes/com/sun/tools/javac/comp/Check.java
! test/tools/javac/generics/8016640/T8016640.java
From paul.sandoz at oracle.com Fri Aug 16 04:24:39 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 16 Aug 2013 11:24:39 +0000
Subject: hg: jdk8/tl/jdk: 8022797: Clarify spliterator characteristics for
collections containing no elements
Message-ID: <20130816112450.C13654892E@hg.openjdk.java.net>
Changeset: 737b6c298d81
Author: psandoz
Date: 2013-08-13 11:16 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/737b6c298d81
8022797: Clarify spliterator characteristics for collections containing no elements
Reviewed-by: alanb, mduigou
! src/share/classes/java/util/Collection.java
From roger.riggs at oracle.com Fri Aug 16 09:50:21 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 16 Aug 2013 16:50:21 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130816165100.1B3C04893F@hg.openjdk.java.net>
Changeset: 53819fd0ab61
Author: rriggs
Date: 2013-08-16 11:28 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53819fd0ab61
8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing
8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed.
Summary: TCKChronology: corrected display name to match update from JDK-8015986
Reviewed-by: alanb
! test/java/time/tck/java/time/chrono/TCKChronology.java
! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
Changeset: d7fc4e149bb8
Author: rriggs
Date: 2013-08-16 11:11 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7fc4e149bb8
8022193: java/time/test/java/util/TestFormatter.java failed in th locale.
Summary: Tests corrected to use fixed locale and not dependent on the environment
Reviewed-by: sherman
! src/share/classes/java/util/Formatter.java
! test/java/time/test/java/util/TestFormatter.java
From roger.riggs at oracle.com Fri Aug 16 11:00:01 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Fri, 16 Aug 2013 18:00:01 +0000
Subject: hg: jdk8/tl/jdk: 8019185: Inconsistency between JapaneseEra start
dates and java.util.JapaneseImperialDate
Message-ID: <20130816180013.E79D848946@hg.openjdk.java.net>
Changeset: acaa256e3f7c
Author: rriggs
Date: 2013-08-16 13:58 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acaa256e3f7c
8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate
Summary: align Meiji start date with lib/calendar.properties to avoid any confusion
Reviewed-by: sherman
! src/share/classes/java/time/chrono/JapaneseEra.java
From xuelei.fan at oracle.com Sun Aug 18 22:56:51 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 19 Aug 2013 13:56:51 +0800
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5209EE6C.3050604@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
<52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com>
<5209EE6C.3050604@oracle.com>
Message-ID: <5211B3A3.2050506@oracle.com>
If no objections, I will push the change by COB Monday.
Thanks,
Xuelei
On 8/13/2013 4:29 PM, Xuelei Fan wrote:
> Can I get an additional code review from networking team?
>
> Thanks,
> Xuelei
>
> On 8/12/2013 2:07 PM, Weijun Wang wrote:
>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
>
From paul.sandoz at oracle.com Mon Aug 19 01:54:44 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 19 Aug 2013 08:54:44 +0000
Subject: hg: jdk8/tl/jdk: 8022318: Document Spliterator characteristics and
binding policy of java util concurrent collection impls
Message-ID: <20130819085531.8707F48988@hg.openjdk.java.net>
Changeset: 9e9f5713b26d
Author: psandoz
Date: 2013-08-06 14:26 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e9f5713b26d
8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls
Reviewed-by: chegar
Contributed-by: Martin Buchholz , Paul Sandoz
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/package-info.java
From chris.hegarty at oracle.com Mon Aug 19 02:45:33 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 19 Aug 2013 09:45:33 +0000
Subject: hg: jdk8/tl: 8021820: Number of opened files used in select() is
limited to 1024 [macosx]
Message-ID: <20130819094534.30D3F4898B@hg.openjdk.java.net>
Changeset: 00dcfaa6bc01
Author: aefimov
Date: 2013-08-16 18:40 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/rev/00dcfaa6bc01
8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks
! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4
From chris.hegarty at oracle.com Mon Aug 19 02:47:17 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 19 Aug 2013 09:47:17 +0000
Subject: hg: jdk8/tl/jdk: 8021820: Number of opened files used in select() is
limited to 1024 [macosx]
Message-ID: <20130819094817.B3DE94898E@hg.openjdk.java.net>
Changeset: 11ccaabdb2a8
Author: aefimov
Date: 2013-08-16 18:41 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11ccaabdb2a8
8021820: Number of opened files used in select() is limited to 1024 [macosx]
Reviewed-by: alanb, chegar, tbell, smarks
+ test/java/net/ServerSocket/SelectFdsLimit.java
From alan.bateman at oracle.com Mon Aug 19 03:07:04 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 19 Aug 2013 10:07:04 +0000
Subject: hg: jdk8/tl/jdk: 8023215: test/java/util/Comparator/TypeTest.java not
running (failing but reported as passing)
Message-ID: <20130819100719.3AF2648991@hg.openjdk.java.net>
Changeset: f580728b08b4
Author: alanb
Date: 2013-08-19 11:04 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f580728b08b4
8023215: test/java/util/Comparator/TypeTest.java not running (failing but reported as passing)
Reviewed-by: psandoz
! test/java/util/Comparator/TypeTest.java
From paul.sandoz at oracle.com Mon Aug 19 07:15:56 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 19 Aug 2013 14:15:56 +0000
Subject: hg: jdk8/tl/jdk: 8014824: Document Spliterator characteristics and
binding policy of java util collection impls
Message-ID: <20130819141634.3910A4899C@hg.openjdk.java.net>
Changeset: 3647aab7b1d5
Author: psandoz
Date: 2013-08-06 14:26 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3647aab7b1d5
8014824: Document Spliterator characteristics and binding policy of java util collection impls
Reviewed-by: chegar
! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java
From michael.x.mcmahon at oracle.com Mon Aug 19 08:12:22 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 19 Aug 2013 16:12:22 +0100
Subject: Code review request, 8020842 IDN do not throw IAE when hostname
ends with a trailing dot
In-Reply-To: <5211B3A3.2050506@oracle.com>
References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com>
<520133C7.20401@oracle.com> <5202411F.2010706@oracle.com>
<52025434.8070200@oracle.com> <5202561A.5040908@oracle.com>
<52025726.8060203@oracle.com> <520264F1.1090802@oracle.com>
<52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com>
<520447BD.30206@oracle.com> <52045070.1000506@oracle.com>
<520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com>
<5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com>
<520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com>
<520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com>
<52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com>
<5209EE6C.3050604@oracle.com> <5211B3A3.2050506@oracle.com>
Message-ID: <521235D6.2070308@oracle.com>
Seems fine to me Xuelei.
- Michael
On 19/08/13 06:56, Xuelei Fan wrote:
> If no objections, I will push the change by COB Monday.
>
> Thanks,
> Xuelei
>
> On 8/13/2013 4:29 PM, Xuelei Fan wrote:
>> Can I get an additional code review from networking team?
>>
>> Thanks,
>> Xuelei
>>
>> On 8/12/2013 2:07 PM, Weijun Wang wrote:
>>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
From kumar.x.srinivasan at oracle.com Mon Aug 19 09:42:45 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Mon, 19 Aug 2013 16:42:45 +0000
Subject: hg: jdk8/tl/langtools: 7071377: Exception when javac -processor is
given a class name with invalid postfix
Message-ID: <20130819164255.72E15489A4@hg.openjdk.java.net>
Changeset: 389eaf6ed973
Author: ksrini
Date: 2013-08-19 07:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/389eaf6ed973
7071377: Exception when javac -processor is given a class name with invalid postfix
Reviewed-by: jjg, vromero
! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/processing/errors/TestClassNames.java
From sean.mullan at oracle.com Mon Aug 19 12:13:44 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 19 Aug 2013 19:13:44 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130819191422.3915D489A7@hg.openjdk.java.net>
Changeset: bce5205dbe84
Author: ascarpino
Date: 2013-08-14 10:50 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bce5205dbe84
8022669: OAEPParameterSpec does not work if MGF1ParameterSpec is set to SHA2 algorithms
Reviewed-by: mullan
! src/share/classes/sun/security/rsa/RSAPadding.java
! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java
Changeset: b40d246d4d81
Author: ascarpino
Date: 2013-08-16 12:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b40d246d4d81
8022896: test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java fails
Reviewed-by: mullan
! test/ProblemList.txt
From dan.xu at oracle.com Mon Aug 19 12:39:13 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Mon, 19 Aug 2013 19:39:13 +0000
Subject: hg: jdk8/tl/jdk: 8023203: Wrap RandomAccessFile.seek native method
into a Java helper method
Message-ID: <20130819193934.17B0D489B2@hg.openjdk.java.net>
Changeset: 2fd841fccb2e
Author: dxu
Date: 2013-08-19 12:38 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2fd841fccb2e
8023203: Wrap RandomAccessFile.seek native method into a Java helper method
Reviewed-by: alanb, chegar
! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/io/RandomAccessFile.java
! src/share/native/java/io/RandomAccessFile.c
From sean.mullan at oracle.com Mon Aug 19 14:19:17 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 19 Aug 2013 21:19:17 +0000
Subject: hg: jdk8/tl/jdk: 8016850: JCK javax.security.auth.Policy tests fail
when run in Profiles mode
Message-ID: <20130819211951.B52AD489C1@hg.openjdk.java.net>
Changeset: f120e2c4b4b1
Author: mullan
Date: 2013-08-19 17:17 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f120e2c4b4b1
8016850: JCK javax.security.auth.Policy tests fail when run in Profiles mode
Summary: Move default javax.security.auth.Policy implementation to compact1 profile
Reviewed-by: vinnie
! src/share/classes/com/sun/security/auth/PolicyFile.java
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
! src/share/classes/javax/security/auth/Policy.java
+ src/share/classes/sun/security/provider/AuthPolicyFile.java
+ src/share/classes/sun/security/provider/SubjectCodeSource.java
From xuelei.fan at oracle.com Mon Aug 19 17:43:43 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 20 Aug 2013 00:43:43 +0000
Subject: hg: jdk8/tl/jdk: 8020842: IDN do not throw IAE when hostname ends
with a trailing dot
Message-ID: <20130820004420.A5A84489CB@hg.openjdk.java.net>
Changeset: 096e7c665857
Author: xuelei
Date: 2013-08-19 17:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/096e7c665857
8020842: IDN do not throw IAE when hostname ends with a trailing dot
Reviewed-by: weijun, michaelm
! src/share/classes/java/net/IDN.java
+ test/java/net/IDN/IllegalArg.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java
From xuelei.fan at oracle.com Mon Aug 19 18:51:26 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 20 Aug 2013 01:51:26 +0000
Subject: hg: jdk8/tl/jdk: 8023230: The impl of KerberosClientKeyExchange maybe
not exist
Message-ID: <20130820015148.C0D5F489CE@hg.openjdk.java.net>
Changeset: 21a25911f7f7
Author: xuelei
Date: 2013-08-19 18:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21a25911f7f7
8023230: The impl of KerberosClientKeyExchange maybe not exist
Reviewed-by: weijun
! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
From staffan.larsen at oracle.com Mon Aug 19 23:59:36 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 20 Aug 2013 06:59:36 +0000
Subject: hg: jdk8/tl/jdk: 8022071: Some vm/jvmti tests fail because cannot
attach to the Java virtual machine
Message-ID: <20130820070010.F0E36489D2@hg.openjdk.java.net>
Changeset: 53ea4b5cef9b
Author: sla
Date: 2013-08-20 08:59 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53ea4b5cef9b
8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine
Reviewed-by: erikj, sspitsyn
! makefiles/CompileNativeLibraries.gmk
+ makefiles/mapfiles/libattach/reorder-windows-x86
+ makefiles/mapfiles/libattach/reorder-windows-x86_64
! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c
From david.holmes at oracle.com Tue Aug 20 00:19:32 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Tue, 20 Aug 2013 07:19:32 +0000
Subject: hg: jdk8/tl/jdk: 8023311: Clean up profile-includes.txt
Message-ID: <20130820071955.810B7489D5@hg.openjdk.java.net>
Changeset: e17da8b09f5e
Author: dholmes
Date: 2013-08-20 03:18 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e17da8b09f5e
8023311: Clean up profile-includes.txt
Reviewed-by: alanb
! makefiles/profile-includes.txt
From staffan.larsen at oracle.com Tue Aug 20 07:56:12 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 20 Aug 2013 14:56:12 +0000
Subject: hg: jdk8/tl/jdk: 8016727:
test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Message-ID: <20130820145635.5C28E489E3@hg.openjdk.java.net>
Changeset: 961cdea684b5
Author: sla
Date: 2013-08-20 16:53 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/961cdea684b5
8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Reviewed-by: alanb
! test/com/sun/jdi/sde/TemperatureTableTest.java
From paul.sandoz at oracle.com Tue Aug 20 09:47:20 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Tue, 20 Aug 2013 16:47:20 +0000
Subject: hg: jdk8/tl/jdk: 8023367:
Collections.emptyList().sort((Comparator)null) throws NPE
Message-ID: <20130820164747.1CD50489ED@hg.openjdk.java.net>
Changeset: c17d6543b30f
Author: psandoz
Date: 2013-08-20 17:36 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c17d6543b30f
8023367: Collections.emptyList().sort((Comparator)null) throws NPE
Reviewed-by: alanb, mduigou
! src/share/classes/java/util/Collections.java
! test/java/util/Collection/ListDefaults.java
From staffan.larsen at oracle.com Tue Aug 20 10:07:41 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 20 Aug 2013 17:07:41 +0000
Subject: hg: jdk8/tl/jdk: 8023250: Update JavaScript code in JDK for changes
in iteration over Java arrays
Message-ID: <20130820170753.D7C43489F1@hg.openjdk.java.net>
Changeset: 1ccc7bbee0bb
Author: attila
Date: 2013-08-20 11:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ccc7bbee0bb
8023250: Update JavaScript code in JDK for changes in iteration over Java arrays
Reviewed-by: sundar, sla
! src/share/classes/com/sun/tools/hat/resources/hat.js
From joe.darcy at oracle.com Tue Aug 20 12:16:27 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 20 Aug 2013 19:16:27 +0000
Subject: hg: jdk8/tl/langtools: 8011043: Warn about use of 1.5 and earlier
source and target values
Message-ID: <20130820191632.B7F59489F6@hg.openjdk.java.net>
Changeset: 58da1296c6b3
Author: darcy
Date: 2013-08-20 12:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58da1296c6b3
8011043: Warn about use of 1.5 and earlier source and target values
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javadoc/Start.java
+ test/tools/javac/diags/examples/ObsoleteSourceAndTarget.java
From jonathan.gibbons at oracle.com Tue Aug 20 14:48:34 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 20 Aug 2013 21:48:34 +0000
Subject: hg: jdk8/tl/langtools: 8020663: Restructure some properties to
facilitate better translation
Message-ID: <20130820214837.9671E48A07@hg.openjdk.java.net>
Changeset: a76dc1b4c299
Author: jjg
Date: 2013-08-20 14:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76dc1b4c299
8020663: Restructure some properties to facilitate better translation
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
From kumar.x.srinivasan at oracle.com Tue Aug 20 14:18:34 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 20 Aug 2013 21:18:34 +0000
Subject: hg: jdk8/tl/langtools: 7179455:
tools/javac/processing/model/testgetallmembers/Main.java fails
against JDK 7 and JDK 8
Message-ID: <20130820211839.BB48A48A01@hg.openjdk.java.net>
Changeset: 0f88e3d3d250
Author: ksrini
Date: 2013-08-20 14:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f88e3d3d250
7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8
Reviewed-by: jjg
! test/tools/javac/processing/model/testgetallmembers/Main.java
From jonathan.gibbons at oracle.com Tue Aug 20 14:55:32 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 20 Aug 2013 21:55:32 +0000
Subject: hg: jdk8/tl/langtools: 8022080: javadoc generates invalid HTML in
Turkish locale
Message-ID: <20130820215535.36BC748A08@hg.openjdk.java.net>
Changeset: 79e341614c50
Author: jjg
Date: 2013-08-20 14:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79e341614c50
8022080: javadoc generates invalid HTML in Turkish locale
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java
! src/share/classes/com/sun/tools/doclint/HtmlTag.java
From jonathan.gibbons at oracle.com Tue Aug 20 15:13:02 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 20 Aug 2013 22:13:02 +0000
Subject: hg: jdk8/tl/langtools: 8013887: In class use,
some tables are randomly unsorted
Message-ID: <20130820221305.33B1448A09@hg.openjdk.java.net>
Changeset: 720992953d43
Author: jjg
Date: 2013-08-20 15:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/720992953d43
8013887: In class use, some tables are randomly unsorted
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
From mike.duigou at oracle.com Tue Aug 20 17:51:30 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 21 Aug 2013 00:51:30 +0000
Subject: hg: jdk8/tl: 8023433: Improve 'make help'
Message-ID: <20130821005130.7CC5C48A18@hg.openjdk.java.net>
Changeset: c8da1b6a9762
Author: mduigou
Date: 2013-08-20 17:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8da1b6a9762
8023433: Improve 'make help'
Reviewed-by: tbell
! NewMakefile.gmk
From alan.bateman at oracle.com Wed Aug 21 02:02:07 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 21 Aug 2013 09:02:07 +0000
Subject: hg: jdk8/tl/jdk: 8023351: Add TEST.groups in preparation to simplify
rules in jdk/test/Makefile
Message-ID: <20130821090221.72AF148A34@hg.openjdk.java.net>
Changeset: eb18a483e772
Author: alanb
Date: 2013-08-21 09:59 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb18a483e772
8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile
Reviewed-by: lancea, mduigou
! test/TEST.ROOT
+ test/TEST.groups
From staffan.larsen at oracle.com Wed Aug 21 02:43:40 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 21 Aug 2013 09:43:40 +0000
Subject: hg: jdk8/tl/jdk: 4 new changesets
Message-ID: <20130821094503.9A16C48A37@hg.openjdk.java.net>
Changeset: 68be998c2596
Author: egahlin
Date: 2013-08-19 12:57 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68be998c2596
6358357: Division by zero in Threads tab when shrinking jconsole window
Reviewed-by: mchung, leifs, jbachorik
! src/share/classes/sun/tools/jconsole/Plotter.java
Changeset: bddf55211ed8
Author: egahlin
Date: 2013-08-19 16:21 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bddf55211ed8
6417721: Thread list should not allow multiple selection
Reviewed-by: alanb, jbachorik, sjiang
! src/share/classes/sun/tools/jconsole/ThreadTab.java
Changeset: 2636d337a1ed
Author: egahlin
Date: 2013-08-19 16:41 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2636d337a1ed
6800801: NPE in JConsole when using Nimbus L&F
Reviewed-by: alanb, sjiang
! src/share/classes/sun/tools/jconsole/ConnectDialog.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
Changeset: ba943fc47fc8
Author: egahlin
Date: 2013-08-19 13:11 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba943fc47fc8
7042707: Un-needed mnemonic in JConsole resource file
Reviewed-by: mfang, jbachorik
! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
From david.holmes at oracle.com Wed Aug 21 02:57:16 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Wed, 21 Aug 2013 09:57:16 +0000
Subject: hg: jdk8/tl/jdk: 8023460: OPENJDK build fails due to missing jfr.jar
Message-ID: <20130821095728.7866948A38@hg.openjdk.java.net>
Changeset: 3b8fed46b2a8
Author: dholmes
Date: 2013-08-21 05:56 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8
8023460: OPENJDK build fails due to missing jfr.jar
Reviewed-by: alanb
! makefiles/Profiles.gmk
From mark.sheppard at oracle.com Wed Aug 21 06:37:21 2013
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 21 Aug 2013 14:37:21 +0100
Subject: RFR: 8023326 [TESTBUG] java/net/CookieHandler/LocalHostCookie.java
misplaced try/finally
Message-ID: <5214C291.5050500@oracle.com>
Hi
please oblige and review the fix below to address the issue in JDK-8023326
which makes the test more robust to certain exceptions thrown.
http://cr.openjdk.java.net/~msheppar/8023326/webrev/
regards
Mark
--- old/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21 12:23:21 2013
+++ new/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21 12:23:21 2013
@@ -72,7 +72,9 @@
}
}
} finally {
- s.stopServer();
+ if (s != null) {
+ s.stopServer();
+ }
}
}
@@ -96,7 +98,9 @@
}
public void stopServer() {
- server.stop(0);
+ if (server != null) {
+ server.stop(0);
+ }
}
}
From staffan.larsen at oracle.com Wed Aug 21 08:33:42 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Wed, 21 Aug 2013 15:33:42 +0000
Subject: hg: jdk8/tl/jdk: 8023485: Remove com/sun/jdi/DoubleAgentTest.java and
com/sun/jdi/FieldWatchpoints.java from ProblemList.txt
Message-ID: <20130821153409.DC15048A46@hg.openjdk.java.net>
Changeset: 8996f47f738d
Author: sla
Date: 2013-08-21 17:19 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8996f47f738d
8023485: Remove com/sun/jdi/DoubleAgentTest.java and com/sun/jdi/FieldWatchpoints.java from ProblemList.txt
Reviewed-by: chegar, mgronlun
! test/ProblemList.txt
From kurchisubhra at gmail.com Wed Aug 21 11:23:31 2013
From: kurchisubhra at gmail.com (Kurchi Subhra Hazra)
Date: Wed, 21 Aug 2013 11:23:31 -0700
Subject: RFR: 8023326 [TESTBUG] java/net/CookieHandler/LocalHostCookie.java
misplaced try/finally
In-Reply-To: <5214C291.5050500@oracle.com>
References: <5214C291.5050500@oracle.com>
Message-ID:
I guess we could have changed class Server to implement AutoCloseable too,
but this looks fine to me.
Thanks,
- Kurchi
On Wed, Aug 21, 2013 at 6:37 AM, Mark Sheppard wrote:
> Hi
> please oblige and review the fix below to address the issue in JDK-8023326
> which makes the test more robust to certain exceptions thrown.
>
> http://cr.openjdk.java.net/~**msheppar/8023326/webrev/
>
> regards
> Mark
>
> --- old/test/java/net/**CookieHandler/LocalHostCookie.**java Wed
> Aug 21 12:23:21 2013
> +++ new/test/java/net/**CookieHandler/LocalHostCookie.**java Wed
> Aug 21 12:23:21 2013
> @@ -72,7 +72,9 @@
> }
> }
> } finally {
> - s.stopServer();
> + if (s != null) {
> + s.stopServer();
> + }
> }
> }
> @@ -96,7 +98,9 @@
> }
> public void stopServer() {
> - server.stop(0);
> + if (server != null) {
> + server.stop(0);
> + }
> }
> }
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130821/7180739e/attachment.html
From mike.duigou at oracle.com Wed Aug 21 12:49:20 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 21 Aug 2013 19:49:20 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130821194944.A99FD48A5B@hg.openjdk.java.net>
Changeset: fad3b6673159
Author: mduigou
Date: 2013-08-21 12:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fad3b6673159
8023306: Add replace() implementations to TreeMap
Reviewed-by: psandoz, alanb, chegar, bpb
! src/share/classes/java/util/TreeMap.java
Changeset: 91a31c77be5b
Author: mduigou
Date: 2013-08-21 12:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91a31c77be5b
8023395: Remove sun.misc.Sort and sun.misc.Compare
Reviewed-by: alanb, smarks, darcy, mr
- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java
From jonathan.gibbons at oracle.com Wed Aug 21 16:14:14 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 21 Aug 2013 23:14:14 +0000
Subject: hg: jdk8/tl/langtools: 8023515: import type-annotations updates
Message-ID: <20130821231417.A145A48A61@hg.openjdk.java.net>
Changeset: 7de231613e4a
Author: jjg
Date: 2013-08-21 16:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de231613e4a
8023515: import type-annotations updates
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com
! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
+ test/tools/javac/annotations/typeAnnotations/failures/DummyProcessor.java
+ test/tools/javac/annotations/typeAnnotations/failures/T8020715.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java
+ test/tools/javac/tree/TypeAnnotationsPretty.java
From jonathan.gibbons at oracle.com Wed Aug 21 17:29:36 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 22 Aug 2013 00:29:36 +0000
Subject: hg: jdk8/tl/langtools: 8022287: javac.sym.Profiles uses a static Map
when it should not
Message-ID: <20130822002939.8336848A65@hg.openjdk.java.net>
Changeset: 57e1266527dd
Author: jjg
Date: 2013-08-21 17:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/57e1266527dd
8022287: javac.sym.Profiles uses a static Map when it should not
Reviewed-by: ksrini
! src/share/classes/com/sun/tools/javac/sym/Profiles.java
+ test/tools/javac/profiles/ProfileTest.java
From xuelei.fan at oracle.com Wed Aug 21 19:46:51 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Thu, 22 Aug 2013 02:46:51 +0000
Subject: hg: jdk8/tl/jdk: 8022228: Intermittent test failures in
sun/security/ssl/javax/net/ssl/NewAPIs
Message-ID: <20130822024717.B922548A76@hg.openjdk.java.net>
Changeset: ec827a62070a
Author: xuelei
Date: 2013-08-21 19:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a
8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs
Reviewed-by: weijun
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
! test/sun/security/ssl/templates/SSLSocketTemplate.java
From staffan.larsen at oracle.com Wed Aug 21 23:29:14 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Thu, 22 Aug 2013 06:29:14 +0000
Subject: hg: jdk8/tl/jdk: 8023101:
java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails
Message-ID: <20130822062937.A47CB48A7B@hg.openjdk.java.net>
Changeset: a0896634ab46
Author: sla
Date: 2013-08-22 08:28 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0896634ab46
8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails
Reviewed-by: ysr
! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
From xuelei.fan at oracle.com Thu Aug 22 00:03:10 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 22 Aug 2013 15:03:10 +0800
Subject: hg: jdk8/tl/jdk: 8022228: Intermittent test failures in
sun/security/ssl/javax/net/ssl/NewAPIs
In-Reply-To:
References: <20130822024717.B922548A76@hg.openjdk.java.net>
Message-ID: <5215B7AE.2040406@oracle.com>
On 8/22/2013 11:37 AM, Laxmi Narayan NIT DGP wrote:
> is there are any chances of contribution for outsider of oracle and even
> student developers ??
>
Sure. Please see the following page about how to contribute:
http://openjdk.java.net/contribute/
And The OpenJDK Developers' Guide:
http://openjdk.java.net/guide/
Thanks,
Xuelei
> *
>
>
>
>
> Laxmi Narayan Patel
> *
> *
> MCA NIT Durgapur (Pre final year)
> *
> *
> mob:- 8345847473
> *
>
>
> On Thu, Aug 22, 2013 at 8:16 AM, > wrote:
>
> Changeset: ec827a62070a
> Author: xuelei
> Date: 2013-08-21 19:44 -0700
> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a
>
> 8022228: Intermittent test failures in
> sun/security/ssl/javax/net/ssl/NewAPIs
> Reviewed-by: weijun
>
> ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
> ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
> ! test/sun/security/ssl/templates/SSLSocketTemplate.java
>
>
From vicente.romero at oracle.com Thu Aug 22 02:23:48 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 22 Aug 2013 09:23:48 +0000
Subject: hg: jdk8/tl/langtools: 8022316: Generic throws,
overriding and method reference
Message-ID: <20130822092359.E724B48A80@hg.openjdk.java.net>
Changeset: 7a4717f3ea7b
Author: vromero
Date: 2013-08-22 10:22 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a4717f3ea7b
8022316: Generic throws, overriding and method reference
Reviewed-by: jjg, mcimadamore
! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.java
+ test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.out
From vicente.romero at oracle.com Thu Aug 22 05:13:31 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 22 Aug 2013 12:13:31 +0000
Subject: hg: jdk8/tl/langtools: 8023112: javac should not use lazy constant
evaluation approach for method references
Message-ID: <20130822121336.74ABE48A86@hg.openjdk.java.net>
Changeset: 25aaff78d754
Author: vromero
Date: 2013-08-22 13:12 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25aaff78d754
8023112: javac should not use lazy constant evaluation approach for method references
Reviewed-by: jjg, mcimadamore
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/T8023112/SkipLazyConstantCreationForMethodRefTest.java
From joe.darcy at oracle.com Thu Aug 22 09:41:33 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 22 Aug 2013 16:41:33 +0000
Subject: hg: jdk8/tl/jdk: 8023587: Fix lone remaining doclint issue in
java.util.regex
Message-ID: <20130822164212.2D00B48AA0@hg.openjdk.java.net>
Changeset: b7c4094be729
Author: darcy
Date: 2013-08-22 09:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7c4094be729
8023587: Fix lone remaining doclint issue in java.util.regex
Reviewed-by: jjg
! src/share/classes/java/util/regex/Pattern.java
From dan.xu at oracle.com Thu Aug 22 11:43:40 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 22 Aug 2013 18:43:40 +0000
Subject: hg: jdk8/tl/jdk: 8023430: Replace File.mkdirs with
Files.createDirectories to get MaxPathLength.java failure details
Message-ID: <20130822184414.54EE348ACC@hg.openjdk.java.net>
Changeset: 8a7d9cc2f41c
Author: dxu
Date: 2013-08-22 11:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a7d9cc2f41c
8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details
Reviewed-by: alanb
! test/ProblemList.txt
! test/java/io/File/MaxPathLength.java
From jonathan.gibbons at oracle.com Thu Aug 22 12:53:39 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 22 Aug 2013 19:53:39 +0000
Subject: hg: jdk8/tl/langtools: 8022173: Relax some warnings in doclint
Message-ID: <20130822195344.ABB5648AD2@hg.openjdk.java.net>
Changeset: b77381d99056
Author: jjg
Date: 2013-08-22 12:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b77381d99056
8022173: Relax some warnings in doclint
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclint/HtmlTag.java
! test/tools/doclint/html/ListTagsTest.java
! test/tools/doclint/html/OtherTagsTest.java
! test/tools/doclint/html/OtherTagsTest.out
! test/tools/doclint/html/TableTagsTest.java
From stuart.marks at oracle.com Thu Aug 22 15:53:20 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Thu, 22 Aug 2013 22:53:20 +0000
Subject: hg: jdk8/tl/jdk: 8022445: fix RMISocketFactory example to avoid using
localhost
Message-ID: <20130822225333.EBC9548ADD@hg.openjdk.java.net>
Changeset: 7496ec8bab76
Author: smarks
Date: 2013-08-22 15:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7496ec8bab76
8022445: fix RMISocketFactory example to avoid using localhost
Reviewed-by: chegar, alanb
! src/share/classes/java/rmi/server/RMISocketFactory.java
From staffan.larsen at oracle.com Thu Aug 22 22:55:36 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Fri, 23 Aug 2013 05:55:36 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130823055615.9B27648AE6@hg.openjdk.java.net>
Changeset: 7b6211cd8d76
Author: egahlin
Date: 2013-08-21 17:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b6211cd8d76
6417649: -interval=0 is accepted and jconsole doesn't update window content at all
Reviewed-by: alanb, jbachorik
! src/share/classes/sun/tools/jconsole/JConsole.java
Changeset: 77a32e5df365
Author: egahlin
Date: 2013-08-21 17:17 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a32e5df365
6359971: Threads tab: Simple text to explain that one can click on a thread to get stack trace
Reviewed-by: alanb, jbachorik
! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/ThreadTab.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties
From chris.hegarty at oracle.com Fri Aug 23 02:03:01 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 23 Aug 2013 09:03:01 +0000
Subject: hg: jdk8/tl/jdk: 6470700: Math.random() / Math.initRNG() uses "double
checked locking"
Message-ID: <20130823090333.C8F7F48AF2@hg.openjdk.java.net>
Changeset: 223be1d3494f
Author: bpb
Date: 2013-08-22 13:32 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/223be1d3494f
6470700: Math.random() / Math.initRNG() uses "double checked locking"
Summary: Replace class Random variable with a static final holder class
Reviewed-by: alanb, mduigou, chegar
Contributed-by: Brian Burkhalter
! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java
From chris.hegarty at oracle.com Fri Aug 23 01:58:15 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 23 Aug 2013 08:58:15 +0000
Subject: hg: jdk8/tl/jaxws: 8022885: Update JAX-WS RI integration to
2.2.9-b14140; ...
Message-ID: <20130823085819.860EF48AF0@hg.openjdk.java.net>
Changeset: b99d7e355d4b
Author: mkos
Date: 2013-08-23 09:57 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b99d7e355d4b
8022885: Update JAX-WS RI integration to 2.2.9-b14140
8013016: Rebase 8009009 against the latest jdk8/jaxws
Reviewed-by: alanb, chegar
! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeRef.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/package-info.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/EditDistance.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDEventListener.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDHandlerBase.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDParser.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EndOfInputException.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EntityDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/ExternalEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InputEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InternalEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/MessageCatalog.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/Resolver.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/SimpleHashtable.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlChars.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlNames.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlReader.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/package.html
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/resources/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreatorProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AttributesHolder.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/FragmentedArray.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBuffer.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferException.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferMark.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferResult.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferSource.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/DefaultWithLexicalHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Features.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Properties.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/txw2/output/XMLWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/ersSet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/group.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/JAXPParser.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/XSOMParser.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java
! src/share/jaxws_classes/javax/xml/bind/Binder.java
! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java
! src/share/jaxws_classes/javax/xml/bind/DataBindingException.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverter.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterInterface.java
! src/share/jaxws_classes/javax/xml/bind/Element.java
! src/share/jaxws_classes/javax/xml/bind/GetPropertyAction.java
! src/share/jaxws_classes/javax/xml/bind/JAXB.java
! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java
! src/share/jaxws_classes/javax/xml/bind/JAXBElement.java
! src/share/jaxws_classes/javax/xml/bind/JAXBException.java
! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java
! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java
! src/share/jaxws_classes/javax/xml/bind/MarshalException.java
! src/share/jaxws_classes/javax/xml/bind/Messages.java
! src/share/jaxws_classes/javax/xml/bind/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/NotIdentifiableEvent.java
! src/share/jaxws_classes/javax/xml/bind/ParseConversionEvent.java
! src/share/jaxws_classes/javax/xml/bind/PrintConversionEvent.java
! src/share/jaxws_classes/javax/xml/bind/PropertyException.java
! src/share/jaxws_classes/javax/xml/bind/SchemaOutputResolver.java
! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java
! src/share/jaxws_classes/javax/xml/bind/UnmarshalException.java
! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java
! src/share/jaxws_classes/javax/xml/bind/UnmarshallerHandler.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEvent.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEventHandler.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEventLocator.java
! src/share/jaxws_classes/javax/xml/bind/ValidationException.java
! src/share/jaxws_classes/javax/xml/bind/Validator.java
! src/share/jaxws_classes/javax/xml/bind/WhiteSpaceProcessor.java
! src/share/jaxws_classes/javax/xml/bind/annotation/DomHandler.java
! src/share/jaxws_classes/javax/xml/bind/annotation/W3CDomHandler.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessOrder.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorOrder.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyAttribute.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttachmentRef.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttribute.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementDecl.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRef.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRefs.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementWrapper.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElements.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnum.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnumValue.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlID.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlIDREF.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlList.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMixed.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNs.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNsForm.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRegistry.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRootElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchema.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaTypes.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSeeAlso.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlTransient.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlValue.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html
! src/share/jaxws_classes/javax/xml/bind/annotation/package.html
! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentMarshaller.java
! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java
! src/share/jaxws_classes/javax/xml/bind/attachment/package.html
! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java
! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.java
! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ParseConversionEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/PrintConversionEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/package.html
! src/share/jaxws_classes/javax/xml/bind/package.html
! src/share/jaxws_classes/javax/xml/bind/util/JAXBResult.java
! src/share/jaxws_classes/javax/xml/bind/util/JAXBSource.java
! src/share/jaxws_classes/javax/xml/bind/util/Messages.java
! src/share/jaxws_classes/javax/xml/bind/util/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/util/ValidationEventCollector.java
! src/share/jaxws_classes/javax/xml/bind/util/package.html
From chris.hegarty at oracle.com Fri Aug 23 03:11:40 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 23 Aug 2013 10:11:40 +0000
Subject: hg: jdk8/tl/jaxws: 8023636: Missing files from 8022885
Message-ID: <20130823101142.65C0348AF4@hg.openjdk.java.net>
Changeset: d8593d8581df
Author: mkos
Date: 2013-08-23 11:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d8593d8581df
8023636: Missing files from 8022885
Reviewed-by: alanb, chegar
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/StreamingSOAP.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamespaceContextExAdaper.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLReaderComposite.java
From daniel.fuchs at oracle.com Fri Aug 23 12:02:10 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Fri, 23 Aug 2013 19:02:10 +0000
Subject: hg: jdk8/tl/jdk: 8005899: Logger.getLogger(name,
null) should not allow to reset a non-null resource bundle
Message-ID: <20130823190232.AE95C48B16@hg.openjdk.java.net>
Changeset: 4ef82445ea20
Author: dfuchs
Date: 2013-08-23 20:59 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ef82445ea20
8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle
Reviewed-by: mchung, lancea
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/Logger/getLogger/TestLogger.java
+ test/java/util/logging/Logger/getLogger/testlogger/MyResource.java
From alan.bateman at oracle.com Sat Aug 24 13:11:53 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 24 Aug 2013 20:11:53 +0000
Subject: hg: jdk8/tl/jdk: 6378503: In java.math.BigDecimal, division by one
returns zero; ...
Message-ID: <20130824201246.F01CE48B32@hg.openjdk.java.net>
Changeset: 216a4b93cee8
Author: bpb
Date: 2013-08-23 14:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/216a4b93cee8
6378503: In java.math.BigDecimal, division by one returns zero
6446965: Using BigDecimal.divideToIntegralValue with extreme scales can lead to an incorrect result
Summary: Fix overflow of ints and ensure appropriate values passed to checkScaleNonZero()
Reviewed-by: darcy, martin
Contributed-by: Brian Burkhalter
! src/share/classes/java/math/BigDecimal.java
! src/share/classes/java/math/BigInteger.java
! test/java/math/BigDecimal/IntegralDivisionTests.java
From chris.hegarty at oracle.com Sun Aug 25 01:31:38 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 25 Aug 2013 09:31:38 +0100
Subject: RFR: 8023326 [TESTBUG] java/net/CookieHandler/LocalHostCookie.java
misplaced try/finally
In-Reply-To: <5214C291.5050500@oracle.com>
References: <5214C291.5050500@oracle.com>
Message-ID: <5219C0EA.9030605@oracle.com>
Looks ok to me Mark.
-Chris.
On 08/21/2013 02:37 PM, Mark Sheppard wrote:
> Hi
> please oblige and review the fix below to address the issue in JDK-8023326
> which makes the test more robust to certain exceptions thrown.
>
> http://cr.openjdk.java.net/~msheppar/8023326/webrev/
>
> regards
> Mark
>
> --- old/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21
> 12:23:21 2013
> +++ new/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21
> 12:23:21 2013
> @@ -72,7 +72,9 @@
> }
> }
> } finally {
> - s.stopServer();
> + if (s != null) {
> + s.stopServer();
> + }
> }
> }
>
> @@ -96,7 +98,9 @@
> }
>
> public void stopServer() {
> - server.stop(0);
> + if (server != null) {
> + server.stop(0);
> + }
> }
> }
>
>
>
From alan.bateman at oracle.com Mon Aug 26 02:04:09 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 26 Aug 2013 09:04:09 +0000
Subject: hg: jdk8/tl/jdk: 8023139:
java/nio/file/WatchService/SensitivityModifier.java failing
intermittently (win8)
Message-ID: <20130826090449.47C6448B54@hg.openjdk.java.net>
Changeset: 0ee3b995d63b
Author: alanb
Date: 2013-08-26 10:01 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ee3b995d63b
8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8)
Reviewed-by: alanb
Contributed-by: yiming.wang at oracle.com
! test/java/nio/file/WatchService/SensitivityModifier.java
From alan.bateman at oracle.com Mon Aug 26 03:35:06 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 26 Aug 2013 10:35:06 +0000
Subject: hg: jdk8/tl/jdk: 7129312: BufferedInputStream calculates negative
array size with large streams and mark
Message-ID: <20130826103531.1189748B56@hg.openjdk.java.net>
Changeset: 67a1a031876a
Author: igerasim
Date: 2013-08-25 23:20 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67a1a031876a
7129312: BufferedInputStream calculates negative array size with large streams and mark
Reviewed-by: alanb
! src/share/classes/java/io/BufferedInputStream.java
+ test/java/io/BufferedInputStream/LargeCopyWithMark.java
From paul.sandoz at oracle.com Mon Aug 26 07:20:29 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 26 Aug 2013 14:20:29 +0000
Subject: hg: jdk8/tl/jdk: 8023234: StampedLock serializes readers on writer
unlock
Message-ID: <20130826142104.159D148B60@hg.openjdk.java.net>
Changeset: 8a36fc7f494c
Author: shade
Date: 2013-08-26 17:50 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a36fc7f494c
8023234: StampedLock serializes readers on writer unlock
Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock
Reviewed-by: martin, shade
Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java
From roger.riggs at oracle.com Mon Aug 26 09:00:48 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Mon, 26 Aug 2013 16:00:48 +0000
Subject: hg: jdk8/tl/jdk: 8011944: Sort fails with
ArrayIndexOutOfBoundsException
Message-ID: <20130826160109.BC73D48B69@hg.openjdk.java.net>
Changeset: 07585a2483fa
Author: rriggs
Date: 2013-08-26 11:46 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07585a2483fa
8011944: Sort fails with ArrayIndexOutOfBoundsException
Summary: Increase the size of pending stack and add test cases
Reviewed-by: alanb
! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/TimSort.java
+ test/java/util/Arrays/TimSortStackSize.java
From sean.coffey at oracle.com Mon Aug 26 10:34:36 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Mon, 26 Aug 2013 17:34:36 +0000
Subject: hg: jdk8/tl/jdk: 8016018: Typo in AbstractStringBuilder#indexOf and
#lastIndexOf descriptions
Message-ID: <20130826173447.BBEA048B6F@hg.openjdk.java.net>
Changeset: 92a66af7f834
Author: igerasim
Date: 2013-08-26 18:26 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92a66af7f834
8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions
Reviewed-by: alanb, chegar
! src/share/classes/java/lang/AbstractStringBuilder.java
From mike.duigou at oracle.com Mon Aug 26 11:38:22 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Mon, 26 Aug 2013 18:38:22 +0000
Subject: hg: jdk8/tl: 8023491: Remove target names from test/Makefile and
defer to sub-repo makefiles.
Message-ID: <20130826183822.7C91C48B79@hg.openjdk.java.net>
Changeset: f643fee2b40f
Author: mduigou
Date: 2013-08-26 10:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/f643fee2b40f
8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.
Reviewed-by: erikj
! common/makefiles/Main.gmk
! test/Makefile
From jonathan.gibbons at oracle.com Mon Aug 26 11:49:13 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 26 Aug 2013 18:49:13 +0000
Subject: hg: jdk8/tl/langtools: 8023701: Fix badly named test
Message-ID: <20130826184916.B9D5B48B7B@hg.openjdk.java.net>
Changeset: 60f156c653d3
Author: jjg
Date: 2013-08-26 11:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/60f156c653d3
8023701: Fix badly named test
Reviewed-by: bpatel
- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
+ test/com/sun/javadoc/testNavigation/TestNavigation.java
+ test/com/sun/javadoc/testNavigation/pkg/A.java
+ test/com/sun/javadoc/testNavigation/pkg/C.java
+ test/com/sun/javadoc/testNavigation/pkg/E.java
+ test/com/sun/javadoc/testNavigation/pkg/I.java
From paul.sandoz at oracle.com Mon Aug 26 13:55:36 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Mon, 26 Aug 2013 20:55:36 +0000
Subject: hg: jdk8/tl/jdk: 8020292: j.u.SplittableRandom
Message-ID: <20130826205600.268B448B83@hg.openjdk.java.net>
Changeset: 5ce9025c9e1a
Author: psandoz
Date: 2013-08-26 22:55 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ce9025c9e1a
8020292: j.u.SplittableRandom
Reviewed-by: mduigou
Contributed-by: Guy Steele , Doug Lea , Brian Goetz , Paul Sandoz
+ src/share/classes/java/util/SplittableRandom.java
+ test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java
From jonathan.gibbons at oracle.com Mon Aug 26 15:56:30 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Mon, 26 Aug 2013 22:56:30 +0000
Subject: hg: jdk8/tl/langtools: 8023768: Use the unannotatedType in cyclicity
checks.
Message-ID: <20130826225633.9D81D48B89@hg.openjdk.java.net>
Changeset: 7bf6313e1ced
Author: jjg
Date: 2013-08-26 15:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bf6313e1ced
8023768: Use the unannotatedType in cyclicity checks.
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java
From david.holmes at oracle.com Mon Aug 26 17:12:08 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Tue, 27 Aug 2013 00:12:08 +0000
Subject: hg: jdk8/tl/jdk: 8014135: The JVMTI specification does not conform to
recent changes in JNI specification
Message-ID: <20130827001233.54B4148B8C@hg.openjdk.java.net>
Changeset: 9586ca82bd8b
Author: bpittore
Date: 2013-08-26 11:27 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9586ca82bd8b
8014135: The JVMTI specification does not conform to recent changes in JNI specification
Summary: Added support for statically linked agents
Reviewed-by: alanb, sspitsyn, bobv, coleenp
! src/share/classes/com/sun/tools/attach/VirtualMachine.java
From lana.steuck at oracle.com Mon Aug 26 22:20:16 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:16 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20130827052022.CF0A448BA2@hg.openjdk.java.net>
Changeset: d411c60a8c2f
Author: cl
Date: 2013-08-15 09:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d411c60a8c2f
Added tag jdk8-b103 for changeset 49c4a777fdfd
! .hgtags
Changeset: 4e38de7c767e
Author: cl
Date: 2013-08-22 09:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4e38de7c767e
Added tag jdk8-b104 for changeset d411c60a8c2f
! .hgtags
From lana.steuck at oracle.com Mon Aug 26 22:20:26 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:26 +0000
Subject: hg: jdk8/tl: 9 new changesets
Message-ID: <20130827052027.B374E48BA3@hg.openjdk.java.net>
Changeset: ceefd94ef326
Author: cl
Date: 2013-08-15 09:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/ceefd94ef326
Added tag jdk8-b103 for changeset b7e64be81c8a
! .hgtags
Changeset: 4fb877dfe5c4
Author: erikj
Date: 2013-08-15 17:14 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/4fb877dfe5c4
8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory
Reviewed-by: tbell
! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
Changeset: f10f673d9b17
Author: igerasim
Date: 2013-08-16 14:43 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/f10f673d9b17
8023156: make dist-clean should remove javacservers directory
Reviewed-by: erikj
! common/makefiles/Main.gmk
Changeset: dadf49495ab4
Author: erikj
Date: 2013-08-19 10:31 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/dadf49495ab4
8021430: 64 bit JDK build fails on windows 7 due to missing corba source files
Reviewed-by: tbell, katleman
! common/makefiles/IdlCompilation.gmk
Changeset: 96c1b9b7524b
Author: katleman
Date: 2013-08-20 15:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/96c1b9b7524b
Merge
Changeset: c3b5197f2851
Author: cl
Date: 2013-08-22 09:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/c3b5197f2851
Added tag jdk8-b104 for changeset 96c1b9b7524b
! .hgtags
Changeset: e8a3edda1f60
Author: lana
Date: 2013-08-20 17:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/e8a3edda1f60
Merge
Changeset: 056398db9dcb
Author: lana
Date: 2013-08-23 14:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/056398db9dcb
Merge
! common/autoconf/generated-configure.sh
Changeset: 163091288aeb
Author: lana
Date: 2013-08-26 14:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/163091288aeb
Merge
! common/makefiles/Main.gmk
From lana.steuck at oracle.com Mon Aug 26 22:20:31 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:31 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20130827052056.027AB48BA4@hg.openjdk.java.net>
Changeset: a22fe9bd01e6
Author: cl
Date: 2013-08-15 09:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a22fe9bd01e6
Added tag jdk8-b103 for changeset b1ceab582fc6
! .hgtags
Changeset: af28b93bfb6f
Author: cl
Date: 2013-08-22 09:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/af28b93bfb6f
Added tag jdk8-b104 for changeset a22fe9bd01e6
! .hgtags
Changeset: d4d6422ec564
Author: lana
Date: 2013-08-20 17:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d4d6422ec564
Merge
Changeset: 09a46ec11f88
Author: lana
Date: 2013-08-23 14:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/09a46ec11f88
Merge
From lana.steuck at oracle.com Mon Aug 26 22:20:35 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:35 +0000
Subject: hg: jdk8/tl/jaxws: 3 new changesets
Message-ID: <20130827052056.7DA8C48BA5@hg.openjdk.java.net>
Changeset: 42211ab0ab1c
Author: cl
Date: 2013-08-15 09:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/42211ab0ab1c
Added tag jdk8-b103 for changeset 6cdc6ed98780
! .hgtags
Changeset: 88390df7ed2c
Author: cl
Date: 2013-08-22 09:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88390df7ed2c
Added tag jdk8-b104 for changeset 42211ab0ab1c
! .hgtags
Changeset: 533c1032337c
Author: lana
Date: 2013-08-26 14:50 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/533c1032337c
Merge
From lana.steuck at oracle.com Mon Aug 26 22:20:46 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:46 +0000
Subject: hg: jdk8/tl/nashorn: 5 new changesets
Message-ID: <20130827052057.0813148BA6@hg.openjdk.java.net>
Changeset: afc100513451
Author: cl
Date: 2013-08-15 09:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/afc100513451
Added tag jdk8-b103 for changeset 414203de4374
! .hgtags
Changeset: 74244f43c577
Author: cl
Date: 2013-08-22 09:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/74244f43c577
Added tag jdk8-b104 for changeset afc100513451
! .hgtags
Changeset: 1f2394beecf7
Author: lana
Date: 2013-08-20 17:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1f2394beecf7
Merge
- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java
Changeset: f484bfb624dd
Author: lana
Date: 2013-08-23 14:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f484bfb624dd
Merge
- src/jdk/internal/dynalink/support/Backport.java
- src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/MapIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java
Changeset: a18f92a0a910
Author: lana
Date: 2013-08-26 14:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a18f92a0a910
Merge
From lana.steuck at oracle.com Mon Aug 26 22:20:47 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:47 +0000
Subject: hg: jdk8/tl/langtools: 6 new changesets
Message-ID: <20130827052114.E6B9448BA7@hg.openjdk.java.net>
Changeset: dd4a00c220c6
Author: cl
Date: 2013-08-15 09:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd4a00c220c6
Added tag jdk8-b103 for changeset 76cfe7c61f25
! .hgtags
Changeset: f2ee3a4e7927
Author: cl
Date: 2013-08-22 09:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f2ee3a4e7927
Added tag jdk8-b104 for changeset dd4a00c220c6
! .hgtags
Changeset: b59a0b4675c9
Author: lana
Date: 2013-08-20 17:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b59a0b4675c9
Merge
- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
Changeset: 375834b5cf08
Author: lana
Date: 2013-08-23 14:17 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/375834b5cf08
Merge
- test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java
- test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
Changeset: 00ca54ceca1b
Author: lana
Date: 2013-08-26 14:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/00ca54ceca1b
Merge
Changeset: cc3fb73f5e08
Author: lana
Date: 2013-08-26 22:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc3fb73f5e08
Merge
From lana.steuck at oracle.com Mon Aug 26 22:20:56 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:20:56 +0000
Subject: hg: jdk8/tl/hotspot: 32 new changesets
Message-ID: <20130827052233.5940E48BA8@hg.openjdk.java.net>
Changeset: 0bbd1c775bef
Author: cl
Date: 2013-08-15 09:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bbd1c775bef
Added tag jdk8-b103 for changeset 6f9be7f87b96
! .hgtags
Changeset: 39127bb12d32
Author: amurillo
Date: 2013-08-09 01:39 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39127bb12d32
8022688: new hotspot build - hs25-b46
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: ca0165daa6ec
Author: sspitsyn
Date: 2013-08-06 16:33 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0165daa6ec
7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments
Summary: Restore the appendix argument after PopFrame() call
Reviewed-by: twisti, coleenp
Contributed-by: serguei.spitsyn at oracle.com
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
Changeset: c54a3122f9c8
Author: omajid
Date: 2013-08-06 12:28 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c54a3122f9c8
8022188: Make zero compile after 8016131 and 8016697
Reviewed-by: dholmes, twisti
! src/cpu/zero/vm/entryFrame_zero.hpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/stubGenerator_zero.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
Changeset: 196aa14f9f29
Author: dholmes
Date: 2013-08-06 21:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/196aa14f9f29
Merge
Changeset: 195ff07bc7f6
Author: dsamersoff
Date: 2013-08-07 19:02 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/195ff07bc7f6
8021771: warning stat64 is deprecated - when building on OSX 10.7.5
Summary: stat64 have to be replaced with stat
Reviewed-by: dholmes, kmo
Contributed-by: rednaxelafx at gmail.com
! src/os/bsd/vm/attachListener_bsd.cpp
Changeset: 31f3b1e1c5e5
Author: dcubed
Date: 2013-08-08 09:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f3b1e1c5e5
8016601: Unable to build hsx24 on Windows using project creator and Visual Studio
Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups.
Reviewed-by: rdurbin, coleenp
! make/windows/create.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/trace.make
! make/windows/makefiles/vm.make
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java
Changeset: c661fa2e5189
Author: iklam
Date: 2013-08-08 14:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c661fa2e5189
8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10
Summary: Added extra help message in make/solaris/makefiles/dtrace.make
Reviewed-by: dholmes, sspitsyn
! make/solaris/makefiles/dtrace.make
Changeset: 57ac7245594c
Author: minqi
Date: 2013-08-08 15:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57ac7245594c
8019583: [TESTBUG] runtime/7107135 always passes
Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable.
Reviewed-by: coleenp, dholmes, iklam
Contributed-by: yumin.qi at oracle.com
! test/runtime/7107135/Test7107135.sh
Changeset: 6222a021d582
Author: minqi
Date: 2013-08-08 20:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6222a021d582
Merge
Changeset: 98aa538fd97e
Author: mikael
Date: 2013-08-09 09:51 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98aa538fd97e
8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2
Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup
Reviewed-by: coleenp, dsamersoff
! src/os/windows/vm/os_windows.cpp
Changeset: ed7c17e7d45b
Author: dcubed
Date: 2013-08-09 13:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed7c17e7d45b
Merge
Changeset: 7b03590c334b
Author: dcubed
Date: 2013-08-09 15:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b03590c334b
Merge
Changeset: bd0e82136b03
Author: iklam
Date: 2013-08-10 10:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd0e82136b03
8022740: Visual 2008 IDE build is broken
Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1.
Reviewed-by: dcubed, ccheung
! make/windows/projectfiles/common/Makefile
! src/share/tools/ProjectCreator/FileTreeCreator.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java
Changeset: 85147f28faba
Author: coleenp
Date: 2013-08-12 17:24 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85147f28faba
8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32
Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore
Reviewed-by: sspitsyn, dcubed, mseledtsov
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! test/runtime/RedefineObject/Agent.java
! test/runtime/RedefineObject/TestRedefineObject.java
+ test/runtime/RedefineObject/WalkThroughInvoke.java
Changeset: d1034bd8cefc
Author: adlertz
Date: 2013-08-07 17:56 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1034bd8cefc
8022284: Hide internal data structure in PhaseCFG
Summary: Hide private node to block mapping using public interface
Reviewed-by: kvn, roland
! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/output.hpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/vmStructs.cpp
Changeset: ce8969c36762
Author: adlertz
Date: 2013-08-07 18:04 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce8969c36762
8022475: Remove unneeded ad-files
Summary: Remove .ad files that are not used
Reviewed-by: kvn
! make/bsd/makefiles/adlc.make
! make/linux/makefiles/adlc.make
! make/solaris/makefiles/adlc.make
! make/windows/makefiles/adlc.make
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad
Changeset: 5394ec69f112
Author: rbackman
Date: 2013-08-09 18:05 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5394ec69f112
Merge
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad
Changeset: 11237ee74aae
Author: iignatyev
Date: 2013-08-10 10:01 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11237ee74aae
8019915: whitebox testClearMethodStateTest fails with tiered on sparc
Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test
Reviewed-by: kvn
! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java
Changeset: bcc4f6f54d83
Author: kvn
Date: 2013-08-14 10:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcc4f6f54d83
8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag
Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag.
Reviewed-by: roland
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/loopTransform.cpp
Changeset: 56b94e55267a
Author: rbackman
Date: 2013-08-15 15:26 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56b94e55267a
Merge
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad
Changeset: 9766f73e770d
Author: stefank
Date: 2013-05-31 14:32 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9766f73e770d
8022880: False sharing between PSPromotionManager instances
Summary: Pad the PSPromotionManager instances in the manager array.
Reviewed-by: brutisso, jmasa
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parNew/parOopClosures.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
+ src/share/vm/memory/padded.hpp
+ src/share/vm/memory/padded.inline.hpp
! src/share/vm/utilities/debug.hpp
! src/share/vm/utilities/globalDefinitions.hpp
Changeset: 330dfb0476f4
Author: brutisso
Date: 2013-08-14 09:02 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/330dfb0476f4
8022800: Use specific generations rather than generation iteration
Reviewed-by: jmasa, ehelin
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp
Changeset: 3f22cbf5275d
Author: brutisso
Date: 2013-08-14 10:55 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f22cbf5275d
Merge
Changeset: 5d9995d16b26
Author: ehelin
Date: 2013-08-14 13:49 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d9995d16b26
8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining
Reviewed-by: coleenp, mgerdin
! src/share/vm/utilities/exceptions.hpp
Changeset: bd902affe102
Author: brutisso
Date: 2013-08-15 10:05 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd902affe102
8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013
Reviewed-by: stefank, ehelin
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/genRemSet.hpp
Changeset: 274ce305e5b9
Author: ehelin
Date: 2013-08-13 18:16 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/274ce305e5b9
8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0
Reviewed-by: stefank, brutisso, sjohanss
! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp
Changeset: 33d39b75663f
Author: ehelin
Date: 2013-08-15 06:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33d39b75663f
Merge
Changeset: 5a62937e55b3
Author: brutisso
Date: 2013-08-16 09:02 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a62937e55b3
Merge
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad
Changeset: 580430d131cc
Author: amurillo
Date: 2013-08-16 04:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/580430d131cc
Merge
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad
Changeset: 104743074675
Author: amurillo
Date: 2013-08-16 04:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/104743074675
Added tag hs25-b46 for changeset 580430d131cc
! .hgtags
Changeset: c93e0a210e1b
Author: cl
Date: 2013-08-22 09:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c93e0a210e1b
Added tag jdk8-b104 for changeset 104743074675
! .hgtags
From lana.steuck at oracle.com Mon Aug 26 22:22:10 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 27 Aug 2013 05:22:10 +0000
Subject: hg: jdk8/tl/jdk: 23 new changesets
Message-ID: <20130827052721.2B1BC48BA9@hg.openjdk.java.net>
Changeset: f1d8d15bfcb5
Author: cl
Date: 2013-08-15 09:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1d8d15bfcb5
Added tag jdk8-b103 for changeset e0f6039c0290
! .hgtags
Changeset: c982f579b67e
Author: cl
Date: 2013-08-22 09:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c982f579b67e
Added tag jdk8-b104 for changeset f1d8d15bfcb5
! .hgtags
Changeset: 2722f4000b65
Author: jgodinez
Date: 2013-08-15 11:56 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2722f4000b65
8023045: [MacOSX] PrinterIOException when printing a JComponent
Reviewed-by: bae, jchen
! src/share/classes/sun/print/PSPrinterJob.java
Changeset: b44ce67c0565
Author: vadim
Date: 2013-08-16 15:57 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b44ce67c0565
8013446: [parfait] Memory leak in jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
Reviewed-by: bae, prr
! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
Changeset: dadd43e02a79
Author: prr
Date: 2013-08-19 03:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dadd43e02a79
8017580: Crash in font loading code on Linux (due to use of reflection)
Reviewed-by: bae, vadim
! src/share/native/sun/font/sunFont.c
! src/share/native/sun/font/sunfontids.h
Changeset: 0c950b2be7ab
Author: jgodinez
Date: 2013-08-19 11:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c950b2be7ab
8022241: [macosx] [PIT] lookupPrintServices() returns one too long array
Reviewed-by: prr, jchen
! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
Changeset: 64be71ae6185
Author: lana
Date: 2013-08-20 17:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64be71ae6185
Merge
Changeset: 903a279f1fce
Author: ant
Date: 2013-08-09 05:20 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/903a279f1fce
8013611: Modal dialog fails to obtain keyboard focus
Reviewed-by: leonidr
! src/share/classes/java/awt/KeyboardFocusManager.java
+ test/java/awt/Focus/8013611/JDK8013611.java
Changeset: 2cd1a041381b
Author: alexsch
Date: 2013-08-09 14:16 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cd1a041381b
7121409: Two conformance tests for AccessibleText.getCharacterBounds(int i) fail
Reviewed-by: serb
! src/share/classes/javax/swing/JLabel.java
Changeset: 4702ab74b70a
Author: serb
Date: 2013-08-13 15:41 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4702ab74b70a
7027045: (doc) java/awt/Window.java has several typos in javadoc
Reviewed-by: art, serb
Contributed-by: konstantin.perikov at gmail.com
! src/share/classes/java/awt/Window.java
Changeset: 149bf2400fa1
Author: lana
Date: 2013-08-13 15:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/149bf2400fa1
Merge
- test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java
- test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
Changeset: c5db3ec83cba
Author: pchelko
Date: 2013-08-14 16:17 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5db3ec83cba
8013454: [parfait] Memory leak in jdk/src/windows/native/sun/windows/awt_Cursor.cpp
8012079: [parfait] possible null pointer dereference in jdk/src/windows/native/sun/windows/awt_Font.cpp
Reviewed-by: art, serb
! src/windows/native/sun/windows/awt_Cursor.cpp
! src/windows/native/sun/windows/awt_Font.cpp
Changeset: 1d6ce0070fd3
Author: pchelko
Date: 2013-08-14 17:20 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d6ce0070fd3
7173464: Clipboard.getAvailableDataFlavors: Comparison method violates contract
Reviewed-by: anthony, art, serb
! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
+ test/sun/awt/datatransfer/DataFlavorComparatorTest.java
Changeset: 3930a827160a
Author: leonidr
Date: 2013-08-15 01:17 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3930a827160a
8022997: [macosx] Remaining duplicated key events
Reviewed-by: anthony, serb
! src/macosx/native/sun/awt/CMenuItem.m
! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java
Changeset: d7a34d7e7f22
Author: alitvinov
Date: 2013-08-15 14:20 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7a34d7e7f22
7191018: Manual test closed/java/awt/JAWT causes JVM to crash starting from JDK 5
Reviewed-by: anthony, serb
! src/solaris/native/sun/awt/awt_DrawingSurface.c
Changeset: c089e93e6444
Author: serb
Date: 2013-08-16 16:52 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c089e93e6444
8020051: [TEST_BUG] Testcase for 8004859 has a typo
Reviewed-by: anthony
! test/java/awt/Graphics2D/Test8004859/Test8004859.java
Changeset: e3316cd6ca47
Author: serb
Date: 2013-08-16 20:56 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3316cd6ca47
8006085: [findbugs] a warning on javax.sound.sampled.DataLine$Info constructor
Reviewed-by: art, prr
! src/share/classes/javax/sound/sampled/DataLine.java
Changeset: 64dc24e0d577
Author: serb
Date: 2013-08-16 21:18 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64dc24e0d577
8005980: [findbugs] More com.sun.media.sound.* warnings
Reviewed-by: art, prr
! src/share/classes/com/sun/media/sound/DataPusher.java
! src/share/classes/com/sun/media/sound/ModelStandardDirector.java
! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/SoftMixingClip.java
! src/share/classes/sun/audio/AudioData.java
Changeset: fefa29e15a14
Author: lana
Date: 2013-08-20 17:38 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fefa29e15a14
Merge
Changeset: a79fcf53195f
Author: lana
Date: 2013-08-20 17:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79fcf53195f
Merge
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java
Changeset: 9626ba160e3d
Author: lana
Date: 2013-08-23 14:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9626ba160e3d
Merge
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/java/util/jar/UnsupportedProfileException.java
- src/share/classes/sun/security/provider/ConfigSpiFile.java
- test/java/net/URLClassLoader/profiles/Basic.java
- test/java/net/URLClassLoader/profiles/Lib.java
- test/java/net/URLClassLoader/profiles/basic.sh
- test/tools/jar/AddAndUpdateProfile.java
- test/tools/launcher/profiles/Basic.java
- test/tools/launcher/profiles/Logging.java
- test/tools/launcher/profiles/Main.java
- test/tools/launcher/profiles/VersionCheck.java
Changeset: c58e39bb5d62
Author: lana
Date: 2013-08-26 14:53 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c58e39bb5d62
Merge
Changeset: 6cdc679e3412
Author: lana
Date: 2013-08-26 22:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cdc679e3412
Merge
From weijun.wang at oracle.com Tue Aug 27 02:51:22 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 27 Aug 2013 09:51:22 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130827095225.1083C48BB4@hg.openjdk.java.net>
Changeset: ca53110f1c74
Author: weijun
Date: 2013-08-27 17:50 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca53110f1c74
8015669: KerberosPrincipal::equals should ignore name-type
Reviewed-by: mullan
! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
+ test/sun/security/krb5/auto/KPEquals.java
Changeset: 4bddc344848e
Author: weijun
Date: 2013-08-27 17:50 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bddc344848e
8022761: regression: SecurityException is NOT thrown while trying to pack a wrongly signed Indexed Jar file
Reviewed-by: sherman
! src/share/classes/java/util/jar/JarVerifier.java
+ test/sun/security/tools/jarsigner/jvindex.sh
From sean.mullan at oracle.com Tue Aug 27 07:47:34 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 27 Aug 2013 14:47:34 +0000
Subject: hg: jdk8/tl/jdk: 8023769: JDK-8016850 broke the old build
Message-ID: <20130827144802.7A91E48BC4@hg.openjdk.java.net>
Changeset: 134283a88499
Author: mullan
Date: 2013-08-27 10:46 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/134283a88499
8023769: JDK-8016850 broke the old build
Summary: remove files that were moved/removed from com/sun/security/auth/FILES_java.gmk
Reviewed-by: chegar, xuelei
! make/com/sun/security/auth/FILES_java.gmk
From sean.mullan at oracle.com Tue Aug 27 10:00:32 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Tue, 27 Aug 2013 17:00:32 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130827170114.3E4EF48BD4@hg.openjdk.java.net>
Changeset: 6a1bfcde4d4d
Author: mullan
Date: 2013-08-27 12:04 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a1bfcde4d4d
8019830: Add com.sun.media.sound to the list of restricted package
Reviewed-by: vinnie
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/java/lang/SecurityManager/CheckPackageAccess.java
Changeset: 3575263eefab
Author: mullan
Date: 2013-08-27 12:27 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3575263eefab
Merge
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java
From joe.darcy at oracle.com Tue Aug 27 11:46:44 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 27 Aug 2013 18:46:44 +0000
Subject: hg: jdk8/tl/jdk: 8023827: Fix doclint issues in javax.net.ssl
Message-ID: <20130827184707.54C9948BE2@hg.openjdk.java.net>
Changeset: 51151b440e95
Author: darcy
Date: 2013-08-27 11:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51151b440e95
8023827: Fix doclint issues in javax.net.ssl
Reviewed-by: wetmore, xuelei
! src/share/classes/javax/net/ssl/SNIHostName.java
! src/share/classes/javax/net/ssl/X509KeyManager.java
From joe.darcy at oracle.com Tue Aug 27 11:59:39 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 27 Aug 2013 18:59:39 +0000
Subject: hg: jdk8/tl/langtools: 8023826: Typo in warning about obsolete source
/ target values
Message-ID: <20130827185942.4591C48BE3@hg.openjdk.java.net>
Changeset: 662a5188bded
Author: darcy
Date: 2013-08-27 11:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/662a5188bded
8023826: Typo in warning about obsolete source / target values
Reviewed-by: jjg, wmdietl
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
From xueming.shen at oracle.com Tue Aug 27 12:51:41 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Tue, 27 Aug 2013 19:51:41 +0000
Subject: hg: jdk8/tl/jdk: 8023647: "abc1c".matches("(\\w)+1\\1")) returns false
Message-ID: <20130827195214.B335F48BEF@hg.openjdk.java.net>
Changeset: 3f6777cbfe69
Author: sherman
Date: 2013-08-27 12:54 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f6777cbfe69
8023647: "abc1c".matches("(\\w)+1\\1")) returns false
Summary: to correct the wrong GroupCurly group index backoff code
Reviewed-by: alanb
! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java
From alan.bateman at oracle.com Wed Aug 28 07:33:51 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 28 Aug 2013 14:33:51 +0000
Subject: hg: jdk8/tl/jdk: 8023717: (process) ProcessBuilder should catch
SecurityException rather than AccessControlException
Message-ID: <20130828143416.D038248C29@hg.openjdk.java.net>
Changeset: 2efa310226f7
Author: alanb
Date: 2013-08-28 14:07 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2efa310226f7
8023717: (process) ProcessBuilder should catch SecurityException rather than AccessControlException
Reviewed-by: wetmore, alanb
Contributed-by: martinrb at google.com
! src/share/classes/java/lang/ProcessBuilder.java
From alan.bateman at oracle.com Wed Aug 28 07:53:08 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 28 Aug 2013 14:53:08 +0000
Subject: hg: jdk8/tl/jdk: 8022594: Potential deadlock in of
sun.nio.ch.Util/IOUtil
Message-ID: <20130828145330.265AB48C2B@hg.openjdk.java.net>
Changeset: 378acd4d03c8
Author: alanb
Date: 2013-08-28 15:50 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/378acd4d03c8
8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil
Reviewed-by: chegar
! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java
! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java
! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPoll.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollPort.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
! src/solaris/classes/sun/nio/ch/KQueue.java
! src/solaris/classes/sun/nio/ch/KQueuePort.java
! src/solaris/classes/sun/nio/ch/NativeThread.java
! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/windows/classes/sun/nio/ch/DatagramDispatcher.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
! src/windows/classes/sun/nio/ch/FileKey.java
! src/windows/classes/sun/nio/ch/Iocp.java
! src/windows/classes/sun/nio/ch/PipeImpl.java
! src/windows/classes/sun/nio/ch/SocketDispatcher.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
From xueming.shen at oracle.com Wed Aug 28 09:43:58 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 28 Aug 2013 16:43:58 +0000
Subject: hg: jdk8/tl/jdk: 8023713: ZipFileSystem crashes on old zip file
Message-ID: <20130828164438.79F9A6236B@hg.openjdk.java.net>
Changeset: 690b2931baef
Author: sherman
Date: 2013-08-28 09:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/690b2931baef
8023713: ZipFileSystem crashes on old zip file
Summary: to handle extra data field copy correctly even the extra data does not follow the spec
Reviewed-by: alanb, martin, chegar
! src/share/classes/java/util/zip/ZipOutputStream.java
! test/java/util/zip/TestExtraTime.java
From paul.sandoz at oracle.com Wed Aug 28 13:13:49 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 28 Aug 2013 20:13:49 +0000
Subject: hg: jdk8/tl/jdk: 8023155: Ensure functional consistency across Random,
ThreadLocalRandom, SplittableRandom
Message-ID: <20130828201419.3B4096237E@hg.openjdk.java.net>
Changeset: b1f41565b806
Author: psandoz
Date: 2013-08-28 22:11 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f41565b806
8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom
Reviewed-by: mduigou
Contributed-by: Doug Lea , Paul Sandoz
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/Random/RandomStreamTest.java
+ test/java/util/Random/RandomTest.java
! test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java
From jonathan.gibbons at oracle.com Wed Aug 28 15:41:21 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 28 Aug 2013 22:41:21 +0000
Subject: hg: jdk8/tl/langtools: 8010310: [javadoc] Error processing sources
with -private
Message-ID: <20130828224126.38AC562385@hg.openjdk.java.net>
Changeset: 189942cdf585
Author: jjg
Date: 2013-08-28 15:40 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/189942cdf585
8010310: [javadoc] Error processing sources with -private
Reviewed-by: vromero, mcimadamore
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
+ test/tools/javadoc/nonConstExprs/Test.java
From staffan.larsen at oracle.com Thu Aug 29 02:26:05 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Thu, 29 Aug 2013 09:26:05 +0000
Subject: hg: jdk8/tl/jdk: 8023786: (jdk) setjmp/longjmp changes the process
signal mask on OS X
Message-ID: <20130829093110.91F276239C@hg.openjdk.java.net>
Changeset: 779ff9f3b2e3
Author: sla
Date: 2013-08-29 11:22 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/779ff9f3b2e3
8023786: (jdk) setjmp/longjmp changes the process signal mask on OS X
Reviewed-by: dholmes
! src/share/back/SDE.c
! src/share/native/common/check_code.c
From xuelei.fan at oracle.com Thu Aug 29 05:46:51 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 29 Aug 2013 20:46:51 +0800
Subject: [JDK 8] Code review request JDK-8023881, IDN.USE_STD3_ASCII_RULES
option is too strict to use Unicode in IDN.toASCII
Message-ID: <521F42BB.9020309@oracle.com>
Hi,
Please review the fix of JDK-8023881.
webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/
This bug has not been ported to bugs.sun.com. The following is the
descirption of the issue.
--------------------------------------------------------
IDN.toASCII("??.com", IDN.USE_STD3_ASCII_RULES) throws:
Exception ... java.lang.IllegalArgumentException: Contains non-LDH
characters
at java.net.IDN.toASCIIInternal(IDN.java:275)
at java.net.IDN.toASCII(IDN.java:118)
However, the "idn" tool is able to handle above IDN properly:
$ idn --usestd3asciirules www.??.com
www.xn--fsq092h.com
Per step 3, section 4.1, RFC 3490:
3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
(a) Verify the absence of non-LDH ASCII code points; that is, the
absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
(b) Verify the absence of leading and trailing hyphen-minus; that
is, the absence of U+002D at the beginning and end of the
sequence.
However, in the impl of IDN is checking far more strictly than above.
Unicode point bigger than 0x007A is not acceptable. It is too strict to
convert Unicode with IDN.toASCII() if IDN.USE_STD3_ASCII_RULES option is
set.
--------------------------------------------------------
Thanks,
Xuelei
From michael.x.mcmahon at oracle.com Thu Aug 29 07:57:30 2013
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 29 Aug 2013 15:57:30 +0100
Subject: [JDK 8] Code review request JDK-8023881, IDN.USE_STD3_ASCII_RULES
option is too strict to use Unicode in IDN.toASCII
In-Reply-To: <521F42BB.9020309@oracle.com>
References: <521F42BB.9020309@oracle.com>
Message-ID: <521F615A.8080002@oracle.com>
Xuelei,
This looks fine.
I would add a comment to line 408-409 that says something like:
Non LDH refers to characters in the ASCII range, but which
are not letters, digits or the hypen.
That explains what exactly was fixed here.
Michael
On 29/08/13 13:46, Xuelei Fan wrote:
> Hi,
>
> Please review the fix of JDK-8023881.
>
> webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/
>
> This bug has not been ported to bugs.sun.com. The following is the
> descirption of the issue.
>
> --------------------------------------------------------
> IDN.toASCII("??.com", IDN.USE_STD3_ASCII_RULES) throws:
>
> Exception ... java.lang.IllegalArgumentException: Contains non-LDH
> characters
> at java.net.IDN.toASCIIInternal(IDN.java:275)
> at java.net.IDN.toASCII(IDN.java:118)
>
> However, the "idn" tool is able to handle above IDN properly:
> $ idn --usestd3asciirules www.??.com
> www.xn--fsq092h.com
>
> Per step 3, section 4.1, RFC 3490:
>
> 3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
>
> (a) Verify the absence of non-LDH ASCII code points; that is, the
> absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
>
> (b) Verify the absence of leading and trailing hyphen-minus; that
> is, the absence of U+002D at the beginning and end of the
> sequence.
>
> However, in the impl of IDN is checking far more strictly than above.
> Unicode point bigger than 0x007A is not acceptable. It is too strict to
> convert Unicode with IDN.toASCII() if IDN.USE_STD3_ASCII_RULES option is
> set.
> --------------------------------------------------------
>
> Thanks,
> Xuelei
From xuelei.fan at oracle.com Thu Aug 29 08:20:29 2013
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 29 Aug 2013 23:20:29 +0800
Subject: [JDK 8] Code review request JDK-8023881, IDN.USE_STD3_ASCII_RULES
option is too strict to use Unicode in IDN.toASCII
In-Reply-To: <521F615A.8080002@oracle.com>
References: <521F42BB.9020309@oracle.com> <521F615A.8080002@oracle.com>
Message-ID: <521F66BD.9080404@oracle.com>
On 8/29/2013 10:57 PM, Michael McMahon wrote:
> Xuelei,
>
> This looks fine.
>
> I would add a comment to line 408-409 that says something like:
>
> Non LDH refers to characters in the ASCII range, but which
> are not letters, digits or the hypen.
>
I will add the comment. Thanks for the quick code review.
Xuelei
> That explains what exactly was fixed here.
>
> Michael
>
> On 29/08/13 13:46, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the fix of JDK-8023881.
>>
>> webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/
>>
>> This bug has not been ported to bugs.sun.com. The following is the
>> descirption of the issue.
>>
>> --------------------------------------------------------
>> IDN.toASCII("??.com", IDN.USE_STD3_ASCII_RULES) throws:
>>
>> Exception ... java.lang.IllegalArgumentException: Contains non-LDH
>> characters
>> at java.net.IDN.toASCIIInternal(IDN.java:275)
>> at java.net.IDN.toASCII(IDN.java:118)
>>
>> However, the "idn" tool is able to handle above IDN properly:
>> $ idn --usestd3asciirules www.??.com
>> www.xn--fsq092h.com
>>
>> Per step 3, section 4.1, RFC 3490:
>>
>> 3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
>>
>> (a) Verify the absence of non-LDH ASCII code points; that is, the
>> absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
>>
>> (b) Verify the absence of leading and trailing hyphen-minus; that
>> is, the absence of U+002D at the beginning and end of the
>> sequence.
>>
>> However, in the impl of IDN is checking far more strictly than above.
>> Unicode point bigger than 0x007A is not acceptable. It is too strict to
>> convert Unicode with IDN.toASCII() if IDN.USE_STD3_ASCII_RULES option is
>> set.
>> --------------------------------------------------------
>>
>> Thanks,
>> Xuelei
>
From dan.xu at oracle.com Thu Aug 29 10:44:20 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Thu, 29 Aug 2013 17:44:20 +0000
Subject: hg: jdk8/tl/jdk: 4792059: test/java/io/pathNames/GeneralSolaris.java
fails on symbolic links
Message-ID: <20130829174445.5008B623C7@hg.openjdk.java.net>
Changeset: 5bf4f2eeee85
Author: dxu
Date: 2013-08-29 10:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bf4f2eeee85
4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links
Summary: Exclude the possible usage of linked files or directories in the test
Reviewed-by: alanb
! test/java/io/pathNames/General.java
From jonathan.gibbons at oracle.com Thu Aug 29 11:42:43 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 18:42:43 +0000
Subject: hg: jdk8/tl/langtools: 8001669: javadoc internal DocletAbortException
should set cause when appropriate
Message-ID: <20130829184250.9071D623CF@hg.openjdk.java.net>
Changeset: 0e6577980181
Author: jjg
Date: 2013-08-29 11:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e6577980181
8001669: javadoc internal DocletAbortException should set cause when appropriate
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
From jonathan.gibbons at oracle.com Thu Aug 29 11:58:03 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 18:58:03 +0000
Subject: hg: jdk8/tl/langtools: 8023522:
tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA
newline fail on windows only
Message-ID: <20130829185809.5FF98623D3@hg.openjdk.java.net>
Changeset: b0b25c1f6cbd
Author: jjg
Date: 2013-08-29 11:57 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0b25c1f6cbd
8023522: tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA newline fail on windows only
Reviewed-by: darcy
! test/tools/javac/tree/TypeAnnotationsPretty.java
From jonathan.gibbons at oracle.com Thu Aug 29 12:04:23 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 19:04:23 +0000
Subject: hg: jdk8/tl/langtools: 8013384: Potential infinite loop in javadoc
Message-ID: <20130829190432.B1D57623D8@hg.openjdk.java.net>
Changeset: 9c0e192c0926
Author: jjg
Date: 2013-08-29 12:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9c0e192c0926
8013384: Potential infinite loop in javadoc
Reviewed-by: darcy
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
From jonathan.gibbons at oracle.com Thu Aug 29 12:12:25 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 29 Aug 2013 19:12:25 +0000
Subject: hg: jdk8/tl/langtools: 8022744: javac -Xpkginfo command's
documentation is sparse
Message-ID: <20130829191232.EF632623DA@hg.openjdk.java.net>
Changeset: 96b6865eda94
Author: jjg
Date: 2013-08-29 12:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/96b6865eda94
8022744: javac -Xpkginfo command's documentation is sparse
Reviewed-by: darcy
! src/share/classes/com/sun/tools/javac/main/Option.java
From mike.duigou at oracle.com Thu Aug 29 16:05:12 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 29 Aug 2013 23:05:12 +0000
Subject: hg: jdk8/tl: 8023892: test/Makefile shouldn't try to tell
langtools/test/Makefile where to put output.
Message-ID: <20130829230512.8E950623FC@hg.openjdk.java.net>
Changeset: 51a61778a99d
Author: mduigou
Date: 2013-08-29 16:04 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/51a61778a99d
8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to put output.
Reviewed-by: erikj, vromero, henryjen
! test/Makefile
From jonathan.gibbons at oracle.com Thu Aug 29 19:20:32 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 02:20:32 +0000
Subject: hg: jdk8/tl/langtools: 8023833: Replace direct use of AnnotatedType
in javadoc code
Message-ID: <20130830022040.35E3D62403@hg.openjdk.java.net>
Changeset: 23f0f3c9c44a
Author: jjg
Date: 2013-08-29 19:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23f0f3c9c44a
8023833: Replace direct use of AnnotatedType in javadoc code
Reviewed-by: darcy
! src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java
From xuelei.fan at oracle.com Thu Aug 29 18:59:41 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Fri, 30 Aug 2013 01:59:41 +0000
Subject: hg: jdk8/tl/jdk: 8023881: IDN.USE_STD3_ASCII_RULES option is too
strict to use Unicode in IDN.toASCII
Message-ID: <20130830015953.C9E4362401@hg.openjdk.java.net>
Changeset: cdf68747b0fb
Author: xuelei
Date: 2013-08-29 18:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf68747b0fb
8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII
Reviewed-by: michaelm
! src/share/classes/java/net/IDN.java
+ test/java/net/IDN/UseSTD3ASCIIRules.java
From jonathan.gibbons at oracle.com Fri Aug 30 11:50:05 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 18:50:05 +0000
Subject: hg: jdk8/tl/langtools: 8023700: Use non breaking space in various
labels
Message-ID: <20130830185013.C200E6243A@hg.openjdk.java.net>
Changeset: 240f424cc0d5
Author: jjg
Date: 2013-08-30 11:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/240f424cc0d5
8023700: Use non breaking space in various labels
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! test/com/sun/javadoc/testNavigation/TestNavigation.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java
From jonathan.gibbons at oracle.com Fri Aug 30 15:16:09 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 22:16:09 +0000
Subject: hg: jdk8/tl/langtools: 8024093: Two *.rej files checked in to
langtools/test directory
Message-ID: <20130830221612.C01AF62443@hg.openjdk.java.net>
Changeset: 3dd40e5715fb
Author: jjg
Date: 2013-08-30 15:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3dd40e5715fb
8024093: Two *.rej files checked in to langtools/test directory
Reviewed-by: mchung
- test/tools/javac/diags/examples/MrefStat.java.rej
- test/tools/javac/diags/examples/MrefStat1.java.rej
From jonathan.gibbons at oracle.com Fri Aug 30 16:27:42 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 30 Aug 2013 23:27:42 +0000
Subject: hg: jdk8/tl/langtools: 8008367: Sub-packages missing from Profiles
javadoc
Message-ID: <20130830232747.8DC6E6244C@hg.openjdk.java.net>
Changeset: f050c714b556
Author: jjg
Date: 2013-08-30 16:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f050c714b556
8008367: Sub-packages missing from Profiles javadoc
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
From jonathan.gibbons at oracle.com Fri Aug 30 17:37:22 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 31 Aug 2013 00:37:22 +0000
Subject: hg: jdk8/tl/langtools: 8015663: Need to supply tests to provide
javadoc for profiles support code coverage
Message-ID: <20130831003729.303AE62453@hg.openjdk.java.net>
Changeset: 7993cfab8610
Author: jjg
Date: 2013-08-30 17:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7993cfab8610
8015663: Need to supply tests to provide javadoc for profiles support code coverage
Reviewed-by: jjg
Contributed-by: evgeniya.stepanova at oracle.com
! test/com/sun/javadoc/testProfiles/TestProfiles.java
+ test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java
! test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java
+ test/com/sun/javadoc/testProfiles/pkg2/ClassError.java
+ test/com/sun/javadoc/testProfiles/pkg2/ClassException.java
+ test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java
+ test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java
! test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt
From dan.xu at oracle.com Fri Aug 30 16:46:11 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Fri, 30 Aug 2013 23:46:11 +0000
Subject: hg: jdk8/tl/jdk: 8023765: Improve MaxPathLength.java testcase and
reduce its test load; ...
Message-ID: <20130830234645.ED4336244F@hg.openjdk.java.net>
Changeset: 5b01c851bb1d
Author: dxu
Date: 2013-08-30 16:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b01c851bb1d
8023765: Improve MaxPathLength.java testcase and reduce its test load
7160013: java/io/File/MaxPathLength.java fails
Reviewed-by: alanb
! test/ProblemList.txt
! test/java/io/File/MaxPathLength.java