From alejandro.murillo at oracle.com Tue Sep 2 16:21:40 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 02 Sep 2014 10:21:40 -0600 Subject: jdk9-dev: HotSpot Message-ID: <5405EE94.8060509@oracle.com> jdk9-hs-2014-08-29 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/0610b52412cf http://hg.openjdk.java.net/jdk9/dev/corba/rev/1f5939bac4ae http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1a3bdc233bda http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/65e6291d9ba9 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/9b415daee626 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c6107c9365a1 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/73b1d870a886 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/2520d5e7bc5f Component : VM Status : 0 major failures, 0 minor failures Date : 09/03/2014 at 19:30 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-08-29-173357.amurillo.jdk9-hs-2014-08-29-jdk9-dev-control Testing: 876 new failures, 3040 known failures, 413119 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8027480: Build Windows x64 fastdebug builds using /homeparams 8028787: tmtools/jstat/gcoldcapacity/jstat_gcoldcapacity02 fails nsk.share.Failure: OGC < OGCMN in RT_Baseline 8041727: [TESTBUG] runtime/jsig/Test8017498.sh fails with Test8017498.sh: 50: [: x/usr/bin/gcc: unexpected operator 8048150: Allow easy configurations for large CDS archives 8050464: G1 string deduplication tests hang/timeout and leave running processes consuming all resources 8051415: TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory 8054546: NMT2 leaks memory 8054808: Bitmap verification sometimes fails after Full GC aborts concurrent mark. 8054819: Rename HeapRegionSeq to HeapRegionManager 8055052: [TESTBUG] runtime/NMT/JcmdDetailDiff.java fails on Windows when there are no debug symbols available 8055053: [TESTBUG] runtime/NMT/VirtualAllocCommitUncommitRecommit.java fails 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected 8055164: [TESTBUG] runtime/CompressedOops/CompressedClassPointers.java fails with OpenJDK build 8055236: Deadlock during NMT2 shutdown on Windows 8055338: (process) Add instrumentation to help diagnose JDK-6573254 8055416: Several vm/gc/heap/summary "After GC" events emitted for the same GC ID 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC 8055684: runtime/NMT/CommandLineEmptyArgument.java fails 8055751: TestAnonymousClassUnloading.java needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot 8055754: filemap.cpp does not compile with clang 8055765: Misplaced @key stress prevents MallocSiteHashOverflow.java and MallocStressTest.java tests from running 8055814: [TESTBUG] runtime/NMT/NMTWithCDS.java fails with product builds due to missing UnlockDiagnosticVMOptions 8055816: Remove dead code in g1BlockOffsetTable 8055818: Remove PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from g1BlockOffsetTable.cpp 8055844: [TESTBUG] test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java fails on Solaris Sparc due to incorrect page size being used 8055919: Remove dead code in G1 concurrent marking code 8055953: [TESTBUG] Fix for 8055098 does not contain unit test 8056043: Heap does not shrink within the heap after JDK-8038423 8056072: add jprt_optimized targets -- Alejandro From lana.steuck at oracle.com Wed Sep 3 20:51:18 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 3 Sep 2014 13:51:18 -0700 (PDT) Subject: jdk9-b29: dev Message-ID: <201409032051.s83KpIGs026935@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/9e6581aeda38 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/e541ebaf2ab7 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/13705e2ddeb2 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2da27e8e2c86 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/3d1a4bfb6abb http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/30adcd13a313 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/deb29e92f68a http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/163a9cd806fd --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8034218 client-libs AIX: Provide a better fontconfig.properties file JDK-8055955 core-libs (ch) Remove unnecessary initialization of InetAddress from FileChannel JDK-8055421 core-libs (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c JDK-8055852 core-libs Add test/java/lang/Math/DoubleConsts.java and FloatConsts.java JDK-8056123 core-libs Anonymous function statements leak internal function names into global scope JDK-8055949 core-libs ByteArrayOutputStream capacity should be maximal array size permitted by VM JDK-8056310 core-libs Cleanup in WinNTFileSystem_md.c JDK-8049228 core-libs Improve multithreaded scalability of InetAddress cache JDK-7186258 core-libs InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate JDK-8055830 core-libs JDK-8015969.js is silently failing JDK-8055796 core-libs JSObject and browser JSObject linkers should provide fallback to call underlying Java methods directly JDK-8054720 core-libs Modifications of I/O methods for instrumentation purposes JDK-8055747 core-libs Move SimpleSSLContext to jdk/testlibrary JDK-8055762 core-libs Nashorn misses linker for netscape.javascript.JSObject instances JDK-8055878 core-libs Nashorn: all tests failed with AccessControlException JDK-8056243 core-libs OptimisticTypePersistence should refuse to work in symlinked directories JDK-8055911 core-libs Questionable String.intern() in jdk.nashorn.internal.ir.IdentNode() JDK-8055954 core-libs Questionable use of parallelStream() in jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.initialize() JDK-8055811 core-libs Tests for Nashorn ClassFilter Support JDK-8055899 core-libs Two nashorn tests fail in 8u40 nightly build with ClassNotFoundException JDK-8042003 core-libs Update java/lang/Math tests to eliminate dependency on sun.misc.DoubleConsts and sun.misc.FloatConsts JDK-8054714 core-libs Use StringJoiner where it makes the code cleaner JDK-8055687 core-libs Wrong "this" passed to JSObject.eval call JDK-8055393 core-libs [Testbug] Some tests are being executed and fail under profiles JDK-8056094 core-libs [nashorn] tests fail when running via jtreg JDK-8055870 core-libs iteration fails if index var is not used JDK-8055675 core-libs java/util/Currency/PropertiesTest.sh fails on OS X after JDK-8055253 JDK-8055906 core-libs jdk.nashorn.internal.codegen.ApplySpecialization$1.leaveIdentNode() should throw stackless Exception JDK-8056025 core-libs jdk.nashorn.internal.codegen.CompilationPhase.setStates() is hot in class installation phase JDK-8055913 core-libs jdk.nashorn.internal.ir.Node.hashCode() delegates to Object.hashCode() and is hot JDK-8056052 core-libs jdk.nashorn.internal.runtime.Source.getContent() does excess Object.clone() JDK-8055923 core-libs jdk.nashorn.internal.{codegen.CompilationPhase|runtime.Timing} should use System.nanoTime JDK-8056050 core-libs runExternalJsTest method in test/jdk/nashorn/internal/runtime/ClassFilter.java slows down "ant test" JDK-8056065 core-libs sun/net/www/protocol/http/RedirectOnPost.java failing. JDK-8043936 core-svc Drop HPROF as demo, keep as HPROF agent shipped with JDK JDK-8043981 core-svc Remove the JPDA demo JDK-8055230 core-svc Rename attach provider implementation class be platform neutral JDK-8040692 core-svc [TESTBUG] sun/management/jmxremote/bootstrap/JvmstatCountersTest.java requires -XX:+UsePerfData option to pass on embedded platforms JDK-8054066 core-svc com/sun/jdi/DoubleAgentTest.java fails with timeout JDK-8049226 core-svc com/sun/jdi/OptionTest.java test times out again JDK-8037082 core-svc java/lang/instrument/NativeMethodPrefixAgent.java failing JDK-7132590 core-svc javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java fails in JDK8-B22 JDK-8046791 globalization AUWelcome dialog not totally localized for zh_CN and zh_TW JDK-8054402 hotspot "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes JDK-8048879 hotspot "unexpected yanked node" opto/postaloc.cpp:139 JDK-8046417 hotspot (jdk) Add JFR events to list all ClassLoaders JDK-8056148 hotspot Add java/lang/management/MemoryMXBean/LowMemoryTest.java to ProblemList.txt JDK-6590051 hotspot Application class sharing JDK-8055525 hotspot Bigapp weblogic+medrec fails to startup after JDK-8038423 JDK-8026303 hotspot CMS: JVM intermittently crashes with "FreeList of size 258 violates Conservation Principle" assert JDK-8046070 hotspot Class Data Sharing clean up and refactoring JDK-8038423 hotspot G1: Decommit memory within the heap JDK-7173584 hotspot Implement arraycopy as a macro node JDK-8044406 hotspot JVM crash with JDK8 (build 1.8.0-b132) with G1 GC JDK-8054927 hotspot Missing MemNode::acquire ordering in some volatile Load nodes JDK-8055635 hotspot Missing include in g1RegionToSpaceMapper.hpp results in unresolved symbol of fastdebug build without precompiled headers JDK-8055007 hotspot NMT2: emptyStack missing in minimal build JDK-8043284 hotspot Optimize signed integer comparison JDK-8054547 hotspot Re-enable warning for incompatible java launcher JDK-8054224 hotspot Recursive method that was compiled by C1 is unable to catch StackOverflowError JDK-8054818 hotspot Refactor HeapRegionSeq to manage heap region and auxiliary data JDK-8055503 hotspot Rollback 8054164 changeset JDK-8055108 hotspot SA: Remove the extra byte written for CONTENT_TYPE_CLASS JDK-8054883 hotspot Segmentation error while running program JDK-8055275 hotspot Several gc/class_unloading/ tests fail due to missed +UnlockDiagnosticVMOptions flag JDK-8055098 hotspot WB API should be extended to provide information about size and age of object. JDK-8055231 hotspot ZERO variant build is broken JDK-8054711 hotspot [TESTBUG] Enable NMT2 tests after NMT2 is integrated JDK-8032999 hotspot [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job JDK-8055061 hotspot assert at share/vm/services/virtualMemoryTracker.cpp:332 Error: ShouldNotReachHere() when running NMT tests JDK-8042384 hotspot closed/com/oracle/jfr/api/ConfigurationTest/TestDefaultPresets.java Setting '...' in event '...' was not configured JDK-8054362 hotspot gc/g1/TestEagerReclaimHumongousRegions2.java timeout JDK-8055677 hotspot java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012 JDK-8055184 hotspot newly added DumpJFR tests fail on multiple platforms JDK-8054368 hotspot nsk/jdi/VirtualMachine/exit/exit002 crash with detail tracking on (NMT2) JDK-8055153 hotspot nsk/stress/jck60/jck60014 crashes on sparc JDK-8043913 hotspot remove legacy code in SPARC's VM_Version::platform_features JDK-8054013 hotspot run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx JDK-8055051 hotspot runtime/NMT/CommandLineEmptyArgument.java fails JDK-8055284 hotspot sanity/WhiteBox.java fails with NPE JDK-8054164 hotspot solaris makefile JDK-8055855 infrastructure "make profiles" failing since refactoring of java.awt.datatransfer JDK-8056062 infrastructure Additional minor cleanups from source restructure build changes JDK-8056246 infrastructure Fix AIX build after the Modular Source Code change 8054834 JDK-8056064 infrastructure Fix corba locale build problem on windows JDK-8014510 infrastructure Fix sjavac on all platforms in jprt JDK-8055188 infrastructure General cleanup of minor issues from source restructure JDK-8055095 infrastructure Improve "do nothing" incremental build performance after modularized source code integration JDK-8055096 infrastructure Remove explicit mx flag from javadoc command line JDK-8055922 infrastructure Work around sjavac limitation with public api tracking cross modules JDK-8056113 infrastructure [build] tools.jar missing modules.xml JDK-8055856 infrastructure checkdeps build target doesn't work for cross-compilation builds JDK-8055772 infrastructure get_source.sh : version check assumes English localization JDK-8055331 infrastructure hgforest: cleaner handling of exit results. JDK-8047952 infrastructure hotspot fastdebug builds broken on fedora 19 after JDK-8047734 JDK-8055299 security-libs HttpsURLConnection.equals() broken JDK-8050370 security-libs Need new regressions tests for MessageDigest with DigestIOStream JDK-8048617 security-libs Tests for PKCS12 read operations JDK-8055901 security-libs Update policytool for jdk.net.NetworkPermission JDK-8055731 security-libs sun/security/smartcardio/TestDirect.java throws java.lang.IndexOutOfBoundsException JDK-8056283 tools @ignore tools/javac/defaultMethods/Assertions.java until JDK-8047675 is fixed JDK-8056075 tools Add support for dumping inference dependency graphs JDK-8049126 tools Group 8a: golden files for annotations test in tools/java dir JDK-8055074 tools Group 9a: golden files for tests in tools/javac dir JDK-8056252 tools Incremental build fails on Windows JDK-8056055 tools IntelliJ source paths broken after modularization of langtools JDK-8056061 tools Mark implementations of public interfaces with an annotation JDK-8054500 tools Refactor sjavac Main class into ClientMain and ServerMain JDK-8055767 tools Sjavac is leaking servers JDK-8038732 tools [javadoc] NetBeans IDE target does not build doclets JDK-8050031 tools [javadoc] class-use pages have duplicates and missing entries JDK-8054925 tools [javadoc] refactor the Doclet start method. JDK-8044859 tools javac duplicates option processing when using Compiler API JDK-8037819 xml Xerces Update: jaxp/validation/XMLSchemaFactory From yuri.nesterenko at oracle.com Mon Sep 8 06:58:38 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Mon, 08 Sep 2014 10:58:38 +0400 Subject: Result: New jdk9 Committer: Alexander Stepanov Message-ID: <540D539E.4030608@oracle.com> Voting for Alexander Stepanov [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thank you! -yan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-August/001240.html From jaroslav.bachorik at oracle.com Mon Sep 8 08:13:04 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 08 Sep 2014 10:13:04 +0200 Subject: [preview] CFV: New JDK9 Committer: Yekaterina Kantserova Message-ID: <540D6510.5070802@oracle.com> I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. Yekaterina is a member of the Java VM SQE team. She is the lead for the Test Stabilization and Test Refactoring efforts in the JVM serviceability area. So far, she directly contributed to JDK some 17 changes[3] out of which these 8 [4] can be considered non-trivial. The changes she contributed showed that she had good knowledge of the code base, was very well familiarized with the OpenJDK process and would be perfectly capable to author and commit changes on her own. Votes are due by September 22, 2014 Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thank you, -JB- [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 [4] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From jaroslav.bachorik at oracle.com Mon Sep 8 08:13:42 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 08 Sep 2014 10:13:42 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova Message-ID: <540D6536.5040703@oracle.com> I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. Yekaterina is a member of the Java VM SQE team. She is the lead for the Test Stabilization and Test Refactoring efforts in the JVM serviceability area. So far, she directly contributed to JDK some 17 changes[3] out of which these 8 [4] can be considered non-trivial. The changes she contributed showed that she had good knowledge of the code base, was very well familiarized with the OpenJDK process and would be perfectly capable to author and commit changes on her own. Votes are due by September 22, 2014 Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thank you, -JB- [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 [4] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From erik.joelsson at oracle.com Mon Sep 8 08:17:44 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Sep 2014 10:17:44 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6628.9080608@oracle.com> Vote: yes /Erik From erik.helin at oracle.com Mon Sep 8 08:16:26 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 08 Sep 2014 10:16:26 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D65DA.1070701@oracle.com> Vote: yes Erik On 2014-09-08 10:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the > Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which > these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and would > be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From joel.franck at oracle.com Mon Sep 8 08:22:45 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 8 Sep 2014 10:22:45 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <399A31CE-A297-483F-9B3C-0C1CAA69C5E3@oracle.com> Vote: yes! cheers /Joel On 8 sep 2014, at 10:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the Test Stabilization and Test Refactoring efforts in the JVM serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the code base, was very well familiarized with the OpenJDK process and would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From stefan.karlsson at oracle.com Mon Sep 8 08:26:12 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 08 Sep 2014 10:26:12 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6824.5040900@oracle.com> Vote: yes StefanK On 2014-09-08 10:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From Alan.Bateman at oracle.com Mon Sep 8 08:28:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Sep 2014 09:28:01 +0100 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6891.5070408@oracle.com> Vote: yes (I've been very impressed by Katja's efforts to re-write and stabilize the tests for this area over the last 18 months. Good work!) From stefan.johansson at oracle.com Mon Sep 8 08:28:04 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 08 Sep 2014 10:28:04 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6894.4080504@oracle.com> Vote: YES StefanJ On 2014-09-08 10:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From dmitry.samersoff at oracle.com Mon Sep 8 08:28:26 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 08 Sep 2014 12:28:26 +0400 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D68AA.1050405@oracle.com> Vote: Yes On 2014-09-08 12:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the > Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which > these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and would > be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 -- 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 daniel.fuchs at oracle.com Mon Sep 8 08:30:52 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 08 Sep 2014 10:30:52 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D693C.7000901@oracle.com> Vote: Yes On 9/8/14 10:13 AM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the > Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. From jesper.wilhelmsson at oracle.com Mon Sep 8 08:34:18 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 08 Sep 2014 10:34:18 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6A0A.3070400@oracle.com> Vote: Yes /Jesper Jaroslav Bachorik skrev 8/9/14 10:13: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the Test > Stabilization and Test Refactoring efforts in the JVM serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which these 8 > [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the code base, > was very well familiarized with the OpenJDK process and would be perfectly > capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From ivan.gerasimov at oracle.com Mon Sep 8 08:37:53 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 08 Sep 2014 12:37:53 +0400 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6AE1.2050106@oracle.com> Vote: Yes On 08.09.2014 12:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 > > From shanliang.jiang at oracle.com Mon Sep 8 08:40:03 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 08 Sep 2014 10:40:03 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6B63.7020900@oracle.com> Vote: Yes Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From bengt.rutisson at oracle.com Mon Sep 8 08:46:43 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 08 Sep 2014 10:46:43 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D6CF3.60104@oracle.com> Vote: yes Bengt On 2014-09-08 10:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From andrei.eremeev at oracle.com Mon Sep 8 11:26:15 2014 From: andrei.eremeev at oracle.com (Andrei Eremeev) Date: Mon, 08 Sep 2014 14:26:15 +0300 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D9257.9050903@oracle.com> Vote: yes. Andrei On 08.09.2014 11:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From staffan.larsen at oracle.com Mon Sep 8 11:32:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Sep 2014 13:32:12 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <71852406-2BC4-4AB8-BAE4-7C4586350BCF@oracle.com> Vote: yes. On 8 sep 2014, at 10:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the Test Stabilization and Test Refactoring efforts in the JVM serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the code base, was very well familiarized with the OpenJDK process and would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From roger.riggs at oracle.com Mon Sep 8 12:11:02 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 08 Sep 2014 08:11:02 -0400 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540D9CD6.8060307@oracle.com> Vote: Yes On 9/8/2014 4:13 AM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. From karen.kinnear at oracle.com Mon Sep 8 12:15:15 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 8 Sep 2014 08:15:15 -0400 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: Vote: yes On Sep 8, 2014, at 4:13 AM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the Test Stabilization and Test Refactoring efforts in the JVM serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the code base, was very well familiarized with the OpenJDK process and would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From mikael.gerdin at oracle.com Mon Sep 8 13:08:48 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Sep 2014 15:08:48 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <13182534.beSomt08Xr@mgerdin03> Vote: yes On Monday 08 September 2014 10.13.42 Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the > Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which > these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and would > be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From daniel.daugherty at oracle.com Mon Sep 8 13:38:05 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Sep 2014 07:38:05 -0600 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540DB13D.80000@oracle.com> Vote: yes Dan On 9/8/14 2:13 AM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 > > From coleen.phillimore at oracle.com Mon Sep 8 13:54:22 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 08 Sep 2014 09:54:22 -0400 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540DB50E.9050702@oracle.com> Vote: yes On 9/8/14, 4:13 AM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From christian.tornqvist at oracle.com Mon Sep 8 14:37:04 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 8 Sep 2014 10:37:04 -0400 Subject: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <0a8901cfcb72$5cb46430$161d2c90$@oracle.com> Vote: yes -----Original Message----- From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of Jaroslav Bachorik Sent: Monday, September 8, 2014 4:14 AM To: jdk9-dev at openjdk.java.net Subject: CFV: New JDK9 Committer: Yekaterina Kantserova I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. Yekaterina is a member of the Java VM SQE team. She is the lead for the Test Stabilization and Test Refactoring efforts in the JVM serviceability area. So far, she directly contributed to JDK some 17 changes[3] out of which these 8 [4] can be considered non-trivial. The changes she contributed showed that she had good knowledge of the code base, was very well familiarized with the OpenJDK process and would be perfectly capable to author and commit changes on her own. Votes are due by September 22, 2014 Only current JDK9 Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Thank you, -JB- [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 [4] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From vladimir.x.ivanov at oracle.com Mon Sep 8 15:39:26 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 08 Sep 2014 19:39:26 +0400 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540DCDAE.1040608@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 9/8/14, 12:13 PM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the > Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which > these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and would > be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From alejandro.murillo at oracle.com Mon Sep 8 16:04:54 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 08 Sep 2014 10:04:54 -0600 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540DD3A6.7000604@oracle.com> vote: yes On 9/8/2014 2:13 AM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > -- Alejandro From serguei.spitsyn at oracle.com Tue Sep 9 01:55:43 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 08 Sep 2014 18:55:43 -0700 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <540E5E1F.8030209@oracle.com> Vote: yes On 9/8/14 1:13 AM, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for > the Test Stabilization and Test Refactoring efforts in the JVM > serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of > which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the > code base, was very well familiarized with the OpenJDK process and > would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From alejandro.murillo at oracle.com Tue Sep 9 21:00:38 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 09 Sep 2014 15:00:38 -0600 Subject: jdk9-dev: HotSpot Message-ID: <540F6A76.6070307@oracle.com> jdk9-hs-2014-09-05 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/16f1b2409462 http://hg.openjdk.java.net/jdk9/dev/corba/rev/1f5939bac4ae http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/624c017f6d94 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/93a5ed174422 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/9b415daee626 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6ff26a69c28e http://hg.openjdk.java.net/jdk9/dev/langtools/rev/0d89f8b94872 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/dcc08ab6777a Component : VM Status : 0 major failures, 0 minor failures Date : 09/09/2014 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-09-05-153504.amurillo.jdk9-hs-2014-09-05-jdk9-dev-control Testing: 549 new failures, 3084 known failures, 387054 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6590051: Application class sharing 8037925: CMM Testing: an allocated humongous object at the end of the heap should not prevents shrinking the heap 8046070: Class Data Sharing clean up and refactoring 8048150: Allow easy configurations for large CDS archives 8054547: Re-enable warning for incompatible java launcher 8054711: [TESTBUG] Enable NMT2 tests after NMT2 is integrated 8054808: Bitmap verification sometimes fails after Full GC aborts concurrent mark. 8054819: Rename HeapRegionSeq to HeapRegionManager 8054952: [TESTBUG] Add missing NMT2 tests 8054970: gc src file exclusion should exclude alternative sources 8055051: runtime/NMT/CommandLineEmptyArgument.java fails 8055052: [TESTBUG] runtime/NMT/JcmdDetailDiff.java fails on Windows when there are no debug symbols available 8055053: [TESTBUG] runtime/NMT/VirtualAllocCommitUncommitRecommit.java fails 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC 8055684: runtime/NMT/CommandLineEmptyArgument.java fails 8055765: Misplaced @key stress prevents MallocSiteHashOverflow.java and MallocStressTest.java tests from running 8055919: Remove dead code in G1 concurrent marking code 8056043: Heap does not shrink within the heap after JDK-8038423 8056056: Remove unnecessary inclusion of HS_ALT_MAKE from solaris Makefile 8056072: add jprt_optimized targets 8056175: Change "8048150: Allow easy configurations for large CDS archives" triggers conversion warning with older GCC 8056180: [TESTBUG] Exclude closed/runtime/AppCDS/ArchiveSize.java until 8056178 has been fixed 8056223: typo in export_optimized_jdk 8056299: new hotspot build - hs25.40-b09 8056971: Minor class loading clean-up 8057143: Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq 8057531: refactor gc argument processing code slightly 8057535: add a thread extension class 8057536: Refactor G1 to allow context specific allocations 8057623: add an extension class for argument handling 8057628: automatically enable g1 when ResourceTracking is enabled -- Alejandro From lana.steuck at oracle.com Wed Sep 10 19:45:09 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 10 Sep 2014 12:45:09 -0700 (PDT) Subject: jdk9-b30: dev Message-ID: <201409101945.s8AJj9Zp013514@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/36e9bc875325 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/072dbed6c5d9 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/ef5427c13e1e http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8d24fb4493f1 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/e58d3ea638c3 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/d181d4002214 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5c722dffbc0f http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/98967ae6ae53 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8043693 client-libs A typo in the javadoc for javax.imageio.ImageReader JDK-8055254 client-libs Address source incompatability of JSlider generification JDK-8039271 client-libs CMM profile files (cmm/*) should not be in ${java.home}/lib JDK-8055201 client-libs JNI exception pending in jdk/src/solaris/native/sun/awt/CUPSfuncs.c JDK-8046894 client-libs JNI exception pending in jdk/src/solaris/native/sun/awt/X11Color.c JDK-8046887 client-libs JNI exception pending in jdk/src/solaris/native/sun/awt: awt_DrawingSurface.c, awt_GraphicsEnv.c, awt_InputMethod.c, sun_awt_X11_GtkFileDialogPeer.c JDK-8054800 client-libs JNI exception pending in jdk/src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp JDK-8046007 client-libs Java app receives javax.print.PrintException: Printer is not accepting job. JDK-6975892 client-libs Javadoc typo in javax.print.attribute.standard.DialogTypeSelection JDK-8054801 client-libs Memory leak in jdk/src/windows/native/sun/windows/awt_InputMethod.cpp JDK-6708093 client-libs Redundant unused native method declaration in LCMS.java JDK-8054360 client-libs Refine generification of javax.swing JDK-8042199 client-libs The build of J2DBench via makefile is broken after the JDK-8005402 JDK-8042835 client-libs Unexpected mnemonic in JFileChooser JDK-8049065 client-libs [JLightweightFrame] Support DnD for SwingNode JDK-8053657 client-libs [TEST_BUG] move some 5 tests related to undecorated Frame/JFrame to JDK JDK-8054878 client-libs javadoc issues in javax.imageio JDK-8055776 core-libs Add initial unit tests which test SQLPermissions JDK-8057019 core-libs Additional arguments to Function.prototype.apply messes up actual arguments passed JDK-8056129 core-libs AtomicInteger is treated as primitive number with optimistic compilation JDK-8055222 core-libs Currency update needed for ISO 4217 Amendment #159 JDK-8051889 core-libs Implement block scoping in symbol assignment and scope computation JDK-8056249 core-libs Improve CompletableFuture resource usage JDK-8057551 core-libs Make class dumping available outside --compile-only mode JDK-8054343 core-libs Nashorn: Some tests fails on windows with AccessControlException JDK-8056913 core-libs Optimistic Type Persistence allows unbounded growth of cache directory JDK-8038436 core-libs Re-examine the mechanism to determine available localedata and cldrdata JDK-8057150 core-svc Add more diagnostics to JMXStartStopTest JDK-8057134 core-svc sun/management/jmxremote/startstop/JMXStartStopTest.java failing intermittently JDK-8056994 core-svc sun/tools/jstatd/TestJstatdPortAndServer.java and sun/tools/jstatd/TestJstatdServer.java miss correct check of RMI server availability JDK-8022233 deploy Blocking dialog is with wrong title when unsigned applet requests all permission JDK-8052691 deploy Caller_allowable_codebase does not honor checkbox when starting with a "t" JDK-8024746 deploy DRS: differences in behavior for jnlp applets and applet/object applets for case with new/secure but disabled JRE and old insecure JRE that is requested JDK-8035144 deploy Expires value in MSK timezone in HTTP Header of response does not get respected by plugin. JDK-8055704 deploy Putback if 8055179 missed TrustDeciderDialogTest JDK-8035086 deploy Revocation check is still performed for expired cert even if we are going to block an app anyway ( level HIGH ) JDK-8055179 deploy Security Dialog for unsigned jnlp still different in jnlp Application case. JDK-8020304 deploy Self-signed sandbox app causes "expired JRE" blocking window since 7u40 b29 ( Very High security level + expired JRE) JDK-8051577 deploy Some JavaFX webstart apps are reported via Java Usage Tracker incorrectly JDK-8035657 deploy Test with signed JNLP applet with extensions fails since 7u55/8u5 b09 JDK-8049336 deploy Warning always displayed on LiveConnect call in Java 7u60 JDK-8046637 deploy [REGRESSION] HTTPS connection from wiithin plugin/javaws app fail JDK-8055338 hotspot (process) Add instrumentation to help diagnose JDK-6573254 JDK-8048150 hotspot Allow easy configurations for large CDS archives JDK-8053921 hotspot AppCDS: runtime/AppCDS/SignedJar fails JDK-8054808 hotspot Bitmap verification sometimes fails after Full GC aborts concurrent marking JDK-8027480 hotspot Build Windows x64 fastdebug builds using /homeparams JDK-8055236 hotspot Deadlock during NMT2 shutdown on Windows JDK-8056043 hotspot G1 does not uncommit within the heap after JDK-8038423 JDK-8050464 hotspot G1 string deduplication tests hang/timeout and leave running processes consuming all resources JDK-8055706 hotspot JfrCHeapObj::new_array needs disambiguation JDK-8054546 hotspot NMT2 leaks memory JDK-8055818 hotspot Remove PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC from g1BlockOffsetTable.cpp JDK-8055919 hotspot Remove dead code in G1 concurrent marking code JDK-8055816 hotspot Remove dead code in g1BlockOffsetTable JDK-8054819 hotspot Rename HeapRegionSeq to HeapRegionManager JDK-8055416 hotspot Several vm/gc/heap/summary "After GC" events emitted for the same GC ID JDK-8055069 hotspot TSX and RTM should be deprecated more strongly until hardware is corrected JDK-8055657 hotspot Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC JDK-8055751 hotspot TestAnonymousClassUnloading.java needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot JDK-8051415 hotspot TypeTuple::make_domain() and TypeTuple::make_range() allocate too much memory JDK-8056180 hotspot [TESTBUG] Exclude closed/runtime/AppCDS/ArchiveSize.java until 8056178 has been fixed JDK-8055953 hotspot [TESTBUG] Fix for 8055098 does not contain unit test JDK-8055765 hotspot [TESTBUG] Misplaced @key stress prevents MallocSiteHashOverflow.java and MallocStressTest.java tests from running JDK-8054981 hotspot [TESTBUG] closed/runtime/4420691/Test4420691 fails in nightly testing JDK-8055112 hotspot [TESTBUG] closed/runtime/4784641/CheckedIsSameObjectTest.java fails because of msvcr71 dependency JDK-8055164 hotspot [TESTBUG] runtime/CompressedOops/CompressedClassPointers.java fails with OpenJDK build JDK-8055052 hotspot [TESTBUG] runtime/NMT/JcmdDetailDiff.java fails on Windows when there are no debug symbols available JDK-8055814 hotspot [TESTBUG] runtime/NMT/NMTWithCDS.java fails with product builds due to missing UnlockDiagnosticVMOptions JDK-8055053 hotspot [TESTBUG] runtime/NMT/VirtualAllocCommitUncommitRecommit.java fails JDK-8041727 hotspot [TESTBUG] runtime/jsig/Test8017498.sh fails with Test8017498.sh: 50: [: x/usr/bin/gcc: unexpected operator JDK-8055844 hotspot [TESTBUG] test/runtime/NMT/VirtualAllocCommitUncommitRecommit.java fails on Solaris Sparc due to incorrect page size being used JDK-8056072 hotspot add jprt_optimized targets JDK-8055754 hotspot filemap.cpp does not compile with clang JDK-8055684 hotspot runtime/NMT/CommandLineEmptyArgument.java fails JDK-8028787 hotspot tmtools/jstat/gcoldcapacity/jstat_gcoldcapacity02 fails nsk.share.Failure: OGC < OGCMN in RT_Baseline JDK-8057132 infrastructure Build fails if PROFILE is set in the environment JDK-8027627 infrastructure LOG=trace hardcodes value to bash JDK-8043220 install Add "restart browser" warning in TOU page of JUT JDK-8053903 install An unexpected "In Progress" dialog pops up when installing jdk on Windows XP JDK-8053909 install Grammatical error in the Uninstall Tool JDK-8055701 install Incomplete letters displayed in Java update Welcome dialog JDK-8039950 install JRE installer accessibility issues JDK-8053964 install Need to Disable UsageTracker and RuleSet installer options in consumer bundles (both iftw and offline) JDK-8051835 install NoJava window improvements JDK-8049709 install Out-Of-Date mock-up contains small inconsistency JDK-8057076 security-libs Correct exception message in CertAndKeyGen.java JDK-8048621 security-libs Implement basic keystore tests JDK-8049429 security-libs Need new tests for java client server communications with various TLS/SSL combinations JDK-8048362 security-libs Test doPrivileged with accomplice JDK-8038414 tools Constant pool's strings are not escaped properly JDK-8034861 tools Incorrect format and indentation of InnerClasses section JDK-8057005 tools IntelliJ should allow import for nested classes JDK-8056288 tools Missing bug id in test/com/sun/javadoc/testOrdering/TestOrdering.java JDK-8044597 tools Request to update tools/javap/T4501661.java to add test for package option JDK-8054563 tools Update RunCodingRules.java for source code reorg JDK-8047675 tools tools/javac/defaultMethods/Assertions.java fails if run with -enableassertions (-ea) JDK-8037819 xml Xerces Update: jaxp/validation/XMLSchemaFactory From marcus.lagergren at oracle.com Mon Sep 15 07:55:42 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 15 Sep 2014 09:55:42 +0200 Subject: CFV: New JDK9 Committer: Yekaterina Kantserova In-Reply-To: <540D6536.5040703@oracle.com> References: <540D6536.5040703@oracle.com> Message-ID: <6AFC7518-D940-4516-AA12-A6CD78480C39@oracle.com> Vote: yes /M On 08 Sep 2014, at 10:13, Jaroslav Bachorik wrote: > I hereby nominate Ykaterina Kantserova (ykantser) to JDK9 Committer. > > Yekaterina is a member of the Java VM SQE team. She is the lead for the Test Stabilization and Test Refactoring efforts in the JVM serviceability area. > > So far, she directly contributed to JDK some 17 changes[3] out of which these 8 [4] can be considered non-trivial. > > The changes she contributed showed that she had good knowledge of the code base, was very well familiarized with the OpenJDK process and would be perfectly capable to author and commit changes on her own. > > Votes are due by September 22, 2014 > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thank you, > > -JB- > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=ykantser&revcount=100 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6407a15e2274 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/075293ea610b > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c1164d1adb76 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0c0f5406a3e3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0ba15ac25072 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4ee6d5df9665 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b04b124418d8 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2de8c6c2d652 From alejandro.murillo at oracle.com Tue Sep 16 15:13:28 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 16 Sep 2014 09:13:28 -0600 Subject: jdk9-dev: HotSpot Message-ID: <54185398.6040101@oracle.com> jdk9-hs-2014-09-12 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/1540bfaa0606 http://hg.openjdk.java.net/jdk9/dev/corba/rev/c432b80aadd0 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0825d4f74ef8 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/292317ebc7db http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/d35ad0854f68 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50d878aa3d5c http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c419bddef7f3 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/9f8ab1b79632 Component : VM Status : 0 major failures, 0 minor failures Date : 09/16/2014 at 16:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-09-13-212858.amurillo.jdk9-hs-2014-09-12-jdk9-dev-control Testing: 334 new failures, 3143 known failures, 369141 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8025564: gc/memory/UniThread/Linear1 times out during heap verification 8035419: warning from b09 for hotspot.agent.src.os.win32.windbg.sawindbg.cpp: 'JNI exception pending' 8046210: Missing memory barrier when reading init_lock 8050147: StoreLoad barrier interferes with stack usages 8053886: assert(false) failed: Should not allocate with exception pending 8054836: [TESTBUG] Test is needed to verify correctness of malloc tracking 8054889: Compiler team's implementation task 8055008: Clean up code that saves the previous versions of redefined classes 8055289: Internal Error: mallocTracker.cpp:146 fatal error: Should not use malloc for big memory block, use virtual memory instead 8056053: Disable HOTSPOT_BUILD_JOBS when building with configure 8056124: Hotspot should use PICL interface to get cacheline size on SPARC 8056154: JVM crash with EXCEPTION_ACCESS_VIOLATION when there are many threads running 8056242: Add function to return structured information about loaded libraries. 8056930: Output host info under some condition for core dump 8057570: RedefineClasses() tests fail assert(((Metadata*)obj)->is_valid()) failed: obj is valid 8057643: Unable to build --with-debug-level=optimized on OSX 8057696: java -version triggers assertion for slowdebug zero builds 8057722: G1: Code root hashtable updated incorrectly when evacuation failed 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build 8057750: CTW should not make MH intrinsics not entrant 8057758: Tests run TypeProfileLevel=222 crash with guarantee(0) failed: must find derived/base pair 8057780: Fix ppc build after "8050147: StoreLoad barrier interferes with stack usages 8057910: G1: BOT verification should not pass top 8057918: Update out-dated ignore tags in GC jtreg tests 8058092: Test vm/mlvm/meth/stress/compiler/deoptimize. Assert in src/share/vm/classfile/systemDictionary.cpp: MH intrinsic invariant 8058184: Move _highest_comp_level and _highest_osr_comp_level from MethodData to MethodCounters -- Alejandro From joe.darcy at oracle.com Wed Sep 17 04:11:31 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 16 Sep 2014 21:11:31 -0700 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: <53E10590.2010801@oracle.com> References: <53D4152E.20001@oracle.com> <53D9073A.90108@oracle.com> <53E10590.2010801@oracle.com> Message-ID: <541909F3.50605@oracle.com> Hello swing developers, In response to the earlier call for feedback on the initial swing generification changes, several bugs were filed and fixed: JDK-8054360: Refine generification of javax.swing https://bugs.openjdk.java.net/browse/JDK-8054360 JDK-8055254: Address source incompatability of JSlider generification https://bugs.openjdk.java.net/browse/JDK-8055254 These fixes are now present in JDK 9 b30: https://jdk9.java.net/download/ Please give b30 a try when recompiling your favorite swing code base and report on how the refined generification works. Thanks, -Joe On 8/5/2014 9:25 AM, Joe Darcy wrote: > Hello, > > A quick follow-up, I've filed > > JDK-8054360: Refine generification of javax.swing > https://bugs.openjdk.java.net/browse/JDK-8054360#comment-13532821 > > to tweak the generification of TreeNode and possibly a few other types. > > Thanks for the feedback, > > -Joe > > On 7/30/2014 7:54 AM, Joe Darcy wrote: >> Hi Andrej and Martijn, >> >> Thanks for responding. >> >> On 7/28/2014 5:04 AM, Andrej Golovnin wrote: >>> Hi Joe, >>> >>> I'm not sure if it is what you are looking for. >> >> For context, the general evolution policy of the JDK: >> >> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy >> >> >> includes "avoid introducing source incompatibilities." As this is a >> large generification change to swing, some level of source >> incompatibility may be acceptable in a platform release like JDK 9, >> but if there are very widespread issues, some of the changes may be >> reconsidered. >> >> The request to try out the changes was to get enough information to >> see if any (partial) reconsideration was warranted. >> >> >>> But I tried to compile my project with the new build. And I got a >>> compile error in one of my classes. I have a class which implements >>> the TreeNode interface and looks like this: >>> >>> class MyTreeNode implements TreeNode { >>> .... >>> @Override >>> public Enumeration children() { >>> return ....; >>> } >>> ... >>> } >>> >>> The error message is: "return type Enumeration is not >>> compatible with Enumeration". >>> >>> If I change (see attached patch) the definition of the >>> children()-method in the TreeNode-interface to: >>> >>> public interface TreeNode { >>> ... >>> Enumeration children(); >>> ... >>> } >>> >>> then my code compiles. >> >> That design issue was raised during code review: >> >> http://mail.openjdk.java.net/pipermail/swing-dev/2014-June/003643.html >> >> "It was not immediately clear how javax.swing.tree.TreeNode.children(), >> which returns a raw Enumeration, should be generified. I changed it to >> >> Enumeration children(); >> >> and that seems to work fine. Something like >> >> Enumeration >> >> with a covariant override would save a few casts in a private >> implementation, but generally doesn't seem to be a good trade-off since >> many normal clients could be inconvenienced dealing with the wildcard." >> >> If generified subclasses of TreeNode are common, the generification >> of children may need reconsideration. >> >>> >>> BTW, a good test for your changes would be to try to compile >>> NetBeans and/or IntelliJ IDEA using the new JDK 9 build. They both >>> are really big Swing applications which make use maybe of all Swing >>> APIs. >>> >>> >> >> My preference would be for the NetBeans and IntelliJ teams to do that >> task :-) >> >> Thanks, >> >> -Joe > From andrej.golovnin at gmail.com Wed Sep 17 07:53:25 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 17 Sep 2014 09:53:25 +0200 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: <541909F3.50605@oracle.com> References: <53D4152E.20001@oracle.com> <53D9073A.90108@oracle.com> <53E10590.2010801@oracle.com> <541909F3.50605@oracle.com> Message-ID: Hi Joe, I have tested JDK 9b30 with my project and I still have compile errors. I have a code which looks like this: class BeanNode extends DefaultMutableTreeNode { ... } @SuppressWarnings("unchecked") private void aMethod() { BeanNode node = .... .... Enumeration children = node.children(); ... } The compiler reports for this code following error: error: incompatible types: Enumeration cannot be converted to Enumeration because the DefaultMutableTreeNode defines the method #children() as: public Enumeration children() { ... } Best regards, Andrej Golovnin On Wed, Sep 17, 2014 at 6:11 AM, Joe Darcy wrote: > Hello swing developers, > > In response to the earlier call for feedback on the initial swing > generification changes, several bugs were filed and fixed: > > JDK-8054360: Refine generification of javax.swing > https://bugs.openjdk.java.net/browse/JDK-8054360 > > JDK-8055254: Address source incompatability of JSlider generification > https://bugs.openjdk.java.net/browse/JDK-8055254 > > These fixes are now present in JDK 9 b30: > > https://jdk9.java.net/download/ > > Please give b30 a try when recompiling your favorite swing code base and > report on how the refined generification works. > > Thanks, > > -Joe > > On 8/5/2014 9:25 AM, Joe Darcy wrote: > >> Hello, >> >> A quick follow-up, I've filed >> >> JDK-8054360: Refine generification of javax.swing >> https://bugs.openjdk.java.net/browse/JDK-8054360#comment-13532821 >> >> to tweak the generification of TreeNode and possibly a few other types. >> >> Thanks for the feedback, >> >> -Joe >> >> On 7/30/2014 7:54 AM, Joe Darcy wrote: >> >>> Hi Andrej and Martijn, >>> >>> Thanks for responding. >>> >>> On 7/28/2014 5:04 AM, Andrej Golovnin wrote: >>> >>>> Hi Joe, >>>> >>>> I'm not sure if it is what you are looking for. >>>> >>> >>> For context, the general evolution policy of the JDK: >>> >>> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/ >>> OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy >>> >>> includes "avoid introducing source incompatibilities." As this is a >>> large generification change to swing, some level of source incompatibility >>> may be acceptable in a platform release like JDK 9, but if there are very >>> widespread issues, some of the changes may be reconsidered. >>> >>> The request to try out the changes was to get enough information to see >>> if any (partial) reconsideration was warranted. >>> >>> >>> But I tried to compile my project with the new build. And I got a >>>> compile error in one of my classes. I have a class which implements the >>>> TreeNode interface and looks like this: >>>> >>>> class MyTreeNode implements TreeNode { >>>> .... >>>> @Override >>>> public Enumeration children() { >>>> return ....; >>>> } >>>> ... >>>> } >>>> >>>> The error message is: "return type Enumeration is not >>>> compatible with Enumeration". >>>> >>>> If I change (see attached patch) the definition of the >>>> children()-method in the TreeNode-interface to: >>>> >>>> public interface TreeNode { >>>> ... >>>> Enumeration children(); >>>> ... >>>> } >>>> >>>> then my code compiles. >>>> >>> >>> That design issue was raised during code review: >>> >>> http://mail.openjdk.java.net/pipermail/swing-dev/2014-June/003643.html >>> >>> "It was not immediately clear how javax.swing.tree.TreeNode.children(), >>> which returns a raw Enumeration, should be generified. I changed it to >>> >>> Enumeration children(); >>> >>> and that seems to work fine. Something like >>> >>> Enumeration >>> >>> with a covariant override would save a few casts in a private >>> implementation, but generally doesn't seem to be a good trade-off since >>> many normal clients could be inconvenienced dealing with the wildcard." >>> >>> If generified subclasses of TreeNode are common, the generification of >>> children may need reconsideration. >>> >>> >>>> BTW, a good test for your changes would be to try to compile NetBeans >>>> and/or IntelliJ IDEA using the new JDK 9 build. They both are really big >>>> Swing applications which make use maybe of all Swing APIs. >>>> >>>> >>>> >>> My preference would be for the NetBeans and IntelliJ teams to do that >>> task :-) >>> >>> Thanks, >>> >>> -Joe >>> >> >> > From volker.simonis at gmail.com Wed Sep 17 13:50:18 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Sep 2014 15:50:18 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier Message-ID: I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. Goetz (actually G?tz for those of you who can read umlauts :) is a long standing member of the JVM team at SAP, one of the architects of our Itanium and PowerPC ports and a real C2 maven. He's the main contributor of the C2 PowerPC port but has also contributed changes in many other part of the HotSpot including memory ordering changes, code cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and jdk9 committer for the last two years and authored about 80 changes during this time: http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Volker Simonis [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote From vladimir.x.ivanov at oracle.com Wed Sep 17 13:53:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 17 Sep 2014 17:53:12 +0400 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <54199248.2040709@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 9/17/14, 5:50 PM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From staffan.larsen at oracle.com Wed Sep 17 14:04:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 17 Sep 2014 16:04:53 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <829383BC-2F09-4C80-A141-7A5FF83FE1A8@oracle.com> Vote: yes. On 17 sep 2014, at 15:50, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From marcus.lagergren at oracle.com Wed Sep 17 14:47:06 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 17 Sep 2014 16:47:06 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <2F08A269-0CFA-4826-83A8-71B4B6EED2D0@oracle.com> Vote: yes /M On 17 Sep 2014, at 15:50, Volker Simonis wrote: > f From daniel.daugherty at oracle.com Wed Sep 17 14:58:39 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 17 Sep 2014 08:58:39 -0600 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <5419A19F.2080103@oracle.com> Vote: yes Dan On 9/17/14 7:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > From lana.steuck at oracle.com Wed Sep 17 17:33:33 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Sep 2014 10:33:33 -0700 (PDT) Subject: jdk9-b31: dev Message-ID: <201409171733.s8HHXXnx015713@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/69a84c16d9c2 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/77efdecfa2a5 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/0046d55383a9 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/71e99dae28f9 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/7af228ae847f http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/292317ebc7db http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9f7d155d28e5 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/c432b80aadd0 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8029516 core-libs (fs) WatchKey cancel unreliable on Windows JDK-8054987 core-libs (reflect) Add sharing of annotations between instances of Executable JDK-5043030 core-libs (reflect) unnecessary object creation in reflection JDK-8049343 core-libs (tz) Support tzdata2014g JDK-8057826 core-libs Add DataProvider support to the Date, Time and Timestamp tests JDK-8057657 core-libs Annotate LambdaForm parameters with types JDK-7010989 core-libs Duplicate closure of file descriptors leads to unexpected and incorrect closure of sockets JDK-8057654 core-libs Extract checks performed during MethodHandle construction into separate methods JDK-8050173 core-libs Generalize BMH.copyWith API to all method handles JDK-8050166 core-libs Get rid of some package-private methods on arguments in j.l.i.MethodHandle JDK-8058179 core-libs Global constants get in the way of self-modifying properties JDK-8056248 core-libs Improve ForkJoin thread throttling JDK-8057922 core-libs Improve LambdaForm sharing by using LambdaFormEditor more extensively JDK-8057656 core-libs Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks JDK-8056926 core-libs Improve caching of GuardWithTest combinator JDK-8050057 core-libs Improve caching of MethodHandle reinvokers JDK-8050053 core-libs Improve caching of different invokers JDK-8050877 core-libs Improve code for pairwise argument conversions and value boxing/unboxing JDK-8037209 core-libs Improvements and cleanups to bytecode assembly for lambda forms JDK-8057931 core-libs Instead of not skipping small functions in parser, make lexer avoid them instead JDK-8050884 core-libs Intrinsify ValueConversions.identity() functions JDK-8050887 core-libs Intrinsify constants for default values JDK-8038261 core-libs JSR292: cache and reuse typed array accessors JDK-8057042 core-libs LambdaFormEditor: ability to derive new LFs from a base LF JDK-8057588 core-libs Lots of trivial classes are generated by Nashorn compiler JDK-8050200 core-libs Make LambdaForm intrinsics detection more robust JDK-8058117 core-libs Missing jdk.deploy.osx from modules.xml JDK-8049555 core-libs Move varargsArray from sun.invoke.util package to java.lang.invoke JDK-8034954 core-libs Optimistic iteration in for-in and for-each JDK-8055251 core-libs Re-examine Integer.parseInt and Long.parseLong methods JDK-8058100 core-libs Reduce the RecompilableScriptFunctionData footprint JDK-8057930 core-libs Remove "eval id" from eval locations JDK-8057747 core-libs Several test failing after update to tzdata2014g JDK-8057148 core-libs Skip nested functions on reparse JDK-8050052 core-libs Small cleanups in java.lang.invoke code JDK-8057703 core-libs Still, lots of trivial classes are generated by Nashorn compiler JDK-8050174 core-libs Support overriding of isInvokeSpecial flag in WrappedMember JDK-8043839 core-libs TEST closed/com/sun/jndi/dns/RandomXID.java failed intermittently in nightly JDK-8057678 core-libs Tests for let&const keywords in Nashorn JDK-8057021 core-libs UserAccessorProperty guards fail with multiple globals JDK-8057742 core-libs ant clean test should not fail if one or more external test suites are missing JDK-8057936 core-libs java.net.URLClassLoader.findClass uses exceptions in control flow JDK-8057611 core-libs jdk/nashorn/internal/scripts/JO* classes are missing from the generated methods dump JDK-8056951 core-libs pico-optimize contains(Object) methods JDK-8057746 core-svc Cannot handle JdpException in JMX agent initialization. JDK-8057686 core-svc Clean up ProblemList.txt JDK-8057556 core-svc JDP should better handle non-active interfaces JDK-8057174 core-svc MemoryMXBean tests -- TEST FAILED: chunkSize: 6291456 is less than YOUNG_GEN_SIZE: 8388608 JDK-8057776 core-svc Misc cleanups of the attach code JDK-8057778 core-svc Misc cleanups of the attach code (aix) JDK-8057558 core-svc VirtualMachineImpl.execute on windows should close PipedInputStream before throwing exceptions JDK-8058089 core-svc api/javax_management/loading/MLetArgsSupport.html\#MLetArgsSupportTest0001 fails because of java.lang.IllegalArgumentException (argument type mismatch) JDK-8057937 core-svc javax/management/monitor/GaugeMonitorDeadlockTest.java should be quarantined JDK-8055494 hotspot Add C2 x86 intrinsic for BigInteger::multiplyToLen() method JDK-8028594 hotspot Assertion failed: 19 = 20 : Wrong number of collections for collector ParNew JDK-8056175 hotspot Change "8048150: Allow easy configurations for large CDS archives" triggers conversion warning with older GCC JDK-8055903 hotspot Develop sanity tests on SPARC's SHA instructions support JDK-8055904 hotspot Develop tests for new command-line options related to SHA intrinsics JDK-8054355 hotspot ENFORCE_CC_COMPILER_REV needs to be updated to Solaris C++ 12u3 for JDK 9 JDK-8055286 hotspot Extend CompileCommand=option to handle numeric parameters JDK-8057129 hotspot Fix AIX build after the Extend CompileCommand=option change 8055286 JDK-8048268 hotspot G1 Code Root Migration performs poorly JDK-8055838 hotspot Hotspot does not compile with clang 6.0 (OS X Yosemite) JDK-8057143 hotspot Incomplete renaming of variables containing "hrs" to "hrm" related to HeapRegionSeq JDK-8055755 hotspot Information about loaded dynamic libraries is wrong on MacOSX. JDK-8056964 hotspot JDK-8055286 changes are incomplete. JDK-8056971 hotspot Minor class loading clean-up JDK-8049105 hotspot Move array component mirror to instance of java/lang/Class (hotspot part 2) JDK-8056091 hotspot Move compiler/intrinsics/mathexact/sanity/Verifier to compiler/testlibrary and extend its functionality JDK-8056067 hotspot NodeHash debug variables are available in product build JDK-8056084 hotspot Refactor Hashtable to allow implementations without rehashing support JDK-8057038 hotspot Speculative traps not robust when compilation and class unloading are concurrent JDK-8057037 hotspot Verification in ClassLoaderData::is_alive is too slow JDK-8033152 hotspot [TESTBUG] ./serviceability/4367942/Test4367942.sh needs to be removed now that the test was rewritten in Java JDK-8057147 hotspot [TESTBUG] Platform.isDebugBuild() doesn't work on all build types JDK-8054471 hotspot [TESTBUG] closed/runtime/4784574/Test4784574.java fails during nightly JDK-8055946 hotspot assert(result == NULL || result->is_oop()) failed: must be oop JDK-8055910 hotspot closed/java/util/Collections/CheckedCollections.java failed with ClassCastException not thrown JDK-8054292 hotspot code comments leak in fastdebug builds JDK-8056223 hotspot typo in export_optimized_jdk JDK-8031583 hotspot warnings from b03 for hotspot/agent/src/os/solaris/proc: JNI exception pending JDK-8029172 hotspot warnings from b117 for hotspot.agent.src.os.linux: JNI exception pending JDK-8058180 infrastructure .hgignore should be updated with webrev in all repos JDK-8058177 infrastructure 8056195 parfait checks breaks 32-bit builds JDK-8057538 infrastructure Build the freetype library during configure on Windows JDK-8050946 infrastructure Consolidate Java SE Licensee source bundles JDK-8056195 infrastructure Generate Parfait report using same recipe as SQE baseline JDK-8057125 infrastructure LOG=trace hardcodes value to bash (still) JDK-8055720 infrastructure Missing jrecreate exclude entry in Jigsaw update JDK-8057537 infrastructure Serialize reconfigure and fix make clean-foo foo JDK-8055163 infrastructure Source bundle enhancement -- remove test & samples from JLE source bundles JDK-8057813 security-libs Alterations to jdk_security3 test target JDK-8039898 security-libs sunpkcs11-solaris.cfg should be in solaris specific directory JDK-8056984 tools Exception in compiler: java.lang.AssertionError: isSubClass T JDK-8055075 tools Group 9b: golden files for tests in tools/javac dir JDK-8055079 tools Group 9c: golden files for tests in tools/javac dir JDK-8054210 tools NullPointerException when compiling specific code. JDK-8055996 tools Remove @ignore from tools/javac/T6725036.java JDK-8057753 tools Test langtools/test/tools/javac/NoClass.java is failing when run together with langtools/test/tools/javac/DuplicateImport.java JDK-8056014 tools Type inference may be skipped for a complex receiver generic method in a parameter position JDK-8051989 tools Unportable format string argument mismatch in jdk/src/share/native/com/sun/java/util/jar/pack/unpack.cpp JDK-8055514 tools Wrong, confusing error when non-static varargs referenced in static context JDK-8055500 tools [javac] fix for 8030046 is incorrect JDK-8056021 tools checkin for JDK-8027262 breaks Checker Framework JDK-8042347 tools javac, Gen.LVTAssignAnalyzer should be refactored, it shouldn't be a static class JDK-8057627 xml Add org.w3c.dom.ranges and org.w3c.dom.traversal as exported API in modules.xml JDK-8056202 xml Xerces Update: Catalog Resolver JDK-8058175 xml [XML 1.0/1.1] - Attribute values with supplemental characters are being corrupted. From vladimir.kozlov at oracle.com Wed Sep 17 17:43:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Sep 2014 10:43:59 -0700 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <5419C85F.1040206@oracle.com> Vote: yes On 9/17/14 6:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From christian.thalinger at oracle.com Wed Sep 17 18:06:59 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Sep 2014 11:06:59 -0700 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: Vote: yes On Sep 17, 2014, at 6:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) I can :-) > is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From david.holmes at oracle.com Thu Sep 18 02:17:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Sep 2014 12:17:23 +1000 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541A40B3.7070700@oracle.com> Vote: yes David On 17/09/2014 11:50 PM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From mikael.gerdin at oracle.com Thu Sep 18 07:06:05 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 18 Sep 2014 09:06:05 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <1595843.AJd7f3aqrB@mgerdin03> Vote: yes On Wednesday 17 September 2014 15.50.18 Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From thomas.schatzl at oracle.com Thu Sep 18 07:07:48 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 18 Sep 2014 09:07:48 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <1411024068.2709.0.camel@cirrus> Vote: yes On Wed, 2014-09-17 at 15:50 +0200, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From paul.sandoz at oracle.com Thu Sep 18 07:37:40 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 18 Sep 2014 09:37:40 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <29CFE73E-EA22-4EE7-B4BE-EE4D4C34AB18@oracle.com> Vote yes. On Sep 17, 2014, at 3:50 PM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) Sometimes... :-) Paul. From volker.simonis at gmail.com Thu Sep 18 08:02:18 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Sep 2014 10:02:18 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: Vote: yes Regards, Volker On Wed, Sep 17, 2014 at 3:50 PM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From Alan.Bateman at oracle.com Thu Sep 18 08:05:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Sep 2014 09:05:20 +0100 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541A9240.7010805@oracle.com> Vote: yes From stefan.karlsson at oracle.com Thu Sep 18 08:08:58 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 18 Sep 2014 10:08:58 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541A931A.40801@oracle.com> Vote: yes StefanK On 2014-09-17 15:50, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From joel.franck at oracle.com Thu Sep 18 11:19:24 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Thu, 18 Sep 2014 13:19:24 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <20140918111924.GK19198@oracle.com> Vote: yes cheers /Joel On 2014-09-17, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From harold.seigel at oracle.com Thu Sep 18 12:55:51 2014 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 18 Sep 2014 08:55:51 -0400 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541AD657.3050607@oracle.com> Vote: yes Harold On 9/17/2014 9:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From roger.riggs at oracle.com Thu Sep 18 12:57:01 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 18 Sep 2014 08:57:01 -0400 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541AD69D.30908@oracle.com> Vote: Yes On 9/17/2014 9:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > From coleen.phillimore at oracle.com Thu Sep 18 15:09:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 18 Sep 2014 11:09:02 -0400 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541AF58E.2010605@oracle.com> Vote: yes On 9/17/14, 9:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From karen.kinnear at oracle.com Thu Sep 18 15:13:04 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 18 Sep 2014 11:13:04 -0400 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: vote: yes On Sep 17, 2014, at 9:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From jaroslav.tulach at oracle.com Thu Sep 18 16:22:52 2014 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 18 Sep 2014 18:22:52 +0200 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: <541909F3.50605@oracle.com> References: <53D4152E.20001@oracle.com> <53E10590.2010801@oracle.com> <541909F3.50605@oracle.com> Message-ID: <2054891.PhQFBKa3uh@logouticek> Dne ?t 16. z??? 2014 21:11:31, Joe Darcy napsal(a): > Hello swing developers, > > In response to the earlier call for feedback on the initial swing > generification changes, several bugs were filed and fixed: Hello Joe, I'd heard that NetBeans could no longer be compiled after the initial swing generification changes. Can you build NetBeans after your recent fixes or anything else still remains? Regards. -jt From joe.darcy at oracle.com Thu Sep 18 16:42:49 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 18 Sep 2014 09:42:49 -0700 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: <2054891.PhQFBKa3uh@logouticek> References: <53D4152E.20001@oracle.com> <53E10590.2010801@oracle.com> <541909F3.50605@oracle.com> <2054891.PhQFBKa3uh@logouticek> Message-ID: <541B0B89.7080506@oracle.com> Hi Jarda, On 9/18/2014 9:22 AM, Jaroslav Tulach wrote: > Dne ?t 16. z??? 2014 21:11:31, Joe Darcy napsal(a): >> Hello swing developers, >> >> In response to the earlier call for feedback on the initial swing >> generification changes, several bugs were filed and fixed: > Hello Joe, > I'd heard that NetBeans could no longer be compiled after the initial swing > generification changes. Can you build NetBeans after your recent fixes or > anything else still remains? > On whether or not NetBeans builds, I was hoping you could tell me ;-) These changes in build 30 do address the primary source compatibility issues from the initial round, including those found to impact the NetBeans build. Many of the exemplar test programs that didn't build with b24 do build again with b30. However, I have not tried to do a NetBeans build myself. (Some level of source incompatibility can be acceptable in a feature release, but we don't want gratuitous problems on that front.) Thanks, -Joe From jaroslav.tulach at oracle.com Thu Sep 18 17:08:24 2014 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 18 Sep 2014 19:08:24 +0200 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: <541B0B89.7080506@oracle.com> References: <53D4152E.20001@oracle.com> <2054891.PhQFBKa3uh@logouticek> <541B0B89.7080506@oracle.com> Message-ID: <1632558.3BxJtj8KIv@logouticek> Dne ?t 18. z??? 2014 09:42:49, Joe Darcy napsal(a): > Hi Jarda, > > On 9/18/2014 9:22 AM, Jaroslav Tulach wrote: > > Dne ?t 16. z??? 2014 21:11:31, Joe Darcy napsal(a): > >> Hello swing developers, > >> > >> In response to the earlier call for feedback on the initial swing > > > >> generification changes, several bugs were filed and fixed: > > Hello Joe, > > I'd heard that NetBeans could no longer be compiled after the initial > > swing > > generification changes. Can you build NetBeans after your recent fixes or > > anything else still remains? > > On whether or not NetBeans builds, I was hoping you could tell me ;-) ;-) I may ask around. In general I don't feel responsible for testing my application against newest JDK when I have not changed a single line of code. I believe it is upstream project responsibility to not break us. > These changes in build 30 do address the primary source compatibility > issues from the initial round, including those found to impact the > NetBeans build. Many of the exemplar test programs that didn't build > with b24 do build again with b30. However, I have not tried to do a > NetBeans build myself. I don't necessarily want every JDK engineer to test with NetBeans, but when it is known there was a problem with NetBeans build (because of changes in JDK code), I would expect the verification to be done by JDK engineer prior to announcing "something is fixed". Do I require too much? Building NetBeans is matter of three commands. Did our engineers forget to mention those commands when they complained about NetBeans build being broken? If so let me know, and I make sure they get fired. > (Some level of source incompatibility can be acceptable in a feature > release, but we don't want gratuitous problems on that front.) 100% backward source compatibility is hard to achieve in Java, so yes, we can accept some changes. The requirement however is to find a way to write the source so it compiles on JDK7, JDK8 and JDK9 at the same time. Will that be possible? -jt From joe.darcy at oracle.com Thu Sep 18 17:44:46 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 18 Sep 2014 10:44:46 -0700 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: <1632558.3BxJtj8KIv@logouticek> References: <53D4152E.20001@oracle.com> <2054891.PhQFBKa3uh@logouticek> <541B0B89.7080506@oracle.com> <1632558.3BxJtj8KIv@logouticek> Message-ID: <541B1A0E.8050203@oracle.com> On 9/18/2014 10:08 AM, Jaroslav Tulach wrote: > Dne ?t 18. z??? 2014 09:42:49, Joe Darcy napsal(a): >> Hi Jarda, >> >> On 9/18/2014 9:22 AM, Jaroslav Tulach wrote: >>> Dne ?t 16. z??? 2014 21:11:31, Joe Darcy napsal(a): >>>> Hello swing developers, >>>> >>>> In response to the earlier call for feedback on the initial swing >>>> generification changes, several bugs were filed and fixed: >>> Hello Joe, >>> I'd heard that NetBeans could no longer be compiled after the initial >>> swing >>> generification changes. Can you build NetBeans after your recent fixes or >>> anything else still remains? >> On whether or not NetBeans builds, I was hoping you could tell me ;-) > ;-) I may ask around. In general I don't feel responsible for testing my > application against newest JDK when I have not changed a single line of code. > I believe it is upstream project responsibility to not break us. Well, I think there needs to be a balance in testing (broadly defined) between an upstream project like the JDK and downstream projects relying on it. To a person working on Java project Foo, project Foo is very important, and those JDK guys shouldn't break it ;-) However, project Foo may be relying on implementation details, like the specified-to-be-unspecified order of Class.getMethods which changed in JDK 7, so even if project Foo "breaks" with a JDK update, that doesn't necessarily imply the JDK should be the artifact which is changed. And there are many, many values of Foo. The JDK group does do internal testing of third party Java projects against builds of in-progress JDK releases, but we've also been reaching out to other Java projects to have them try out new JDK builds in their own test frameworks. It is often difficult to do QA on test results of an unfamiliar project; the people involved in a project and often much better positioned to analyze what difference, if any, a new JDK build is making. >> These changes in build 30 do address the primary source compatibility >> issues from the initial round, including those found to impact the >> NetBeans build. Many of the exemplar test programs that didn't build >> with b24 do build again with b30. However, I have not tried to do a >> NetBeans build myself. > I don't necessarily want every JDK engineer to test with NetBeans, but when it > is known there was a problem with NetBeans build (because of changes in JDK > code), I would expect the verification to be done by JDK engineer prior to > announcing "something is fixed". > > Do I require too much? Building NetBeans is matter of three commands. Did our > engineers forget to mention those commands when they complained about NetBeans > build being broken? If so let me know, and I make sure they get fired. I'm not a swing programmer myself and the generification changes (in support of removing warnings from the JDK build) have taken more effort than I anticipated. I welcome assistance from others to help refine these changes to swing. >> (Some level of source incompatibility can be acceptable in a feature >> release, but we don't want gratuitous problems on that front.) > 100% backward source compatibility is hard to achieve in Java, so yes, we can > accept some changes. The requirement however is to find a way to write the > source so it compiles on JDK7, JDK8 and JDK9 at the same time. Will that be > possible? > -jt > Offhand, I don't know anything specific to these swing changes that would prevent that. (There can be subtleties stemming from type inference in language changes, API additions, etc.) In some cases, generating types during the build using an annotation processor can help resolve such version-specific compilation issues. Cheers, -Joe From bengt.rutisson at oracle.com Fri Sep 19 09:02:53 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 19 Sep 2014 11:02:53 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541BF13D.802@oracle.com> Vote: yes Bengt On 9/17/14 3:50 PM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From mike.duigou at oracle.com Fri Sep 19 17:15:46 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 19 Sep 2014 10:15:46 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal Message-ID: Hello all; I've been instigating internal discussions with the Oracle OpenJDK developers about where to do OpenJDK development work for JEP-scale efforts. The scope, duration, and necessary collaboration of JEP-scale efforts makes it appropriate for collaboration to be done using an open, shared version control system rather than just using privately shared patches. As incubation development work it is not appropriate though for this work to be hosted in the jdk9/dev main-line repos. We need a public place to collaborate on issues and features before they are ready for final integration into the main-line JDK repos. It is possible for any OpenJDK developer to request a new OpenJDK project, but the OpenJDK project process seems entirely too heavy-weight to have full OpenJDK projects and/or forests for every issue, feature, exploration or prototype. The problem is both the creation process overhead for new projects as well as the various ongoing administration and maintenance issues attendant with ongoing projects. For larger efforts it is still entirely appropriate to create an OpenJDK project. An extremely rough guide is that if the result of an effort will be a new JDK module or API package then it is probably big enough to deserve a separate project. For everything smaller, shorter or more speculative than is appropriate for a project this new sandbox forest will provide a comfortable home. This proposal has been through a few rounds of internal review and refinement and I believe is nearly ready for activation. Ideally the new sandbox forest would be available for use in early October. Feedback and suggestions welcome. Cheers, Mike Proposal: - Create a new forest in the JDK 9 project for developers to use for experiments, new features, prototypes or any other non-trivial efforts. Goals: - Open : Use OpenJDK public infrastructure - Low-friction : Minimal start-cost and no delays - Collaboration : Individual efforts can self-organize and self-regulate - Approachable : Community members can easily locate, review, comment and participate - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) - Light-weight : Minimal required policy, simpler pre-push rules than main-line jdk9/dev forest - Visible : Links from JEP or issue page and sharable URIs to repo, branches and changesets (*) Authors will require a Committer or Reviewer to push changesets for them. Constraints: - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. - Future OpenJDK bylaws changes may make things easier but we won't block waiting for changes. - Use the JDK 9 project membership and roles. Specifics: - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev forest. - Eligible committers are JDK 9 committers as this is a forest in the JDK 9 project. - Each repo in the forest has a branch (possibly default) that is lockstep updated from parent jdk9/dev repo via cron job syncing or triggered. - Neither jcheck nor hgupdater is enabled for this forest. - All development happens on branches. Committers can create whatever branches in this forest they wish. Branch names "JEP-XXX" and "JDK-XXXXXXX" are, by courtesy, reserved for use of the corresponding JBS issues. Branch names prefixed with an OpenJDK username and a delimiter, by courtesy, are reserved for use of that OpenJDK user. - JBS allows web links to be associated with issues. This can be used to identify the location of development branch for an issue. - Branch owners determine the pre-commit review policy (if any) for their branches. - Branch owners are responsible for reparenting/rebasing their branch to the provided upstream lockstep-with-dev branch however often they wish. - There will be no pushes or promotions from this forest to any other forest. - Integration to the main-line jdk9/dev forest repos will be via the the current JDK 9 changeset review and approval process. - Nightlies, testing, CI, etc. are the responsibility of the individual branch owners. - Since the work in this forest is unreviewed, experimental, prototype or exploratory there is no commitment whatsoever that anything in this forest eventually be part of JDK 9 or any other release. - The forest will be frozen at the release of JDK 9 and possibly deleted sometime thereafter. Feature owners would be responsible for archiving or migrating anything that they wish to retain. Notice and warning will be given on jdk9-dev mailing list to which all JDK 9 project committers are presumed to subscribe. - Changesets pushed to the sandbox forest do not count as "significant contributions" for the purposes of JDK 9 project role eligibility. Desirable Future Changes: - Allow changesets to be pushed to branches in the sandbox forest by users with Author role. This new privilege would be consistent with other Author privileges such as uploading to cr.openjdk.java.net, editing bug reports, and modifying the wiki. Allowing Authors to push changesets would require a modification to the OpenJDK bylaws so we cannot currently implement this policy. Contributors (in no particular order): Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed earlier drafts of this proposal and provided insight and encouragement. From georg.eichinger at racon.at Fri Sep 19 17:24:15 2014 From: georg.eichinger at racon.at (Georg EICHINGER) Date: Fri, 19 Sep 2014 19:24:15 +0200 Subject: =?ISO-8859-1?Q?ist_au=DFer_Haus=2E?= Message-ID: Ich werde ab 18.09.2014 nicht im B?ro sein. Ich kehre zur?ck am 22.09.2014. Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten. Die R?ckmeldung bezieht sich auf ein Mail mit folgendem Thema: RFC: JDK 9 Sandbox Forest Proposal ____________________________________________________________________________________________ Gesendet (c) GRZ/RACON Linz 2014 Agent 'Abwesenheit' Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschlie?lich Informationszwecken. Rechtsgesch?ftliche Erkl?rungen d?rfen ?ber dieses Medium nicht ausgetauscht werden. Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications. From joe.darcy at oracle.com Fri Sep 19 18:50:33 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 19 Sep 2014 11:50:33 -0700 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: References: <53D4152E.20001@oracle.com> <53D9073A.90108@oracle.com> <53E10590.2010801@oracle.com> <541909F3.50605@oracle.com> Message-ID: <541C7AF9.1000408@oracle.com> Hi Andrej, On 09/17/2014 12:53 AM, Andrej Golovnin wrote: > Hi Joe, > > I have tested JDK 9b30 with my project and I still have compile > errors. I have a code which looks like this: > > class BeanNode extends DefaultMutableTreeNode { > ... > } > > @SuppressWarnings("unchecked") > private void aMethod() { > BeanNode node = .... > .... > Enumeration children = node.children(); > ... > } > > The compiler reports for this code following error: > > error: incompatible types: Enumeration cannot be converted > to Enumeration > > because the DefaultMutableTreeNode defines the method #children() as: > > public Enumeration children() { > ... > } The ability to alllow children method to be overriden with a covariant override was one of the major fixes in the generification refinement. However, that was done in the TreeNode interface, but not propagated down to the DefaultMutableTreeNode implementation of TreeNode. If this issue with DefaultMutableTreeNode is common, we can consider making an analogous change there too to have children return an Enumeration rather than Enumeration. Thanks, -Joe > Best regards, > Andrej Golovnin > > On Wed, Sep 17, 2014 at 6:11 AM, Joe Darcy > wrote: > > Hello swing developers, > > In response to the earlier call for feedback on the initial swing > generification changes, several bugs were filed and fixed: > > JDK-8054360: Refine generification of javax.swing > https://bugs.openjdk.java.net/browse/JDK-8054360 > > JDK-8055254: Address source incompatability of JSlider > generification > https://bugs.openjdk.java.net/browse/JDK-8055254 > > These fixes are now present in JDK 9 b30: > > https://jdk9.java.net/download/ > > Please give b30 a try when recompiling your favorite swing code > base and report on how the refined generification works. > > Thanks, > > -Joe > > On 8/5/2014 9:25 AM, Joe Darcy wrote: > > Hello, > > A quick follow-up, I've filed > > JDK-8054360: Refine generification of javax.swing > https://bugs.openjdk.java.net/browse/JDK-8054360#comment-13532821 > > to tweak the generification of TreeNode and possibly a few > other types. > > Thanks for the feedback, > > -Joe > > On 7/30/2014 7:54 AM, Joe Darcy wrote: > > Hi Andrej and Martijn, > > Thanks for responding. > > On 7/28/2014 5:04 AM, Andrej Golovnin wrote: > > Hi Joe, > > I'm not sure if it is what you are looking for. > > > For context, the general evolution policy of the JDK: > > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy > > > > includes "avoid introducing source incompatibilities." As > this is a large generification change to swing, some level > of source incompatibility may be acceptable in a platform > release like JDK 9, but if there are very widespread > issues, some of the changes may be reconsidered. > > The request to try out the changes was to get enough > information to see if any (partial) reconsideration was > warranted. > > > But I tried to compile my project with the new build. > And I got a compile error in one of my classes. I have > a class which implements the TreeNode interface and > looks like this: > > class MyTreeNode implements TreeNode { > .... > @Override > public Enumeration children() { > return ....; > } > ... > } > > The error message is: "return type > Enumeration is not compatible with > Enumeration". > > > because the DefaultMutableTreeNode defines the method > #children() as: > > public Enumeration children() { > ... > } > > If I change (see attached patch) the definition of the > children()-method in the TreeNode-interface to: > > public interface TreeNode { > ... > Enumeration children(); > ... > } > > then my code compiles. > > > That design issue was raised during code review: > > http://mail.openjdk.java.net/pipermail/swing-dev/2014-June/003643.html > > "It was not immediately clear how > javax.swing.tree.TreeNode.children(), > which returns a raw Enumeration, should be generified. I > changed it to > > Enumeration children(); > > and that seems to work fine. Something like > > Enumeration > > with a covariant override would save a few casts in a private > implementation, but generally doesn't seem to be a good > trade-off since > many normal clients could be inconvenienced dealing with > the wildcard." > > If generified subclasses of TreeNode are common, the > generification of children may need reconsideration. > > > BTW, a good test for your changes would be to try to > compile NetBeans and/or IntelliJ IDEA using the new > JDK 9 build. They both are really big Swing > applications which make use maybe of all Swing APIs. > > > > My preference would be for the NetBeans and IntelliJ teams > to do that task :-) > > Thanks, > > -Joe > > > > From kmcguigan at twitter.com Fri Sep 19 19:36:26 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Fri, 19 Sep 2014 15:36:26 -0400 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: This sounds great! Thanks for doing this. On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou wrote: > Hello all; > > I've been instigating internal discussions with the Oracle OpenJDK > developers about where to do OpenJDK development work for JEP-scale > efforts. The scope, duration, and necessary collaboration of JEP-scale > efforts makes it appropriate for collaboration to be done using an open, > shared version control system rather than just using privately shared > patches. As incubation development work it is not appropriate though for > this work to be hosted in the jdk9/dev main-line repos. We need a public > place to collaborate on issues and features before they are ready for final > integration into the main-line JDK repos. > > It is possible for any OpenJDK developer to request a new OpenJDK project, > but the OpenJDK project process seems entirely too heavy-weight to have > full OpenJDK projects and/or forests for every issue, feature, exploration > or prototype. The problem is both the creation process overhead for new > projects as well as the various ongoing administration and maintenance > issues attendant with ongoing projects. For larger efforts it is still > entirely appropriate to create an OpenJDK project. An extremely rough guide > is that if the result of an effort will be a new JDK module or API package > then it is probably big enough to deserve a separate project. For > everything smaller, shorter or more speculative than is appropriate for a > project this new sandbox forest will provide a comfortable home. > > This proposal has been through a few rounds of internal review and > refinement and I believe is nearly ready for activation. Ideally the new > sandbox forest would be available for use in early October. > > Feedback and suggestions welcome. > > Cheers, > > Mike > > > Proposal: > > - Create a new forest in the JDK 9 project for developers to use for > experiments, new features, prototypes or any other non-trivial efforts. > > > Goals: > > - Open : Use OpenJDK public infrastructure > - Low-friction : Minimal start-cost and no delays > - Collaboration : Individual efforts can self-organize and self-regulate > - Approachable : Community members can easily locate, review, comment and > participate > - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) > - Light-weight : Minimal required policy, simpler pre-push rules than > main-line jdk9/dev forest > - Visible : Links from JEP or issue page and sharable URIs to repo, > branches and changesets > > (*) Authors will require a Committer or Reviewer to push changesets for > them. > > > Constraints: > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > - Future OpenJDK bylaws changes may make things easier but we won't block > waiting for changes. > - Use the JDK 9 project membership and roles. > > > Specifics: > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev > forest. > - Eligible committers are JDK 9 committers as this is a forest in the JDK > 9 project. > - Each repo in the forest has a branch (possibly default) that is lockstep > updated from parent jdk9/dev repo via cron job syncing or triggered. > - Neither jcheck nor hgupdater is enabled for this forest. > - All development happens on branches. Committers can create whatever > branches in this forest they wish. Branch names "JEP-XXX" and "JDK-XXXXXXX" > are, by courtesy, reserved for use of the corresponding JBS issues. Branch > names prefixed with an OpenJDK username and a delimiter, by courtesy, are > reserved for use of that OpenJDK user. > - JBS allows web links to be associated with issues. This can be used to > identify the location of development branch for an issue. > - Branch owners determine the pre-commit review policy (if any) for their > branches. > - Branch owners are responsible for reparenting/rebasing their branch to > the provided upstream lockstep-with-dev branch however often they wish. > - There will be no pushes or promotions from this forest to any other > forest. > - Integration to the main-line jdk9/dev forest repos will be via the the > current JDK 9 changeset review and approval process. > - Nightlies, testing, CI, etc. are the responsibility of the individual > branch owners. > - Since the work in this forest is unreviewed, experimental, prototype or > exploratory there is no commitment whatsoever that anything in this forest > eventually be part of JDK 9 or any other release. > - The forest will be frozen at the release of JDK 9 and possibly deleted > sometime thereafter. Feature owners would be responsible for archiving or > migrating anything that they wish to retain. Notice and warning will be > given on jdk9-dev mailing list to which all JDK 9 project committers are > presumed to subscribe. > - Changesets pushed to the sandbox forest do not count as "significant > contributions" for the purposes of JDK 9 project role eligibility. > > > Desirable Future Changes: > > - Allow changesets to be pushed to branches in the sandbox forest by users > with Author role. This new privilege would be consistent with other Author > privileges such as uploading to cr.openjdk.java.net, editing bug reports, > and modifying the wiki. Allowing Authors to push changesets would require a > modification to the OpenJDK bylaws so we cannot currently implement this > policy. > > > Contributors (in no particular order): > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John > Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed > earlier drafts of this proposal and provided insight and encouragement. > -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcguigan at twitter.com From martijnverburg at gmail.com Sat Sep 20 18:14:52 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 20 Sep 2014 19:14:52 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: +1 (from an outsider) On Friday, 19 September 2014, Keith McGuigan wrote: > This sounds great! Thanks for doing this. > > On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou > wrote: > > > Hello all; > > > > I've been instigating internal discussions with the Oracle OpenJDK > > developers about where to do OpenJDK development work for JEP-scale > > efforts. The scope, duration, and necessary collaboration of JEP-scale > > efforts makes it appropriate for collaboration to be done using an open, > > shared version control system rather than just using privately shared > > patches. As incubation development work it is not appropriate though for > > this work to be hosted in the jdk9/dev main-line repos. We need a public > > place to collaborate on issues and features before they are ready for > final > > integration into the main-line JDK repos. > > > > It is possible for any OpenJDK developer to request a new OpenJDK > project, > > but the OpenJDK project process seems entirely too heavy-weight to have > > full OpenJDK projects and/or forests for every issue, feature, > exploration > > or prototype. The problem is both the creation process overhead for new > > projects as well as the various ongoing administration and maintenance > > issues attendant with ongoing projects. For larger efforts it is still > > entirely appropriate to create an OpenJDK project. An extremely rough > guide > > is that if the result of an effort will be a new JDK module or API > package > > then it is probably big enough to deserve a separate project. For > > everything smaller, shorter or more speculative than is appropriate for a > > project this new sandbox forest will provide a comfortable home. > > > > This proposal has been through a few rounds of internal review and > > refinement and I believe is nearly ready for activation. Ideally the new > > sandbox forest would be available for use in early October. > > > > Feedback and suggestions welcome. > > > > Cheers, > > > > Mike > > > > > > Proposal: > > > > - Create a new forest in the JDK 9 project for developers to use for > > experiments, new features, prototypes or any other non-trivial efforts. > > > > > > Goals: > > > > - Open : Use OpenJDK public infrastructure > > - Low-friction : Minimal start-cost and no delays > > - Collaboration : Individual efforts can self-organize and self-regulate > > - Approachable : Community members can easily locate, review, comment > and > > participate > > - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) > > - Light-weight : Minimal required policy, simpler pre-push rules than > > main-line jdk9/dev forest > > - Visible : Links from JEP or issue page and sharable URIs to repo, > > branches and changesets > > > > (*) Authors will require a Committer or Reviewer to push changesets for > > them. > > > > > > Constraints: > > > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > > - Future OpenJDK bylaws changes may make things easier but we won't block > > waiting for changes. > > - Use the JDK 9 project membership and roles. > > > > > > Specifics: > > > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev > > forest. > > - Eligible committers are JDK 9 committers as this is a forest in the JDK > > 9 project. > > - Each repo in the forest has a branch (possibly default) that is > lockstep > > updated from parent jdk9/dev repo via cron job syncing or triggered. > > - Neither jcheck nor hgupdater is enabled for this forest. > > - All development happens on branches. Committers can create whatever > > branches in this forest they wish. Branch names "JEP-XXX" and > "JDK-XXXXXXX" > > are, by courtesy, reserved for use of the corresponding JBS issues. > Branch > > names prefixed with an OpenJDK username and a delimiter, by courtesy, are > > reserved for use of that OpenJDK user. > > - JBS allows web links to be associated with issues. This can be used to > > identify the location of development branch for an issue. > > - Branch owners determine the pre-commit review policy (if any) for their > > branches. > > - Branch owners are responsible for reparenting/rebasing their branch to > > the provided upstream lockstep-with-dev branch however often they wish. > > - There will be no pushes or promotions from this forest to any other > > forest. > > - Integration to the main-line jdk9/dev forest repos will be via the the > > current JDK 9 changeset review and approval process. > > - Nightlies, testing, CI, etc. are the responsibility of the individual > > branch owners. > > - Since the work in this forest is unreviewed, experimental, prototype or > > exploratory there is no commitment whatsoever that anything in this > forest > > eventually be part of JDK 9 or any other release. > > - The forest will be frozen at the release of JDK 9 and possibly deleted > > sometime thereafter. Feature owners would be responsible for archiving or > > migrating anything that they wish to retain. Notice and warning will be > > given on jdk9-dev mailing list to which all JDK 9 project committers are > > presumed to subscribe. > > - Changesets pushed to the sandbox forest do not count as "significant > > contributions" for the purposes of JDK 9 project role eligibility. > > > > > > Desirable Future Changes: > > > > - Allow changesets to be pushed to branches in the sandbox forest by > users > > with Author role. This new privilege would be consistent with other > Author > > privileges such as uploading to cr.openjdk.java.net, editing bug > reports, > > and modifying the wiki. Allowing Authors to push changesets would > require a > > modification to the OpenJDK bylaws so we cannot currently implement this > > policy. > > > > > > Contributors (in no particular order): > > > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John > > Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed > > earlier drafts of this proposal and provided insight and encouragement. > > > > > > -- > > [image: twitter-icon-large.png] > > Keith McGuigan > > @kamggg > > kmcguigan at twitter.com > -- Cheers, Martijn From pointo1d at gmail.com Sat Sep 20 22:05:38 2014 From: pointo1d at gmail.com (pointo1d) Date: Sat, 20 Sep 2014 23:05:38 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <541DFA32.1040503@gmail.com> Hiya Mike , On 19/09/14 18:15, Mike Duigou wrote: > Hello all; > > I've been instigating internal discussions with the Oracle OpenJDK developers about where to do OpenJDK development work for JEP-scale efforts. The scope, duration, and necessary collaboration of JEP-scale efforts makes it appropriate for collaboration to be done using an open, shared version control system rather than just using privately shared patches. As incubation development work it is not appropriate though for this work to be hosted in the jdk9/dev main-line repos. We need a public place to collaborate on issues and features before they are ready for final integration into the main-line JDK repos. > > It is possible for any OpenJDK developer to request a new OpenJDK project, but the OpenJDK project process seems entirely too heavy-weight to have full OpenJDK projects and/or forests for every issue, feature, exploration or prototype. The problem is both the creation process overhead for new projects as well as the various ongoing administration and maintenance issues attendant with ongoing projects. For larger efforts it is still entirely appropriate to create an OpenJDK project. An extremely rough guide is that if the result of an effort will be a new JDK module or API package then it is probably big enough to deserve a separate project. For everything smaller, shorter or more speculative than is appropriate for a project this new sandbox forest will provide a comfortable home. > > This proposal has been through a few rounds of internal review and refinement and I believe is nearly ready for activation. Ideally the new sandbox forest would be available for use in early October. > > Feedback and suggestions welcome. > > Cheers, > > Mike > > > Proposal: > > - Create a new forest in the JDK 9 project for developers to use for experiments, new features, prototypes or any other non-trivial efforts. > > > Goals: > > - Open : Use OpenJDK public infrastructure > - Low-friction : Minimal start-cost and no delays > - Collaboration : Individual efforts can self-organize and self-regulate > - Approachable : Community members can easily locate, review, comment and participate > - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) > - Light-weight : Minimal required policy, simpler pre-push rules than main-line jdk9/dev forest > - Visible : Links from JEP or issue page and sharable URIs to repo, branches and changesets > > (*) Authors will require a Committer or Reviewer to push changesets for them. > > > Constraints: > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > - Future OpenJDK bylaws changes may make things easier but we won't block waiting for changes. > - Use the JDK 9 project membership and roles. > > > Specifics: > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev forest. > - Eligible committers are JDK 9 committers as this is a forest in the JDK 9 project. > - Each repo in the forest has a branch (possibly default) that is lockstep updated from parent jdk9/dev repo via cron job syncing or triggered. > - Neither jcheck nor hgupdater is enabled for this forest. > - All development happens on branches. Committers can create whatever branches in this forest they wish. Branch names "JEP-XXX" and "JDK-XXXXXXX" are, by courtesy, reserved for use of the corresponding JBS issues. Branch names prefixed with an OpenJDK username and a delimiter, by courtesy, are reserved for use of that OpenJDK user. > - JBS allows web links to be associated with issues. This can be used to identify the location of development branch for an issue. > - Branch owners determine the pre-commit review policy (if any) for their branches. > - Branch owners are responsible for reparenting/rebasing their branch to the provided upstream lockstep-with-dev branch however often they wish. > - There will be no pushes or promotions from this forest to any other forest. > - Integration to the main-line jdk9/dev forest repos will be via the the current JDK 9 changeset review and approval process. > - Nightlies, testing, CI, etc. are the responsibility of the individual branch owners. > - Since the work in this forest is unreviewed, experimental, prototype or exploratory there is no commitment whatsoever that anything in this forest eventually be part of JDK 9 or any other release. > - The forest will be frozen at the release of JDK 9 and possibly deleted sometime thereafter. Feature owners would be responsible for archiving or migrating anything that they wish to retain. Notice and warning will be given on jdk9-dev mailing list to which all JDK 9 project committers are presumed to subscribe. > - Changesets pushed to the sandbox forest do not count as "significant contributions" for the purposes of JDK 9 project role eligibility. > > > Desirable Future Changes: > > - Allow changesets to be pushed to branches in the sandbox forest by users with Author role. This new privilege would be consistent with other Author privileges such as uploading to cr.openjdk.java.net, editing bug reports, and modifying the wiki. Allowing Authors to push changesets would require a modification to the OpenJDK bylaws so we cannot currently implement this policy. > > > Contributors (in no particular order): > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed earlier drafts of this proposal and provided insight and encouragement. Eminently sensible - as, I now know, are all things Digou :-) Rgds , -- ?Dave Pointon FIAP MBCS - Contractor engaged by IBM Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe From benjamin.john.evans at gmail.com Sun Sep 21 07:30:51 2014 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Sun, 21 Sep 2014 08:30:51 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: Would this be a good place for betterrev to baseline against? & +1 from someone else who doesn't get a vote. On 20 Sep 2014 19:16, "Martijn Verburg" wrote: > +1 (from an outsider) > > On Friday, 19 September 2014, Keith McGuigan > wrote: > > > This sounds great! Thanks for doing this. > > > > On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou > > wrote: > > > > > Hello all; > > > > > > I've been instigating internal discussions with the Oracle OpenJDK > > > developers about where to do OpenJDK development work for JEP-scale > > > efforts. The scope, duration, and necessary collaboration of JEP-scale > > > efforts makes it appropriate for collaboration to be done using an > open, > > > shared version control system rather than just using privately shared > > > patches. As incubation development work it is not appropriate though > for > > > this work to be hosted in the jdk9/dev main-line repos. We need a > public > > > place to collaborate on issues and features before they are ready for > > final > > > integration into the main-line JDK repos. > > > > > > It is possible for any OpenJDK developer to request a new OpenJDK > > project, > > > but the OpenJDK project process seems entirely too heavy-weight to have > > > full OpenJDK projects and/or forests for every issue, feature, > > exploration > > > or prototype. The problem is both the creation process overhead for new > > > projects as well as the various ongoing administration and maintenance > > > issues attendant with ongoing projects. For larger efforts it is still > > > entirely appropriate to create an OpenJDK project. An extremely rough > > guide > > > is that if the result of an effort will be a new JDK module or API > > package > > > then it is probably big enough to deserve a separate project. For > > > everything smaller, shorter or more speculative than is appropriate > for a > > > project this new sandbox forest will provide a comfortable home. > > > > > > This proposal has been through a few rounds of internal review and > > > refinement and I believe is nearly ready for activation. Ideally the > new > > > sandbox forest would be available for use in early October. > > > > > > Feedback and suggestions welcome. > > > > > > Cheers, > > > > > > Mike > > > > > > > > > Proposal: > > > > > > - Create a new forest in the JDK 9 project for developers to use for > > > experiments, new features, prototypes or any other non-trivial efforts. > > > > > > > > > Goals: > > > > > > - Open : Use OpenJDK public infrastructure > > > - Low-friction : Minimal start-cost and no delays > > > - Collaboration : Individual efforts can self-organize and > self-regulate > > > - Approachable : Community members can easily locate, review, comment > > and > > > participate > > > - Participation : Open to all JDK 9 Reviewers, Committers and > Authors(*) > > > - Light-weight : Minimal required policy, simpler pre-push rules than > > > main-line jdk9/dev forest > > > - Visible : Links from JEP or issue page and sharable URIs to > repo, > > > branches and changesets > > > > > > (*) Authors will require a Committer or Reviewer to push changesets for > > > them. > > > > > > > > > Constraints: > > > > > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > > > - Future OpenJDK bylaws changes may make things easier but we won't > block > > > waiting for changes. > > > - Use the JDK 9 project membership and roles. > > > > > > > > > Specifics: > > > > > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev > > > forest. > > > - Eligible committers are JDK 9 committers as this is a forest in the > JDK > > > 9 project. > > > - Each repo in the forest has a branch (possibly default) that is > > lockstep > > > updated from parent jdk9/dev repo via cron job syncing or triggered. > > > - Neither jcheck nor hgupdater is enabled for this forest. > > > - All development happens on branches. Committers can create whatever > > > branches in this forest they wish. Branch names "JEP-XXX" and > > "JDK-XXXXXXX" > > > are, by courtesy, reserved for use of the corresponding JBS issues. > > Branch > > > names prefixed with an OpenJDK username and a delimiter, by courtesy, > are > > > reserved for use of that OpenJDK user. > > > - JBS allows web links to be associated with issues. This can be used > to > > > identify the location of development branch for an issue. > > > - Branch owners determine the pre-commit review policy (if any) for > their > > > branches. > > > - Branch owners are responsible for reparenting/rebasing their branch > to > > > the provided upstream lockstep-with-dev branch however often they wish. > > > - There will be no pushes or promotions from this forest to any other > > > forest. > > > - Integration to the main-line jdk9/dev forest repos will be via the > the > > > current JDK 9 changeset review and approval process. > > > - Nightlies, testing, CI, etc. are the responsibility of the individual > > > branch owners. > > > - Since the work in this forest is unreviewed, experimental, prototype > or > > > exploratory there is no commitment whatsoever that anything in this > > forest > > > eventually be part of JDK 9 or any other release. > > > - The forest will be frozen at the release of JDK 9 and possibly > deleted > > > sometime thereafter. Feature owners would be responsible for archiving > or > > > migrating anything that they wish to retain. Notice and warning will be > > > given on jdk9-dev mailing list to which all JDK 9 project committers > are > > > presumed to subscribe. > > > - Changesets pushed to the sandbox forest do not count as "significant > > > contributions" for the purposes of JDK 9 project role eligibility. > > > > > > > > > Desirable Future Changes: > > > > > > - Allow changesets to be pushed to branches in the sandbox forest by > > users > > > with Author role. This new privilege would be consistent with other > > Author > > > privileges such as uploading to cr.openjdk.java.net, editing bug > > reports, > > > and modifying the wiki. Allowing Authors to push changesets would > > require a > > > modification to the OpenJDK bylaws so we cannot currently implement > this > > > policy. > > > > > > > > > Contributors (in no particular order): > > > > > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John > > > Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all > reviewed > > > earlier drafts of this proposal and provided insight and encouragement. > > > > > > > > > > > -- > > > > [image: twitter-icon-large.png] > > > > Keith McGuigan > > > > @kamggg > > > > kmcguigan at twitter.com > > > > > -- > Cheers, > Martijn > From igor.veresov at oracle.com Sun Sep 21 09:10:49 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 21 Sep 2014 02:10:49 -0700 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: Vote: yes igor On Sep 17, 2014, at 6:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From behrangsa at gmail.com Sun Sep 21 13:10:27 2014 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Sun, 21 Sep 2014 23:10:27 +1000 Subject: Fwd: 2 new feature proposals: class extensions and import aliases In-Reply-To: References: Message-ID: Hi all, This is nothing new as there are other languages that have this feature already, but now that Java has syntactical support for closures, etc. I think it would be nice if it was possible to augment classes with custom methods. For example, if I wanted to add a method times(Runnable c) to Integer that runs the given block multiple times so that I could type the following code: 5.times(() -> { System.out.println("Hello, World"); }) All I needed to do was to define an "extension" for Integer: *com.foo.IntegerExtension* *========================* extension IntegerExtension extends Integer { public void times(Runnable r) { for (int i = this; i < count; i++) { c.run(); } } } Then I can activate the IntegerExtension explicitly by importing it into a class: *com.foo.Main* *============* import com.foo.IntegerExtension; public class Main { public static void main(String[] args) { 5.times(() -> { System.out.println("Hello, World"); }) } } Of course this is just to show the idea and the implementation can be quite different. Another *very simple* feature that I wish Java had is importing a class with an alias, similar to Groovy: import java.util.Date; import java.sql.Date as SDate; SDate sDate = ...; Date date = ...; // or import java.awt.Point as Vector; spaceship.move(new Vector(+5, -10)); What do you fellows think? Best regards, Behrang http://www.behrang.org From david.r.chase at oracle.com Sun Sep 21 14:41:48 2014 From: david.r.chase at oracle.com (David Chase) Date: Sun, 21 Sep 2014 10:41:48 -0400 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: I vote yes, I have some feedback/questions on the proposal: On 2014-09-19, at 1:15 PM, Mike Duigou wrote: > Goals: > > - Open : Use OpenJDK public infrastructure > - Low-friction : Minimal start-cost and no delays I ran into one specific problem attempting to add stuff to jdk libraries as part of Panama, which is that the creation of a new module is error-prone. In my case, it is only error-prone, I never succeeded, I assume I missed some crucial step. I think we want people to be able to work in this style because at least one of the IDE tools (NetBeans) can sometimes get confused when working with a subset of the source files in java.base. (and even when it works, it?s another little speedbump on the way to configure NetBeans to work properly in this case) So I think we need to address this and write up a recipe, including the need to regenerate configure files etc before commit. Ideally the recipe will contain copy-and-pasteable commands where that is possible. > Specifics: > - Neither jcheck nor hgupdater is enabled for this forest. Do we want something like jcheck to keep the code moderately clean ? for example, there?s the personal ?fixit? script I?ve informally put up for consideration for Codetools (it?s not a commit hook, it merely checks a bunch of source code rules and gives you the the option of an automated fix). This is purely a matter of keeping code clean, on the off chance that we do include some of it in a future release. > - All development happens on branches. It would be lovely to have a short tutorial on how we do this written up and put in an easy-to-access place. Branching still makes me nervous. David From mike.duigou at oracle.com Sun Sep 21 15:06:14 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 21 Sep 2014 08:06:14 -0700 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: Vote: YES On Sep 17 2014, at 06:50 , Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From Alan.Bateman at oracle.com Sun Sep 21 17:01:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Sep 2014 18:01:31 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <541F046B.7000608@oracle.com> On 21/09/2014 15:41, David Chase wrote: > : > I ran into one specific problem attempting to add stuff to > jdk libraries as part of Panama, which is that the creation > of a new module is error-prone. In my case, it is only > error-prone, I never succeeded, I assume I missed some > crucial step. There isn't a module system in JDK 9 yet, it's going to take time to bring all the pieces in and there is a lot of transition and changes along the way. We tried to make it clear in JEP 200 that until there is a module system in place that it would require maintaining the XML document that defines the modular structure. That's the document that gets translated early in the build now to create the build dependences, it is also used to verify the resulting bits at the end. So it is awkward at the moment but should get much better once we have a module system in place. -Alan. From david.r.chase at oracle.com Sun Sep 21 17:13:30 2014 From: david.r.chase at oracle.com (David Chase) Date: Sun, 21 Sep 2014 13:13:30 -0400 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: <541F046B.7000608@oracle.com> References: <541F046B.7000608@oracle.com> Message-ID: On 2014-09-21, at 1:01 PM, Alan Bateman wrote: > There isn't a module system in JDK 9 yet, it's going to take time to bring all the pieces in and there is a lot of transition and changes along the way. We tried to make it clear in JEP 200 that until there is a module system in place that it would require maintaining the XML document that defines the modular structure. That's the document that gets translated early in the build now to create the build dependences, it is also used to verify the resulting bits at the end. So it is awkward at the moment but should get much better once we have a module system in place. I tried to knit my additions into that xml document, reconfigured, etc, but I must have mispronounced one of the magic words. I assume it must have been some basically stupid clerical error, but after 3 tries I decided to just stuff it into java.base, which also seems suboptimal, but less suboptimal that build-borking failure. David From Alan.Bateman at oracle.com Sun Sep 21 17:20:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Sep 2014 18:20:02 +0100 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <541F08C2.4070804@oracle.com> On 21/09/2014 08:30, Ben Evans wrote: > Would this be a good place for betterrev to baseline against? > Not wishing to make the contribution workflow any more complicated but I would think it depends on whether it's it a patch for a a specific issue or an idea for a new feature might iterate and evolve in the sandbox project. Some things might be obvious as to which route to take, other things might find the right route after some discussion. -Alan From doug.simon at oracle.com Sun Sep 21 19:19:28 2014 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 21 Sep 2014 21:19:28 +0200 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <94E9BFE5-A9CE-4172-8B16-FA46DE551D5B@oracle.com> On Sep 19, 2014, at 7:15 PM, Mike Duigou wrote: > Hello all; > > I've been instigating internal discussions with the Oracle OpenJDK developers about where to do OpenJDK development work for JEP-scale efforts. The scope, duration, and necessary collaboration of JEP-scale efforts makes it appropriate for collaboration to be done using an open, shared version control system rather than just using privately shared patches. As incubation development work it is not appropriate though for this work to be hosted in the jdk9/dev main-line repos. We need a public place to collaborate on issues and features before they are ready for final integration into the main-line JDK repos. > > It is possible for any OpenJDK developer to request a new OpenJDK project, but the OpenJDK project process seems entirely too heavy-weight to have full OpenJDK projects and/or forests for every issue, feature, exploration or prototype. The problem is both the creation process overhead for new projects as well as the various ongoing administration and maintenance issues attendant with ongoing projects. For larger efforts it is still entirely appropriate to create an OpenJDK project. An extremely rough guide is that if the result of an effort will be a new JDK module or API package then it is probably big enough to deserve a separate project. For everything smaller, shorter or more speculative than is appropriate for a project this new sandbox forest will provide a comfortable home. > > This proposal has been through a few rounds of internal review and refinement and I believe is nearly ready for activation. Ideally the new sandbox forest would be available for use in early October. > > Feedback and suggestions welcome. > > Cheers, > > Mike > > > Proposal: > > - Create a new forest in the JDK 9 project for developers to use for experiments, new features, prototypes or any other non-trivial efforts. > > > Goals: > > - Open : Use OpenJDK public infrastructure > - Low-friction : Minimal start-cost and no delays > - Collaboration : Individual efforts can self-organize and self-regulate > - Approachable : Community members can easily locate, review, comment and participate Towards the goal of easier reviewing, are there any plans for adopting a code review tool (such as Crucible) as part of this proposal? -Doug From mparchet at sunrise.ch Sun Sep 21 22:07:51 2014 From: mparchet at sunrise.ch (=?utf-8?Q?Parchet_Micha=C3=ABl?=) Date: Mon, 22 Sep 2014 00:07:51 +0200 Subject: Fwd: Openjdk 9 References: <5541D63E-2E85-4585-B65F-43FD4EF5EDC6@sunrise.ch> Message-ID: <15BBB2D1-DC74-4161-BE7B-9FAB77232068@sunrise.ch> > Exp?diteur: Parchet Micha?l > Date: 19 septembre 2014 22:19:07 UTC+2 > Destinataire: "discuss at openjdk.java.net" > Objet: Openjdk 9 > > Hi, > > I'm waiting for open jdk 9 since I have view nothing about open jdk 8 > Could you tell me more about it ? > > Thanks for your answer. > > Best regards > > mparchet > > From weijun.wang at oracle.com Mon Sep 22 00:31:32 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 22 Sep 2014 08:31:32 +0800 Subject: Openjdk 9 In-Reply-To: <15BBB2D1-DC74-4161-BE7B-9FAB77232068@sunrise.ch> References: <5541D63E-2E85-4585-B65F-43FD4EF5EDC6@sunrise.ch> <15BBB2D1-DC74-4161-BE7B-9FAB77232068@sunrise.ch> Message-ID: <3B6DD5B3-22CA-44ED-8657-E1E27566F9F1@oracle.com> http://openjdk.java.net/projects/jdk9/ includes links to repos and proposed features. Is this what you are looking for? --Max On Sep 22, 2014, at 6:07, Parchet Micha?l wrote: > > >> Exp?diteur: Parchet Micha?l >> Date: 19 septembre 2014 22:19:07 UTC+2 >> Destinataire: "discuss at openjdk.java.net" >> Objet: Openjdk 9 >> >> Hi, >> >> I'm waiting for open jdk 9 since I have view nothing about open jdk 8 >> Could you tell me more about it ? >> >> Thanks for your answer. >> >> Best regards >> >> mparchet >> >> From jaroslav.bachorik at oracle.com Mon Sep 22 08:05:26 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 22 Sep 2014 10:05:26 +0200 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541FD846.6050808@oracle.com> Vote: YES -JB- On 09/17/2014 03:50 PM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From volker.simonis at gmail.com Mon Sep 22 08:38:29 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Sep 2014 10:38:29 +0200 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: On Sun, Sep 21, 2014 at 4:41 PM, David Chase wrote: > I vote yes, I have some feedback/questions on the proposal: > > On 2014-09-19, at 1:15 PM, Mike Duigou wrote: >> Goals: >> >> - Open : Use OpenJDK public infrastructure >> - Low-friction : Minimal start-cost and no delays > > I ran into one specific problem attempting to add stuff to > jdk libraries as part of Panama, which is that the creation > of a new module is error-prone. In my case, it is only > error-prone, I never succeeded, I assume I missed some > crucial step. I think we want people to be able to work in > this style because at least one of the IDE tools (NetBeans) > can sometimes get confused when working with a subset of the > source files in java.base. (and even when it works, it?s another > little speedbump on the way to configure NetBeans to work > properly in this case) > > So I think we need to address this and write up a recipe, > including the need to regenerate configure files etc before > commit. Ideally the recipe will contain copy-and-pasteable > commands where that is possible. > >> Specifics: > >> - Neither jcheck nor hgupdater is enabled for this forest. > > Do we want something like jcheck to keep the code moderately > clean ? for example, there?s the personal ?fixit? script > I?ve informally put up for consideration for Codetools (it?s > not a commit hook, it merely checks a bunch of source code > rules and gives you the the option of an automated fix). > This is purely a matter of keeping code clean, on the off > chance that we do include some of it in a future release. > >> - All development happens on branches. > > It would be lovely to have a short tutorial on how we do > this written up and put in an easy-to-access place. > Branching still makes me nervous. > I'm also not familiar with branches. How do branches work in a Mercurial forest? Is it possible to easily develop on a branch if you need to push to different repositories within the whole sandbox forest (i.e. hotspot and jdk). Is it somehow possible to enforce the smae branch on all the repos in a forest? I agree that the OpenJDK project process is much too heavyweight for many smaller project, but in the end you always get a complete forest. I'm just curious if cross repository changes can be easily developed with branches. Thanks, Volker > David > From volker.simonis at gmail.com Mon Sep 22 09:06:11 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Sep 2014 11:06:11 +0200 Subject: When will jdk9/client/jdk be merged into jdk9/dev/jdk? Message-ID: Hi, can somebody please tell me when jdk9/client/jdk will be merged into jdk9/dev/jdk? I thought this happens regularly on a weekly base, but maybe that's wrong? I'm just asking because I pushed a fix which repaired the AIX build (8057934) to the jdk9/client/jdk ropository on September 10th but it hasn't been propagated to jdk9/dev/jdk until now. I there something I can do to speed up this process (i.e. can I manually push a change which already is in jdk9/client/jdk to jdk9/dev/jdk?) Thank you and best regards, Volker From Alan.Bateman at oracle.com Mon Sep 22 09:51:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Sep 2014 10:51:06 +0100 Subject: When will jdk9/client/jdk be merged into jdk9/dev/jdk? In-Reply-To: References: Message-ID: <541FF10A.9090408@oracle.com> On 22/09/2014 10:06, Volker Simonis wrote: > Hi, > > can somebody please tell me when jdk9/client/jdk will be merged into > jdk9/dev/jdk? I thought this happens regularly on a weekly base, but > maybe that's wrong? > > I'm just asking because I pushed a fix which repaired the AIX build > (8057934) to the jdk9/client/jdk ropository on September 10th but it > hasn't been propagated to jdk9/dev/jdk until now. I there something I > can do to speed up this process (i.e. can I manually push a change > which already is in jdk9/client/jdk to jdk9/dev/jdk?) > AFAIK, changes pushed to jdk9/client are integrated into jdk9/dev every 2 weeks. The last integration seems to have been done by Phil on September 12. That integration was probably based on a snapshot of the outgoing changes taken several days before that so my guess is that your change just missed the bus. If the buses are running on time then it's likely that your change will get to jdk9/dev later this week. Your mail is a reminder that we need to question again the need for jdk9/client forest. The latency issues are a big problem, esp. when working with project forests that pull from master. If a change that you need is pushed to jdk9/client then it can take many weeks to get to the place where you actually need it. The other issue is the clean-up and refactoring that covers many areas, it becomes totally uneconomical when contributors are forced to split the changes. There was a good discussion here (in Dec 2013/Jan 2014) about the integration forests that lead to the creation of jdk9/dev and jdk9/client. Key questions at the time were whether changes to the client libraries needed manual testing and the reliability of the automated tests. Testing client libraries is clearly a challenge and I think it would be good to establish where things are currently at. More generally, we've been living with the current arrangement for 9 months or so and it would be a good time to assess if people think it is working well or not. -Alan From Sergey.Bylokhov at oracle.com Mon Sep 22 10:11:59 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Sep 2014 14:11:59 +0400 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <541FF5EF.2020809@oracle.com> Vote: YES On 21.09.2014 13:10, Igor Veresov wrote: > Vote: yes > > igor > > On Sep 17, 2014, at 6:50 AM, Volker Simonis wrote: > >> I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. >> >> Goetz (actually G?tz for those of you who can read umlauts :) is a >> long standing member of the JVM team at SAP, one of the architects of >> our Itanium and PowerPC ports and a real C2 maven. He's the main >> contributor of the C2 PowerPC port but has also contributed changes in >> many other part of the HotSpot including memory ordering changes, code >> cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and >> jdk9 committer for the last two years and authored about 80 changes >> during this time: >> >> http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 >> >> Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 >> >> Only current jdk9 Reviewers [1] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this >> mailing list. >> >> For Three-Vote Consensus voting instructions, see [2]. >> >> Volker Simonis >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#reviewer-vote -- Best regards, Sergey. From volker.simonis at gmail.com Mon Sep 22 13:10:17 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Sep 2014 15:10:17 +0200 Subject: When will jdk9/client/jdk be merged into jdk9/dev/jdk? In-Reply-To: <541FF10A.9090408@oracle.com> References: <541FF10A.9090408@oracle.com> Message-ID: On Mon, Sep 22, 2014 at 11:51 AM, Alan Bateman wrote: > On 22/09/2014 10:06, Volker Simonis wrote: >> >> Hi, >> >> can somebody please tell me when jdk9/client/jdk will be merged into >> jdk9/dev/jdk? I thought this happens regularly on a weekly base, but >> maybe that's wrong? >> >> I'm just asking because I pushed a fix which repaired the AIX build >> (8057934) to the jdk9/client/jdk ropository on September 10th but it >> hasn't been propagated to jdk9/dev/jdk until now. I there something I >> can do to speed up this process (i.e. can I manually push a change >> which already is in jdk9/client/jdk to jdk9/dev/jdk?) >> > AFAIK, changes pushed to jdk9/client are integrated into jdk9/dev every 2 > weeks. The last integration seems to have been done by Phil on September 12. > That integration was probably based on a snapshot of the outgoing changes > taken several days before that so my guess is that your change just missed > the bus. If the buses are running on time then it's likely that your change > will get to jdk9/dev later this week. > Thanks for the information. > Your mail is a reminder that we need to question again the need for > jdk9/client forest. The latency issues are a big problem, esp. when working > with project forests that pull from master. If a change that you need is > pushed to jdk9/client then it can take many weeks to get to the place where > you actually need it. The other issue is the clean-up and refactoring that > covers many areas, it becomes totally uneconomical when contributors are > forced to split the changes. > > There was a good discussion here (in Dec 2013/Jan 2014) about the > integration forests that lead to the creation of jdk9/dev and jdk9/client. > Key questions at the time were whether changes to the client libraries > needed manual testing and the reliability of the automated tests. Testing > client libraries is clearly a challenge and I think it would be good to > establish where things are currently at. More generally, we've been living > with the current arrangement for 9 months or so and it would be a good time > to assess if people think it is working well or not. > The latency is for sure a problem for down-stream consumers like us. We usually only build jd9/dev on a daily basis as we can not afford to build all the different team repositories. Another problem we have is that there's no possibility (or at least I don't know of any) to bundle related/dependent changesets. So if a do a follow-up fix F1 fro a change F and somebody will downport or integrate F into another repo, he won't see that he'll also needs to downport/integrate F1. Likewise, I as the author of F1 will not be notified of any downports/integrations of F. I'll have to keep an eye on it manually. But this is a different problem which could be solved perhaps by by introducing new 'depends on/' fields to the bug system? Regards, Volker > -Alan > > > > From srinivasan.raghavan at oracle.com Mon Sep 22 14:21:05 2014 From: srinivasan.raghavan at oracle.com (srinivasan raghavan) Date: Mon, 22 Sep 2014 19:51:05 +0530 Subject: [9-dev] Request for Approval and Review: 8058653: [TEST_BUG] Test java/awt/Graphics2D/DrawString/DrawStringCrash.java fails with OutOfMemoryError Message-ID: <54203051.20109@oracle.com> Hello , Please review a fix for the issue 8058653 [TEST_BUG] Test java/awt/Graphics2D/DrawString/DrawStringCrash.java fails with OutOfMemoryError Test bug fix https://bugs.openjdk.java.net/browse/JDK-8058653 The webrev is http://cr.openjdk.java.net/~kshefov/8058653/webrev.00/ Thanks -Srinivasan Raghavan From john.r.rose at oracle.com Mon Sep 22 18:27:50 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 22 Sep 2014 11:27:50 -0700 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: Vote: yes From neugens.limasoftware at gmail.com Mon Sep 22 19:03:23 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 22 Sep 2014 21:03:23 +0200 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: I also think that if we start using branches, it will end up being more overhead than using multiple mercurial repositories... Cheers, Mario 2014-09-22 10:38 GMT+02:00 Volker Simonis : > On Sun, Sep 21, 2014 at 4:41 PM, David Chase wrote: >> I vote yes, I have some feedback/questions on the proposal: >> >> On 2014-09-19, at 1:15 PM, Mike Duigou wrote: >>> Goals: >>> >>> - Open : Use OpenJDK public infrastructure >>> - Low-friction : Minimal start-cost and no delays >> >> I ran into one specific problem attempting to add stuff to >> jdk libraries as part of Panama, which is that the creation >> of a new module is error-prone. In my case, it is only >> error-prone, I never succeeded, I assume I missed some >> crucial step. I think we want people to be able to work in >> this style because at least one of the IDE tools (NetBeans) >> can sometimes get confused when working with a subset of the >> source files in java.base. (and even when it works, it?s another >> little speedbump on the way to configure NetBeans to work >> properly in this case) >> >> So I think we need to address this and write up a recipe, >> including the need to regenerate configure files etc before >> commit. Ideally the recipe will contain copy-and-pasteable >> commands where that is possible. >> >>> Specifics: >> >>> - Neither jcheck nor hgupdater is enabled for this forest. >> >> Do we want something like jcheck to keep the code moderately >> clean ? for example, there?s the personal ?fixit? script >> I?ve informally put up for consideration for Codetools (it?s >> not a commit hook, it merely checks a bunch of source code >> rules and gives you the the option of an automated fix). >> This is purely a matter of keeping code clean, on the off >> chance that we do include some of it in a future release. >> >>> - All development happens on branches. >> >> It would be lovely to have a short tutorial on how we do >> this written up and put in an easy-to-access place. >> Branching still makes me nervous. >> > > I'm also not familiar with branches. How do branches work in a > Mercurial forest? Is it possible to easily develop on a branch if you > need to push to different repositories within the whole sandbox forest > (i.e. hotspot and jdk). Is it somehow possible to enforce the smae > branch on all the repos in a forest? I agree that the OpenJDK project > process is much too heavyweight for many smaller project, but in the > end you always get a complete forest. I'm just curious if cross > repository changes can be easily developed with branches. > > Thanks, > Volker > >> David >> -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From mike.duigou at oracle.com Mon Sep 22 19:28:49 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 22 Sep 2014 12:28:49 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: On Sep 22 2014, at 01:38 , Volker Simonis wrote: > On Sun, Sep 21, 2014 at 4:41 PM, David Chase wrote: >> >>> - All development happens on branches. >> >> It would be lovely to have a short tutorial on how we do >> this written up and put in an easy-to-access place. >> Branching still makes me nervous. >> > > I'm also not familiar with branches. How do branches work in a > Mercurial forest? Is it possible to easily develop on a branch if you > need to push to different repositories within the whole sandbox forest > (i.e. hotspot and jdk). Is it somehow possible to enforce the smae > branch on all the repos in a forest? There is no specific support for branching across forests. This will need to be managed manually unless extensions like trees [1] can be adapted to do the necessary management across all repos. > I agree that the OpenJDK project > process is much too heavyweight for many smaller project, but in the > end you always get a complete forest. I'm just curious if cross > repository changes can be easily developed with branches. Though you do end up with a complete forest most patches/features only make changes in a single repo. For some people YMMV significantly of course. I expect that most people will only need to work with a single repo. Mike [1] http://hg.openjdk.java.net/code-tools/trees/raw-file/tip/trees.py > Thanks, > Volker > >> David >> From joe.darcy at oracle.com Mon Sep 22 20:35:26 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 22 Sep 2014 13:35:26 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <5420880E.8050009@oracle.com> I agree with Mike's assessment below: while this proposal as it stands may not directly support all desirable modes of working (branches spanning forests), it greatly simplifies many should-be-common ways of sharing and working on code. I'd like to see us quickly go forward with this proposal, gain some experience with it, and then assess what adjustments might be helpful after a few months. One reason I'd like to see the JDK organization uses branches for this project is so that branches could be included in our toolbox of features to use for multi-release work. For example, I think it could be helpful if the 9 update releases were implemented in terms of branches in a 9 update forest, as opposed to the practice today in the JDK 8 update world where for a few months each release gets its own forest that is then soon abandoned after a few weeks. This could also enable the Hg tooling to be used to answer questions like "which update releases is this fix in?" rather than relying almost exclusively on the bug database for that information. Cheers, -Joe On 9/22/2014 12:28 PM, Mike Duigou wrote: > On Sep 22 2014, at 01:38 , Volker Simonis wrote: > >> On Sun, Sep 21, 2014 at 4:41 PM, David Chase wrote: >>>> - All development happens on branches. >>> It would be lovely to have a short tutorial on how we do >>> this written up and put in an easy-to-access place. >>> Branching still makes me nervous. >>> >> I'm also not familiar with branches. How do branches work in a >> Mercurial forest? Is it possible to easily develop on a branch if you >> need to push to different repositories within the whole sandbox forest >> (i.e. hotspot and jdk). Is it somehow possible to enforce the smae >> branch on all the repos in a forest? > There is no specific support for branching across forests. This will need to be managed manually unless extensions like trees [1] can be adapted to do the necessary management across all repos. > >> I agree that the OpenJDK project >> process is much too heavyweight for many smaller project, but in the >> end you always get a complete forest. I'm just curious if cross >> repository changes can be easily developed with branches. > Though you do end up with a complete forest most patches/features only make changes in a single repo. For some people YMMV significantly of course. I expect that most people will only need to work with a single repo. > > Mike > > [1] http://hg.openjdk.java.net/code-tools/trees/raw-file/tip/trees.py > > >> Thanks, >> Volker >> >>> David >>> From mike.duigou at oracle.com Mon Sep 22 22:18:40 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 22 Sep 2014 15:18:40 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: On Sep 21 2014, at 00:30 , Ben Evans wrote: > Would this be a good place for betterrev to baseline against? > It depends. I suspect that betterrev might need the ability to generate reviews against either the jdk9/dev mainline or a single branch of this sandbox. In the later mode it would be collapsing the entire branch from where it diverges from the mainline to a single changeset suitable to integration back to jdk9/dev. Both functions would be very useful! > & +1 from someone else who doesn't get a vote > Still appreciated. :-) Mike > On 20 Sep 2014 19:16, "Martijn Verburg" wrote: > +1 (from an outsider) > > On Friday, 19 September 2014, Keith McGuigan wrote: > > > This sounds great! Thanks for doing this. > > > > On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou > > wrote: > > > > > Hello all; > > > > > > I've been instigating internal discussions with the Oracle OpenJDK > > > developers about where to do OpenJDK development work for JEP-scale > > > efforts. The scope, duration, and necessary collaboration of JEP-scale > > > efforts makes it appropriate for collaboration to be done using an open, > > > shared version control system rather than just using privately shared > > > patches. As incubation development work it is not appropriate though for > > > this work to be hosted in the jdk9/dev main-line repos. We need a public > > > place to collaborate on issues and features before they are ready for > > final > > > integration into the main-line JDK repos. > > > > > > It is possible for any OpenJDK developer to request a new OpenJDK > > project, > > > but the OpenJDK project process seems entirely too heavy-weight to have > > > full OpenJDK projects and/or forests for every issue, feature, > > exploration > > > or prototype. The problem is both the creation process overhead for new > > > projects as well as the various ongoing administration and maintenance > > > issues attendant with ongoing projects. For larger efforts it is still > > > entirely appropriate to create an OpenJDK project. An extremely rough > > guide > > > is that if the result of an effort will be a new JDK module or API > > package > > > then it is probably big enough to deserve a separate project. For > > > everything smaller, shorter or more speculative than is appropriate for a > > > project this new sandbox forest will provide a comfortable home. > > > > > > This proposal has been through a few rounds of internal review and > > > refinement and I believe is nearly ready for activation. Ideally the new > > > sandbox forest would be available for use in early October. > > > > > > Feedback and suggestions welcome. > > > > > > Cheers, > > > > > > Mike > > > > > > > > > Proposal: > > > > > > - Create a new forest in the JDK 9 project for developers to use for > > > experiments, new features, prototypes or any other non-trivial efforts. > > > > > > > > > Goals: > > > > > > - Open : Use OpenJDK public infrastructure > > > - Low-friction : Minimal start-cost and no delays > > > - Collaboration : Individual efforts can self-organize and self-regulate > > > - Approachable : Community members can easily locate, review, comment > > and > > > participate > > > - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*) > > > - Light-weight : Minimal required policy, simpler pre-push rules than > > > main-line jdk9/dev forest > > > - Visible : Links from JEP or issue page and sharable URIs to repo, > > > branches and changesets > > > > > > (*) Authors will require a Committer or Reviewer to push changesets for > > > them. > > > > > > > > > Constraints: > > > > > > - Policies are consistent with OpenJDK bylaws and JDK 9 project rule. > > > - Future OpenJDK bylaws changes may make things easier but we won't block > > > waiting for changes. > > > - Use the JDK 9 project membership and roles. > > > > > > > > > Specifics: > > > > > > - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev > > > forest. > > > - Eligible committers are JDK 9 committers as this is a forest in the JDK > > > 9 project. > > > - Each repo in the forest has a branch (possibly default) that is > > lockstep > > > updated from parent jdk9/dev repo via cron job syncing or triggered. > > > - Neither jcheck nor hgupdater is enabled for this forest. > > > - All development happens on branches. Committers can create whatever > > > branches in this forest they wish. Branch names "JEP-XXX" and > > "JDK-XXXXXXX" > > > are, by courtesy, reserved for use of the corresponding JBS issues. > > Branch > > > names prefixed with an OpenJDK username and a delimiter, by courtesy, are > > > reserved for use of that OpenJDK user. > > > - JBS allows web links to be associated with issues. This can be used to > > > identify the location of development branch for an issue. > > > - Branch owners determine the pre-commit review policy (if any) for their > > > branches. > > > - Branch owners are responsible for reparenting/rebasing their branch to > > > the provided upstream lockstep-with-dev branch however often they wish. > > > - There will be no pushes or promotions from this forest to any other > > > forest. > > > - Integration to the main-line jdk9/dev forest repos will be via the the > > > current JDK 9 changeset review and approval process. > > > - Nightlies, testing, CI, etc. are the responsibility of the individual > > > branch owners. > > > - Since the work in this forest is unreviewed, experimental, prototype or > > > exploratory there is no commitment whatsoever that anything in this > > forest > > > eventually be part of JDK 9 or any other release. > > > - The forest will be frozen at the release of JDK 9 and possibly deleted > > > sometime thereafter. Feature owners would be responsible for archiving or > > > migrating anything that they wish to retain. Notice and warning will be > > > given on jdk9-dev mailing list to which all JDK 9 project committers are > > > presumed to subscribe. > > > - Changesets pushed to the sandbox forest do not count as "significant > > > contributions" for the purposes of JDK 9 project role eligibility. > > > > > > > > > Desirable Future Changes: > > > > > > - Allow changesets to be pushed to branches in the sandbox forest by > > users > > > with Author role. This new privilege would be consistent with other > > Author > > > privileges such as uploading to cr.openjdk.java.net, editing bug > > reports, > > > and modifying the wiki. Allowing Authors to push changesets would > > require a > > > modification to the OpenJDK bylaws so we cannot currently implement this > > > policy. > > > > > > > > > Contributors (in no particular order): > > > > > > Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John > > > Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed > > > earlier drafts of this proposal and provided insight and encouragement. > > > > > > > > > > > -- > > > > [image: twitter-icon-large.png] > > > > Keith McGuigan > > > > @kamggg > > > > kmcguigan at twitter.com > > > > > -- > Cheers, > Martijn From mike.duigou at oracle.com Mon Sep 22 22:25:10 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 22 Sep 2014 15:25:10 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <989E394B-B90C-4F23-9556-AB08A5CB56F1@oracle.com> On Sep 21 2014, at 07:41 , David Chase wrote: > I vote yes, I have some feedback/questions on the proposal: > > On 2014-09-19, at 1:15 PM, Mike Duigou wrote: >> Goals: >> >> - Open : Use OpenJDK public infrastructure >> - Low-friction : Minimal start-cost and no delays > > I ran into one specific problem attempting to add stuff to > jdk libraries as part of Panama, which is that the creation > of a new module is error-prone. In my case, it is only > error-prone, I never succeeded, I assume I missed some > crucial step. I think we want people to be able to work in > this style because at least one of the IDE tools (NetBeans) > can sometimes get confused when working with a subset of the > source files in java.base. (and even when it works, it?s another > little speedbump on the way to configure NetBeans to work > properly in this case) > > So I think we need to address this and write up a recipe, > including the need to regenerate configure files etc before > commit. Ideally the recipe will contain copy-and-pasteable > commands where that is possible. Indeed. I think Alan is covering this and it is more a general issue with repo/build configuration than specifically with this new sandbox forest. >> Specifics: > >> - Neither jcheck nor hgupdater is enabled for this forest. > > Do we want something like jcheck to keep the code moderately > clean ? for example, there?s the personal ?fixit? script > I?ve informally put up for consideration for Codetools (it?s > not a commit hook, it merely checks a bunch of source code > rules and gives you the the option of an automated fix). > This is purely a matter of keeping code clean, on the off > chance that we do include some of it in a future release. Some people have explicitly requested that this not be provided. They want no impediments at all. it would be nice to be able to accommodate different practices for different branches but we haven't figured out how to do that yet. It is possible for individuals to add the hooks to the hgrc files in their personal copies of the repos but we don't currently have any tools for this (defpath extension is fairly close). > >> - All development happens on branches. > > It would be lovely to have a short tutorial on how we do > this written up and put in an easy-to-access place. > Branching still makes me nervous. Working on this task this week. I hope to have suggested workflow and tutorial docs in the wiki soon. Cheers! Mike From mike.duigou at oracle.com Mon Sep 22 22:29:27 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 22 Sep 2014 15:29:27 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: <94E9BFE5-A9CE-4172-8B16-FA46DE551D5B@oracle.com> References: <94E9BFE5-A9CE-4172-8B16-FA46DE551D5B@oracle.com> Message-ID: <6E16C5E4-622A-447B-A1CE-2085E9A1F41F@oracle.com> There has been ongoing work to provide a public review facility for OpenJDK. Joe Darcy or Brian Beck may be able to comment on the status/progress. It would certainly be desirable to use the sandbox forest for post-commit reviews of changesets to be integrated into the mainline repos but we intentional didn't want to make this proposal contingent on any other new initiatives or requirements. Cheers, Mike On Sep 21 2014, at 12:19 , Doug Simon wrote: >> Goals: >> >> - Open : Use OpenJDK public infrastructure >> - Low-friction : Minimal start-cost and no delays >> - Collaboration : Individual efforts can self-organize and self-regulate >> - Approachable : Community members can easily locate, review, comment and participate > > Towards the goal of easier reviewing, are there any plans for adopting a code review tool (such as Crucible) as part of this proposal? > > -Doug From mike.duigou at oracle.com Mon Sep 22 22:31:05 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 22 Sep 2014 15:31:05 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: References: Message-ID: <8C682EC2-1C5B-49A1-BF21-E2D37431EF3A@oracle.com> On Sep 22 2014, at 12:03 , Mario Torre wrote: > I also think that if we start using branches, it will end up being > more overhead than using multiple mercurial repositories... Yes, it's possible this will be the case for some users. If you don't need collaboration with other users for specific projects or bugs then it might be best to continue to MQ or patches upon the mainline repos. Cheers, Mike > > Cheers, > Mario > > 2014-09-22 10:38 GMT+02:00 Volker Simonis : >> On Sun, Sep 21, 2014 at 4:41 PM, David Chase wrote: >>> I vote yes, I have some feedback/questions on the proposal: >>> >>> On 2014-09-19, at 1:15 PM, Mike Duigou wrote: >>>> Goals: >>>> >>>> - Open : Use OpenJDK public infrastructure >>>> - Low-friction : Minimal start-cost and no delays >>> >>> I ran into one specific problem attempting to add stuff to >>> jdk libraries as part of Panama, which is that the creation >>> of a new module is error-prone. In my case, it is only >>> error-prone, I never succeeded, I assume I missed some >>> crucial step. I think we want people to be able to work in >>> this style because at least one of the IDE tools (NetBeans) >>> can sometimes get confused when working with a subset of the >>> source files in java.base. (and even when it works, it?s another >>> little speedbump on the way to configure NetBeans to work >>> properly in this case) >>> >>> So I think we need to address this and write up a recipe, >>> including the need to regenerate configure files etc before >>> commit. Ideally the recipe will contain copy-and-pasteable >>> commands where that is possible. >>> >>>> Specifics: >>> >>>> - Neither jcheck nor hgupdater is enabled for this forest. >>> >>> Do we want something like jcheck to keep the code moderately >>> clean ? for example, there?s the personal ?fixit? script >>> I?ve informally put up for consideration for Codetools (it?s >>> not a commit hook, it merely checks a bunch of source code >>> rules and gives you the the option of an automated fix). >>> This is purely a matter of keeping code clean, on the off >>> chance that we do include some of it in a future release. >>> >>>> - All development happens on branches. >>> >>> It would be lovely to have a short tutorial on how we do >>> this written up and put in an easy-to-access place. >>> Branching still makes me nervous. >>> >> >> I'm also not familiar with branches. How do branches work in a >> Mercurial forest? Is it possible to easily develop on a branch if you >> need to push to different repositories within the whole sandbox forest >> (i.e. hotspot and jdk). Is it somehow possible to enforce the smae >> branch on all the repos in a forest? I agree that the OpenJDK project >> process is much too heavyweight for many smaller project, but in the >> end you always get a complete forest. I'm just curious if cross >> repository changes can be easily developed with branches. >> >> Thanks, >> Volker >> >>> David >>> > > > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From joe.darcy at oracle.com Tue Sep 23 02:14:30 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 22 Sep 2014 19:14:30 -0700 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: <6E16C5E4-622A-447B-A1CE-2085E9A1F41F@oracle.com> References: <94E9BFE5-A9CE-4172-8B16-FA46DE551D5B@oracle.com> <6E16C5E4-622A-447B-A1CE-2085E9A1F41F@oracle.com> Message-ID: <5420D786.3090205@oracle.com> On 09/22/2014 03:29 PM, Mike Duigou wrote: > There has been ongoing work to provide a public review facility for OpenJDK. Joe Darcy or Brian Beck may be able to comment on the status/progress. Unfortunately, there are no plans I can share at the moment; however, I will say we are keenly aware of the desirability of having a publicly usable code review system, like Crucible, to aid in JDK code reviews. -Joe From volker.simonis at gmail.com Tue Sep 23 08:14:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Sep 2014 10:14:22 +0200 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: <5420880E.8050009@oracle.com> References: <5420880E.8050009@oracle.com> Message-ID: On Mon, Sep 22, 2014 at 10:35 PM, Joe Darcy wrote: > I agree with Mike's assessment below: while this proposal as it stands may > not directly support all desirable modes of working (branches spanning > forests), it greatly simplifies many should-be-common ways of sharing and > working on code. > > I'd like to see us quickly go forward with this proposal, gain some > experience with it, and then assess what adjustments might be helpful after > a few months. Agree. > > One reason I'd like to see the JDK organization uses branches for this > project is so that branches could be included in our toolbox of features to > use for multi-release work. > > For example, I think it could be helpful if the 9 update releases were > implemented in terms of branches in a 9 update forest, as opposed to the > practice today in the JDK 8 update world where for a few months each release > gets its own forest that is then soon abandoned after a few weeks. This > could also enable the Hg tooling to be used to answer questions like "which > update releases is this fix in?" rather than relying almost exclusively on > the bug database for that information. I fully agree that using new new forest for each update release isn't that nice. But in some sense it's quite safe. I'm not sure if it's possible to "close" a certain branch to prevent people from pushing there unintentionally if we would use branches for each update release. And we need some easy way to bring all repos in the forest to the same branch so people don't accidentally build OpenJDK from different branches. So let's start testing branches on the sandbox repo to gain some experience:) > > Cheers, > > -Joe > > > On 9/22/2014 12:28 PM, Mike Duigou wrote: >> >> On Sep 22 2014, at 01:38 , Volker Simonis >> wrote: >> >>> On Sun, Sep 21, 2014 at 4:41 PM, David Chase >>> wrote: >>>>> >>>>> - All development happens on branches. >>>> >>>> It would be lovely to have a short tutorial on how we do >>>> this written up and put in an easy-to-access place. >>>> Branching still makes me nervous. >>>> >>> I'm also not familiar with branches. How do branches work in a >>> Mercurial forest? Is it possible to easily develop on a branch if you >>> need to push to different repositories within the whole sandbox forest >>> (i.e. hotspot and jdk). Is it somehow possible to enforce the smae >>> branch on all the repos in a forest? >> >> There is no specific support for branching across forests. This will need >> to be managed manually unless extensions like trees [1] can be adapted to do >> the necessary management across all repos. >> >>> I agree that the OpenJDK project >>> process is much too heavyweight for many smaller project, but in the >>> end you always get a complete forest. I'm just curious if cross >>> repository changes can be easily developed with branches. >> >> Though you do end up with a complete forest most patches/features only >> make changes in a single repo. For some people YMMV significantly of course. >> I expect that most people will only need to work with a single repo. >> >> Mike >> >> [1] http://hg.openjdk.java.net/code-tools/trees/raw-file/tip/trees.py >> >> >>> Thanks, >>> Volker >>> >>>> David >>>> > From martijnverburg at gmail.com Tue Sep 23 14:02:42 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 23 Sep 2014 15:02:42 +0100 Subject: Swing generification changes in JDK 9 b24 -- swing generification refinements in JDK 9 b30 In-Reply-To: <541909F3.50605@oracle.com> References: <53D4152E.20001@oracle.com> <53D9073A.90108@oracle.com> <53E10590.2010801@oracle.com> <541909F3.50605@oracle.com> Message-ID: My two projects are now fine - thanks for the fixes! Cheers, Martijn On 17 September 2014 05:11, Joe Darcy wrote: > Hello swing developers, > > In response to the earlier call for feedback on the initial swing > generification changes, several bugs were filed and fixed: > > JDK-8054360: Refine generification of javax.swing > https://bugs.openjdk.java.net/browse/JDK-8054360 > > JDK-8055254: Address source incompatability of JSlider generification > https://bugs.openjdk.java.net/browse/JDK-8055254 > > These fixes are now present in JDK 9 b30: > > https://jdk9.java.net/download/ > > Please give b30 a try when recompiling your favorite swing code base and > report on how the refined generification works. > > Thanks, > > -Joe > > On 8/5/2014 9:25 AM, Joe Darcy wrote: > >> Hello, >> >> A quick follow-up, I've filed >> >> JDK-8054360: Refine generification of javax.swing >> https://bugs.openjdk.java.net/browse/JDK-8054360#comment-13532821 >> >> to tweak the generification of TreeNode and possibly a few other types. >> >> Thanks for the feedback, >> >> -Joe >> >> On 7/30/2014 7:54 AM, Joe Darcy wrote: >> >>> Hi Andrej and Martijn, >>> >>> Thanks for responding. >>> >>> On 7/28/2014 5:04 AM, Andrej Golovnin wrote: >>> >>>> Hi Joe, >>>> >>>> I'm not sure if it is what you are looking for. >>>> >>> >>> For context, the general evolution policy of the JDK: >>> >>> http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/ >>> OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy >>> >>> includes "avoid introducing source incompatibilities." As this is a >>> large generification change to swing, some level of source incompatibility >>> may be acceptable in a platform release like JDK 9, but if there are very >>> widespread issues, some of the changes may be reconsidered. >>> >>> The request to try out the changes was to get enough information to see >>> if any (partial) reconsideration was warranted. >>> >>> >>> But I tried to compile my project with the new build. And I got a >>>> compile error in one of my classes. I have a class which implements the >>>> TreeNode interface and looks like this: >>>> >>>> class MyTreeNode implements TreeNode { >>>> .... >>>> @Override >>>> public Enumeration children() { >>>> return ....; >>>> } >>>> ... >>>> } >>>> >>>> The error message is: "return type Enumeration is not >>>> compatible with Enumeration". >>>> >>>> If I change (see attached patch) the definition of the >>>> children()-method in the TreeNode-interface to: >>>> >>>> public interface TreeNode { >>>> ... >>>> Enumeration children(); >>>> ... >>>> } >>>> >>>> then my code compiles. >>>> >>> >>> That design issue was raised during code review: >>> >>> http://mail.openjdk.java.net/pipermail/swing-dev/2014-June/003643.html >>> >>> "It was not immediately clear how javax.swing.tree.TreeNode.children(), >>> which returns a raw Enumeration, should be generified. I changed it to >>> >>> Enumeration children(); >>> >>> and that seems to work fine. Something like >>> >>> Enumeration >>> >>> with a covariant override would save a few casts in a private >>> implementation, but generally doesn't seem to be a good trade-off since >>> many normal clients could be inconvenienced dealing with the wildcard." >>> >>> If generified subclasses of TreeNode are common, the generification of >>> children may need reconsideration. >>> >>> >>>> BTW, a good test for your changes would be to try to compile NetBeans >>>> and/or IntelliJ IDEA using the new JDK 9 build. They both are really big >>>> Swing applications which make use maybe of all Swing APIs. >>>> >>>> >>>> >>> My preference would be for the NetBeans and IntelliJ teams to do that >>> task :-) >>> >>> Thanks, >>> >>> -Joe >>> >> >> > From alejandro.murillo at oracle.com Tue Sep 23 17:02:49 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 23 Sep 2014 11:02:49 -0600 Subject: jdk9-dev: HotSpot Message-ID: <5421A7B9.7090608@oracle.com> jdk9-hs-2014-09-19 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/7feeff170f81 http://hg.openjdk.java.net/jdk9/dev/corba/rev/b5b139354630 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4ac471db103d http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/b940ca3d2c7e http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/838a2f693e51 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/47558493c9c0 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ff1998c1ecab http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/76f31d739efb Component : VM Status : Go for integration Date : 09/23/2014 at 21:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-09-19-090401.amurillo.jdk9-hs-2014-09-19-jdk9-dev-control Testing: 194 new failures, 3075 known failures, 372995 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8025564: gc/memory/UniThread/Linear1 times out during heap verification 8035419: warning from b09 for hotspot.agent.src.os.win32.windbg.sawindbg.cpp: 'JNI exception pending' 8046210: Missing memory barrier when reading init_lock 8050147: StoreLoad barrier interferes with stack usages 8053886: assert(false) failed: Should not allocate with exception pending 8054836: [TESTBUG] Test is needed to verify correctness of malloc tracking 8054889: Compiler team's implementation task 8054957: Enable AppCDS JTREG tests after AppCDS feature is integrated into promoted JDK build 8055008: Clean up code that saves the previous versions of redefined classes 8055009: JVM fails with undefined symbol: _ZN12RegisterImpl8as_VMRegEv 8055083: [TESTBUG] AppCDS build0.sh uses shell constructs that are not always available 8055289: Internal Error: mallocTracker.cpp:146 fatal error: Should not use malloc for big memory block, use virtual memory instead 8056053: Disable HOTSPOT_BUILD_JOBS when building with configure 8056124: Hotspot should use PICL interface to get cacheline size on SPARC 8056154: JVM crash with EXCEPTION_ACCESS_VIOLATION when there are many threads running 8056242: Add function to return structured information about loaded libraries. 8056930: Output host info under some condition for core dump 8056968: jdk9-dev: launching java hangs on all arm platforms (armvfp,armhf,jdk on arm) 8057570: RedefineClasses() tests fail assert(((Metadata*)obj)->is_valid()) failed: obj is valid 8057643: Unable to build --with-debug-level=optimized on OSX 8057696: java -version triggers assertion for slowdebug zero builds 8057722: G1: Code root hashtable updated incorrectly when evacuation failed 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build 8057750: CTW should not make MH intrinsics not entrant 8057758: Tests run TypeProfileLevel=222 crash with guarantee(0) failed: must find derived/base pair 8057780: Fix ppc build after "8050147: StoreLoad barrier interferes with stack usages 8057910: G1: BOT verification should not pass top 8057918: Update out-dated ignore tags in GC jtreg tests 8058092: Test vm/mlvm/meth/stress/compiler/deoptimize. Assert in src/share/vm/classfile/systemDictionary.cpp: MH intrinsic invariant 8058184: Move _highest_comp_level and _highest_osr_comp_level from MethodData to MethodCounters -- Alejandro From serguei.spitsyn at oracle.com Wed Sep 24 06:22:11 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Sep 2014 23:22:11 -0700 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <54226313.4060607@oracle.com> Vote: yes On 9/17/14 6:50 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier (goetz) to jdk9 Reviewer. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other part of the HotSpot including memory ordering changes, code > cleanups and simplifications and bug fixes. He's been a hsx, jdk8u and > jdk9 committer for the last two years and authored about 80 changes > during this time: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=100 > > Votes are due by 4:00 PM GMT, Wednesday, October 1, 2014 > > Only current jdk9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From jaroslav.bachorik at oracle.com Wed Sep 24 08:22:42 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 24 Sep 2014 10:22:42 +0200 Subject: Result: New jdk9 Committer: Yekaterina Kantserova Message-ID: <54227F52.3080304@oracle.com> Voting for Yekaterina Kantserova [1] is now closed. Yes: 24 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, -JB- [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-September/001267.html From John.Coomes at oracle.com Wed Sep 24 19:47:30 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 24 Sep 2014 12:47:30 -0700 Subject: CFV: New jdk9 Reviewer: Goetz Lindenmaier In-Reply-To: References: Message-ID: <21539.8146.231133.242427@mykonos.us.oracle.com> Vote: yes -John From mparchet at sunrise.ch Wed Sep 24 21:12:58 2014 From: mparchet at sunrise.ch (=?utf-8?Q?Parchet_Micha=C3=ABl?=) Date: Wed, 24 Sep 2014 23:12:58 +0200 Subject: Fwd: CFV: New Project Kulla References: <540DFBF3.1050405@sunrise.ch> Message-ID: <5BFCB2BC-F726-4BE1-B18D-93B1C4CC1D34@sunrise.ch> D?but du message transf?r? : > Exp?diteur: Micha?l Parchet > Date: 8 septembre 2014 20:56:51 UTC+2 > Destinataire: discuss at openjdk.java.net > Objet: R?p : CFV: New Project Kulla > > Hello, > > I would like use this function to debug my paroject. invoke only one method. > Open only a JFrame to test it etc,, > > This function could implements like this. > > Begin. > Ask : "whould you like to save your next commands in a source java file ? y/n" > > if answer == y > > show the stop button > When the user type enter. > If this command is valid > Write it in the file > > > When the user click stop. > > if the file hase been saved ? > show message : "your file has been saved to" + absolutefilepath. > > If answer == n > > Enter in the normal interactive mode whithout savig commands > > Please send me news about my idee. > > I Vote yes at 100% > > Best regards > > Micha?l Parchet From robert.field at oracle.com Wed Sep 24 22:33:44 2014 From: robert.field at oracle.com (Robert Field) Date: Wed, 24 Sep 2014 15:33:44 -0700 Subject: Fwd: CFV: New Project Kulla In-Reply-To: <5BFCB2BC-F726-4BE1-B18D-93B1C4CC1D34@sunrise.ch> References: <540DFBF3.1050405@sunrise.ch> <5BFCB2BC-F726-4BE1-B18D-93B1C4CC1D34@sunrise.ch> Message-ID: <148a9cc7188.27a6.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Hi, The Kulla project has been created. Please use the kulla-dev at openjdk.java.net alias for communication with the team. Thanks, Robert On September 24, 2014 2:13:26 PM Parchet Micha?l wrote: > > > > > D?but du message transf?r? : > > > Exp?diteur: Micha?l Parchet > > Date: 8 septembre 2014 20:56:51 UTC+2 > > Destinataire: discuss at openjdk.java.net > > Objet: R?p : CFV: New Project Kulla > > > > Hello, > > > > I would like use this function to debug my paroject. invoke only one method. > > Open only a JFrame to test it etc,, > > > > This function could implements like this. > > > > Begin. > > Ask : "whould you like to save your next commands in a source java file ? > y/n" > > > > if answer == y > > > > show the stop button > > When the user type enter. > > If this command is valid > > Write it in the file > > > > > > When the user click stop. > > > > if the file hase been saved ? > > show message : "your file has been saved to" + absolutefilepath. > > > > If answer == n > > > > Enter in the normal interactive mode whithout savig commands > > > > Please send me news about my idee. > > > > I Vote yes at 100% > > > > Best regards > > > > Micha?l Parchet From lana.steuck at oracle.com Wed Sep 24 23:44:21 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 24 Sep 2014 16:44:21 -0700 (PDT) Subject: jdk9-b32: dev Message-ID: <201409242344.s8ONiLYq022989@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/7e3512dae8e0 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/62ba20541b94 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/ad99965443d1 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8bdf7083b5bd http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/838a2f693e51 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/b940ca3d2c7e http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af46576a8d7c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/b5b139354630 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6624085 client-libs Fourth mouse button (wheel) is treated like second button - isPopupTrigger returns true JDK-8057184 client-libs JCK8's api/javax_swing/JDesktopPane/descriptions.html#getset failed with GTKLookAndFeel on Linux and Solaris run v.s. JDK8+ JDK-8055360 client-libs Move the rest part of AWT ShapedAndTranslucent tests to OpenJDK JDK-8056209 client-libs Remove unused files for libawt JDK-8056122 client-libs Upgrade JDK to use LittleCMS 2.6 JDK-8040617 client-libs [macosx] Large JTable cell results in a OutOfMemoryException JDK-8056211 client-libs api/java_awt/Event/InputMethodEvent/serial/index.html#Input[serial2002] failure JDK-6966205 client-libs closed/sun/awt/font/DeriveFont.java failed with compilation error JDK-8057986 client-libs freetype code to get glyph outline does not handle initial control point properly JDK-8055664 client-libs move 14 tests about setLocationRelativeTo to jdk JDK-8055746 client-libs plenty of clipboard/dnd tests fail and break X11 JDK-8054638 client-libs xrender: text drawn after setColor(Color.white) is actually black JDK-8054029 core-libs (fc) FileChannel.size() returns 0 for block devices on Linux JDK-8058664 core-libs Bad fonts in BigIntegerTest JDK-8057793 core-libs BigDecimal is no longer effectively immutable JDK-8058505 core-libs BigIntegerTest does not exercise Burnikel-Ziegler division JDK-8058293 core-libs Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is broken JDK-8058509 core-libs CLDRLocaleDataMetaInfo should be in jdk.localedata JDK-8056978 core-libs ClassCastException: cannot cast jdk.nashorn.internal.scripts.JO* JDK-8058661 core-libs Compiled LambdaForms should inherit from Object to improve class loading performance JDK-8058394 core-libs Doclint issue for java vs javadoc comment in Date.sql JDK-8058584 core-libs Ignore java/lang/invoke/LFCaching/LFGarbageCollectedTest until 8057020 is fixed JDK-8058230 core-libs Improve java.sql toString formatting JDK-8055055 core-libs Improve numeric parsing in java.sql JDK-8058429 core-libs JCK test api/java_sql/Timestamp/descriptions.html start failing after 8058230 JDK-8058291 core-libs Missing some checks during parameter validation JDK-8058679 core-libs More bad characters in BigIntegerTest JDK-8057035 core-libs Nashorn: Some tests failed using java.awt.Color on Solaris without X11 libraries JDK-8058216 core-libs NetworkInterface.getHardwareAddress can return zero length byte array when run with preferIPv4Stack JDK-8057719 core-libs New tests for LambdaForm Reduction and Caching feature JDK-8058304 core-libs Non-serializable fields in serializable classes JDK-8058615 core-libs Overload resolution ambiguity involving ConsString JDK-8057743 core-libs Single quotes must be escaped in message resource file JDK-8057707 core-libs TEST library enhancement in lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java JDK-8058514 core-libs TEST_BUG: New tests introduced in 8058429 are TimeZone dependent JDK-8058551 core-libs Top level README accidentally modified with changeset 1025:3936203c7dc8 JDK-8058569 core-libs Update java/lang/invoke/lambda tests to eliminate dependency on sun.tools.jar.Main JDK-8058422 core-libs Users should be able to overwrite "context" and "engine" variables JDK-8058545 core-libs With strict mode, bean property assignment of a non-existent property should result in TypeError JDK-8056934 core-libs ZipInputStream does not correctly handle local header data descriptors with the optional signature missing JDK-8058413 core-libs change formatDecimalInt so it is package private JDK-8058366 core-libs export sun.misc to java.sql JDK-8058204 core-libs stream tests timeout, intermittently but more likely to happen after JDK-8056248 JDK-8058480 core-libs test/closed/com/sun/rowset/internal/xmlreadercontenthandler/InvalidTypeTest.java should not write to testbase JDK-8049303 core-svc Transient network problems cause JMX thread to fail silenty JDK-8042205 core-svc javax/management/monitor/*: some tests didn't get all the notifications JDK-8057951 core-svc javax/management/monitor/... should be quarantined JDK-8050115 core-svc javax/management/monitor/GaugeMonitorDeadlockTest.java fails intermittently JDK-8054971 deploy Applet is blocked when requesting sandbox permission and loading loose resource JDK-8056142 deploy Exception Site List dialog is too wide JDK-8055264 deploy Java Web Start rejects name attr of applet-desc tag containing JDK-8055866 deploy Mixed code dialog won't show on jre9 JDK-8041926 deploy SSV dialog doesn't look like design prototype JDK-8032835 deploy Security Dialogs should display OU/O field for Publisher if CN field is empty JDK-8054455 deploy javaws fails to get proxy from browser settings if browser is set to use system proxy ( linux ) JDK-8055009 embedded JVM fails with undefined symbol: _ZN12RegisterImpl8as_VMRegEv JDK-8046210 embedded Missing memory barrier when reading init_lock JDK-8056968 embedded jdk9-dev: launching java hangs on all arm platforms (armvfp,armhf,jdk on arm) JDK-8053886 hotspot assert(false) failed: Should not allocate with exception pending JDK-8056242 hotspot Add function to return structured information about loaded libraries. JDK-8057750 hotspot CTW should not make MH intrinsics not entrant JDK-8055008 hotspot Clean up code that saves the previous versions of redefined classes JDK-8054889 hotspot Compiler team's implementation task JDK-8056053 hotspot Disable HOTSPOT_BUILD_JOBS when building with configure JDK-8054957 hotspot Enable AppCDS JTREG tests after AppCDS feature is integrated into promoted JDK build JDK-8057780 hotspot Fix ppc build after "8050147: StoreLoad barrier interferes with stack usages" JDK-8057910 hotspot G1: BOT verification should not pass top JDK-8057722 hotspot G1: Code root hashtable updated incorrectly when evacuation failed JDK-8056124 hotspot Hotspot should use PICL interface to get cacheline size on SPARC JDK-8055289 hotspot Internal Error: mallocTracker.cpp:146 fatal error: Should not use malloc for big memory block, use virtual memory instead JDK-8056154 hotspot JVM crash with EXCEPTION_ACCESS_VIOLATION when there are many threads running JDK-8058184 hotspot Move _highest_comp_level and _highest_osr_comp_level from MethodData to MethodCounters JDK-8056930 hotspot Output host info under some condition for core dump JDK-8057570 hotspot RedefineClasses() tests fail assert(((Metadata*)obj)->is_valid()) failed: obj is valid JDK-8050147 hotspot StoreLoad barrier interferes with stack usages JDK-8057745 hotspot TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build JDK-8058092 hotspot Test vm/mlvm/meth/stress/compiler/deoptimize. Assert in src/share/vm/classfile/systemDictionary.cpp: MH intrinsic invariant JDK-8057758 hotspot Tests run TypeProfileLevel=222 crash with guarantee(0) failed: must find derived/base pair JDK-8057643 hotspot Unable to build --with-debug-level=optimized on OSX JDK-8057918 hotspot Update out-dated ignore tags in GC jtreg tests JDK-8058605 hotspot [TESTBUG] Add closed/com/oracle/jfr/gc/ConfigurationEventTest/TestGCHeapConfigurationEvent* to ProblemList.txt JDK-8055083 hotspot [TESTBUG] AppCDS build0.sh uses shell constructs that are not always available JDK-8022865 hotspot [TESTBUG] Compressed Oops testing needs to be revised JDK-8054836 hotspot [TESTBUG] Test is needed to verify correctness of malloc tracking JDK-8025564 hotspot gc/memory/UniThread/Linear1 times out during heap verification JDK-8057696 hotspot java -version triggers assertion for slowdebug zero builds JDK-8035419 hotspot warning from b09 for hotspot.agent.src.os.win32.windbg.sawindbg.cpp: 'JNI exception pending' JDK-8058367 infrastructure Add verify-modules target to the default and images target JDK-8058118 infrastructure Generate modules.list during the build JDK-8058317 infrastructure Top-level Makefiles uses deprecated target jvmg in HotSpot Makefiles JDK-8044833 install 8ux- JP jre installation dialog - logo cut off from the image JDK-8055902 install Change applet name in JNLP file JDK-8055663 install Localize changes in 8049709 and 8053909 JDK-8055135 install Typo in Russian JUT translation (confirm dialog) JDK-8016515 install [en] duplicate mnemonic key in jdk 8 installer JDK-8042900 security-libs Allow com.sun.security.jgss to be in different module than org.ietf.jgss JDK-8056141 security-libs Move com.sun.security.jgss into a new module JDK-8050281 security-libs New permission tests for JEP 140 JDK-8043698 tools tag not getting generated in package-summary pages for un-named packages JDK-8055080 tools Group 9d: golden files for tests in tools/javac dir JDK-8055963 tools Inference failure with nested invocation JDK-8047745 tools Javadoc should include encoding information in generated html files JDK-8054548 xml JAX-WS tools need to updated to work with modular image From ivan.gerasimov at oracle.com Thu Sep 25 07:42:16 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 25 Sep 2014 11:42:16 +0400 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout Message-ID: <5423C758.3060904@oracle.com> Hello! This is a proposal to enhance the unshuffle_patch.sh script so that it will be able to read from stdin and write to stdout. This would let us use the script in a pipe chain. For example, the following line could be used to apply a patch directly from a remote repository: wget -q -O - http://path.to.the.raw.patch | bash ~/jdk9/common/bin/unshuffle_patch.sh jdk - - | hg patch - --no-commit (Note, that it would only work, if the repository provides the patches in the git format, which is not currently the case with hg.openjdk.java.net.) Would you please help review/approve this enhancement? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059101 WEBREV: http://cr.openjdk.java.net/~igerasim/8059101/0/webrev/ Sincerely yours, Ivan From daniel.fuchs at oracle.com Thu Sep 25 09:49:41 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 25 Sep 2014 11:49:41 +0200 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <5423C758.3060904@oracle.com> References: <5423C758.3060904@oracle.com> Message-ID: <5423E535.90908@oracle.com> Hi Ivan, When setting output & input, I wonder if it would be simpler to use an 'if else if' construct in order to avoid the '-a' in the 'if' that follows. something like this (pseudo code) might be easier to read: if "x$output" is "x-" then substitute - with /dev/stdout else if $output file exists complain endif Also the script uses echo to print warnings & error. It should probably be changed to print those on stderr ( >&2 ) so that they don't mix with the patch when the output is '-'. Similarly - I feel that either verbose should redirect to stderr, or the script should complain and exit if output is '-' and verbose is on. best regards, -- daniel On 25/09/14 09:42, Ivan Gerasimov wrote: > Hello! > > This is a proposal to enhance the unshuffle_patch.sh script so that it > will be able to read from stdin and write to stdout. > This would let us use the script in a pipe chain. > > For example, the following line could be used to apply a patch directly > from a remote repository: > wget -q -O - http://path.to.the.raw.patch | bash > ~/jdk9/common/bin/unshuffle_patch.sh jdk - - | hg patch - --no-commit > > (Note, that it would only work, if the repository provides the patches > in the git format, which is not currently the case with > hg.openjdk.java.net.) > > Would you please help review/approve this enhancement? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059101 > WEBREV: http://cr.openjdk.java.net/~igerasim/8059101/0/webrev/ > > Sincerely yours, > Ivan > From jaroslav.bachorik at oracle.com Thu Sep 25 09:54:22 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 25 Sep 2014 11:54:22 +0200 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes Message-ID: <5423E64E.6060004@oracle.com> Please, review the following change to the JDK test library class Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 Currently, the ProcessTools.startProcess() might leave a dangling process behind when a timeout or interrupt happens. The solution is to try and forcibly terminate the forked process when this happens. Thanks, -JB- From ivan.gerasimov at oracle.com Thu Sep 25 10:12:43 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 25 Sep 2014 14:12:43 +0400 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <5423E535.90908@oracle.com> References: <5423C758.3060904@oracle.com> <5423E535.90908@oracle.com> Message-ID: <5423EA9B.7010400@oracle.com> Thank you Daniel for the comments! On 25.09.2014 13:49, Daniel Fuchs wrote: > Hi Ivan, > > When setting output & input, I wonder if it would be simpler > to use an 'if else if' construct in order to avoid the '-a' > in the 'if' that follows. > We would still need that -a in if, as the user could pass /dev/stdin and /dev/stdout as the arguments to the script. Dashes are meant to be the shortcut for these long names, but we should allow the long names to be passed too. > something like this (pseudo code) might be easier to read: > > if "x$output" is "x-" then > substitute - with /dev/stdout > else if $output file exists > complain > endif > > Also the script uses echo to print warnings & error. > It should probably be changed to print those on stderr ( >&2 ) > so that they don't mix with the patch when the output is '-'. > Agreed! Redirected all the error messages to stderr. > Similarly - I feel that either verbose should redirect to > stderr, or the script should complain and exit if output > is '-' and verbose is on. > Done. Please see the updated webrev: http://cr.openjdk.java.net/~igerasim/8059101/1/webrev/ Sincerely yours, Ivan From staffan.larsen at oracle.com Thu Sep 25 10:13:17 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 25 Sep 2014 12:13:17 +0200 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes In-Reply-To: <5423E64E.6060004@oracle.com> References: <5423E64E.6060004@oracle.com> Message-ID: <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> I wonder if the p.waitFor() is needed? What if the process launching expired with a timeout and now we are still waiting for the process to end - wouldn?t that kind of defeat the timeout? In any case, the destroyForcibly() should end the process whether we wait for it or not. /Staffan On 25 sep 2014, at 11:54, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: > Please, review the following change to the JDK test library class > > Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 > Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 > > Currently, the ProcessTools.startProcess() might leave a dangling process behind when a timeout or interrupt happens. The solution is to try and forcibly terminate the forked process when this happens. > > Thanks, > > -JB- From daniel.fuchs at oracle.com Thu Sep 25 10:18:13 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 25 Sep 2014 12:18:13 +0200 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <5423EA9B.7010400@oracle.com> References: <5423C758.3060904@oracle.com> <5423E535.90908@oracle.com> <5423EA9B.7010400@oracle.com> Message-ID: <5423EBE5.6020901@oracle.com> Hi Ivan, Should 'usage' also be redirected? best regards, -- daniel On 25/09/14 12:12, Ivan Gerasimov wrote: > Thank you Daniel for the comments! > > On 25.09.2014 13:49, Daniel Fuchs wrote: >> Hi Ivan, >> >> When setting output & input, I wonder if it would be simpler >> to use an 'if else if' construct in order to avoid the '-a' >> in the 'if' that follows. >> > We would still need that -a in if, as the user could pass /dev/stdin and > /dev/stdout as the arguments to the script. > Dashes are meant to be the shortcut for these long names, but we should > allow the long names to be passed too. > >> something like this (pseudo code) might be easier to read: >> >> if "x$output" is "x-" then >> substitute - with /dev/stdout >> else if $output file exists >> complain >> endif >> >> Also the script uses echo to print warnings & error. >> It should probably be changed to print those on stderr ( >&2 ) >> so that they don't mix with the patch when the output is '-'. >> > Agreed! > Redirected all the error messages to stderr. > >> Similarly - I feel that either verbose should redirect to >> stderr, or the script should complain and exit if output >> is '-' and verbose is on. >> > Done. > > Please see the updated webrev: > http://cr.openjdk.java.net/~igerasim/8059101/1/webrev/ > > Sincerely yours, > Ivan > From jaroslav.bachorik at oracle.com Thu Sep 25 10:24:06 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 25 Sep 2014 12:24:06 +0200 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes In-Reply-To: <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> References: <5423E64E.6060004@oracle.com> <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> Message-ID: <5423ED46.8040407@oracle.com> On 09/25/2014 12:13 PM, Staffan Larsen wrote: > I wonder if the p.waitFor() is needed? What if the process launching expired with a timeout and now we are still waiting for the process to end - wouldn?t that kind of defeat the timeout? In any case, the destroyForcibly() should end the process whether we wait for it or not. It would be wonderful but the javadoc states that the result of destroyForcibly() call depends on the implementation and may actually not force close the process and one should use waitFor() to make sure that the process has in fact died. I wonder whether JTReg kills the process tree on timeout - in case it does using waitFor() would guarantee that there would be no zombies left. Without using waitFor() and semantics of destroyForcibly() there might be situations when non-functional stuck processes are left behind (not sure how probable, however). -JB- > > /Staffan > > > On 25 sep 2014, at 11:54, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: > >> Please, review the following change to the JDK test library class >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 >> >> Currently, the ProcessTools.startProcess() might leave a dangling process behind when a timeout or interrupt happens. The solution is to try and forcibly terminate the forked process when this happens. >> >> Thanks, >> >> -JB- > From ivan.gerasimov at oracle.com Thu Sep 25 10:26:13 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 25 Sep 2014 14:26:13 +0400 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <5423EBE5.6020901@oracle.com> References: <5423C758.3060904@oracle.com> <5423E535.90908@oracle.com> <5423EA9B.7010400@oracle.com> <5423EBE5.6020901@oracle.com> Message-ID: <5423EDC5.8030701@oracle.com> On 25.09.2014 14:18, Daniel Fuchs wrote: > Hi Ivan, > > Should 'usage' also be redirected? > This would be inconsistent with other command line utilities. They usually print help/usage to stdout. Sincerely yours, Ivan > best regards, > > -- daniel > > On 25/09/14 12:12, Ivan Gerasimov wrote: >> Thank you Daniel for the comments! >> >> On 25.09.2014 13:49, Daniel Fuchs wrote: >>> Hi Ivan, >>> >>> When setting output & input, I wonder if it would be simpler >>> to use an 'if else if' construct in order to avoid the '-a' >>> in the 'if' that follows. >>> >> We would still need that -a in if, as the user could pass /dev/stdin and >> /dev/stdout as the arguments to the script. >> Dashes are meant to be the shortcut for these long names, but we should >> allow the long names to be passed too. >> >>> something like this (pseudo code) might be easier to read: >>> >>> if "x$output" is "x-" then >>> substitute - with /dev/stdout >>> else if $output file exists >>> complain >>> endif >>> >>> Also the script uses echo to print warnings & error. >>> It should probably be changed to print those on stderr ( >&2 ) >>> so that they don't mix with the patch when the output is '-'. >>> >> Agreed! >> Redirected all the error messages to stderr. >> >>> Similarly - I feel that either verbose should redirect to >>> stderr, or the script should complain and exit if output >>> is '-' and verbose is on. >>> >> Done. >> >> Please see the updated webrev: >> http://cr.openjdk.java.net/~igerasim/8059101/1/webrev/ >> >> Sincerely yours, >> Ivan >> > > > From mikael.auno at oracle.com Thu Sep 25 10:31:10 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Thu, 25 Sep 2014 12:31:10 +0200 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes In-Reply-To: <5423ED46.8040407@oracle.com> References: <5423E64E.6060004@oracle.com> <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> <5423ED46.8040407@oracle.com> Message-ID: <5423EEEE.8000505@oracle.com> On 2014-09-25 12:24, Jaroslav Bachorik wrote: > On 09/25/2014 12:13 PM, Staffan Larsen wrote: >> I wonder if the p.waitFor() is needed? What if the process launching >> expired with a timeout and now we are still waiting for the process to >> end - wouldn?t that kind of defeat the timeout? In any case, the >> destroyForcibly() should end the process whether we wait for it or not. > > It would be wonderful but the javadoc states that the result of > destroyForcibly() call depends on the implementation and may actually > not force close the process and one should use waitFor() to make sure > that the process has in fact died. The javadoc also states though, that the implementation you get when using either ProcessBuilder.start() or Runtime.exec() does in fact forcibly terminate the process. ProcessTools.startProcess() does use ProcessBuilder.start(), so you should be good on that point at least. Mikael > I wonder whether JTReg kills the process tree on timeout - in case it > does using waitFor() would guarantee that there would be no zombies > left. Without using waitFor() and semantics of destroyForcibly() there > might be situations when non-functional stuck processes are left behind > (not sure how probable, however). > > -JB- > >> >> /Staffan >> >> >> On 25 sep 2014, at 11:54, Jaroslav Bachorik >> <jaroslav.bachorik at oracle.com> wrote: >> >>> Please, review the following change to the JDK test library class >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 >>> >>> Currently, the ProcessTools.startProcess() might leave a dangling >>> process behind when a timeout or interrupt happens. The solution is >>> to try and forcibly terminate the forked process when this happens. >>> >>> Thanks, >>> >>> -JB- >> > From staffan.larsen at oracle.com Thu Sep 25 10:33:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 25 Sep 2014 12:33:14 +0200 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes In-Reply-To: <5423ED46.8040407@oracle.com> References: <5423E64E.6060004@oracle.com> <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> <5423ED46.8040407@oracle.com> Message-ID: <009B1294-3DC3-4278-BCD6-E4B6FCF86884@oracle.com> On 25 sep 2014, at 12:24, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: > On 09/25/2014 12:13 PM, Staffan Larsen wrote: >> I wonder if the p.waitFor() is needed? What if the process launching expired with a timeout and now we are still waiting for the process to end - wouldn?t that kind of defeat the timeout? In any case, the destroyForcibly() should end the process whether we wait for it or not. > > It would be wonderful but the javadoc states that the result of destroyForcibly() call depends on the implementation and may actually not force close the process and one should use waitFor() to make sure that the process has in fact died. It also mentions that Processes returned by ProcessBuilder.start() will be terminated forcibly so we can rely on that. I don?t know how much it helps to wait for the process. If it wasn?t terminated, then we risk blocking forever here - still without having terminated the process. > I wonder whether JTReg kills the process tree on timeout - in case it does using waitFor() would guarantee that there would be no zombies left. Without using waitFor() and semantics of destroyForcibly() there might be situations when non-functional stuck processes are left behind (not sure how probable, however). JTreg currently has no process tree handling - there is work in progress to add it as it is clearly desirable. /Staffan > > -JB- > >> >> /Staffan >> >> >> On 25 sep 2014, at 11:54, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: >> >>> Please, review the following change to the JDK test library class >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 >>> >>> Currently, the ProcessTools.startProcess() might leave a dangling process behind when a timeout or interrupt happens. The solution is to try and forcibly terminate the forked process when this happens. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Thu Sep 25 10:39:09 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 25 Sep 2014 12:39:09 +0200 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes In-Reply-To: <009B1294-3DC3-4278-BCD6-E4B6FCF86884@oracle.com> References: <5423E64E.6060004@oracle.com> <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> <5423ED46.8040407@oracle.com> <009B1294-3DC3-4278-BCD6-E4B6FCF86884@oracle.com> Message-ID: <5423F0CD.2020907@oracle.com> On 09/25/2014 12:33 PM, Staffan Larsen wrote: > > On 25 sep 2014, at 12:24, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: > >> On 09/25/2014 12:13 PM, Staffan Larsen wrote: >>> I wonder if the p.waitFor() is needed? What if the process launching expired with a timeout and now we are still waiting for the process to end - wouldn?t that kind of defeat the timeout? In any case, the destroyForcibly() should end the process whether we wait for it or not. >> >> It would be wonderful but the javadoc states that the result of destroyForcibly() call depends on the implementation and may actually not force close the process and one should use waitFor() to make sure that the process has in fact died. > > It also mentions that Processes returned by ProcessBuilder.start() will be terminated forcibly so we can rely on that. I don?t know how much it helps to wait for the process. If it wasn?t terminated, then we risk blocking forever here - still without having terminated the process. > >> I wonder whether JTReg kills the process tree on timeout - in case it does using waitFor() would guarantee that there would be no zombies left. Without using waitFor() and semantics of destroyForcibly() there might be situations when non-functional stuck processes are left behind (not sure how probable, however). > > JTreg currently has no process tree handling - there is work in progress to add it as it is clearly desirable. Ok. These are valid reasons for not using waitFor() - http://cr.openjdk.java.net/~jbachorik/8059034/webrev.01 -JB- > > /Staffan > > >> >> -JB- >> >>> >>> /Staffan >>> >>> >>> On 25 sep 2014, at 11:54, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: >>> >>>> Please, review the following change to the JDK test library class >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 >>>> >>>> Currently, the ProcessTools.startProcess() might leave a dangling process behind when a timeout or interrupt happens. The solution is to try and forcibly terminate the forked process when this happens. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From staffan.larsen at oracle.com Thu Sep 25 10:45:23 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 25 Sep 2014 12:45:23 +0200 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes In-Reply-To: <5423F0CD.2020907@oracle.com> References: <5423E64E.6060004@oracle.com> <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> <5423ED46.8040407@oracle.com> <009B1294-3DC3-4278-BCD6-E4B6FCF86884@oracle.com> <5423F0CD.2020907@oracle.com> Message-ID: <B6D98CBD-B773-49D7-B229-449528AA804B@oracle.com> Looks good! No need for the assignment to p, though. /Staffan On 25 sep 2014, at 12:39, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: > On 09/25/2014 12:33 PM, Staffan Larsen wrote: >> >> On 25 sep 2014, at 12:24, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: >> >>> On 09/25/2014 12:13 PM, Staffan Larsen wrote: >>>> I wonder if the p.waitFor() is needed? What if the process launching expired with a timeout and now we are still waiting for the process to end - wouldn?t that kind of defeat the timeout? In any case, the destroyForcibly() should end the process whether we wait for it or not. >>> >>> It would be wonderful but the javadoc states that the result of destroyForcibly() call depends on the implementation and may actually not force close the process and one should use waitFor() to make sure that the process has in fact died. >> >> It also mentions that Processes returned by ProcessBuilder.start() will be terminated forcibly so we can rely on that. I don?t know how much it helps to wait for the process. If it wasn?t terminated, then we risk blocking forever here - still without having terminated the process. >> >>> I wonder whether JTReg kills the process tree on timeout - in case it does using waitFor() would guarantee that there would be no zombies left. Without using waitFor() and semantics of destroyForcibly() there might be situations when non-functional stuck processes are left behind (not sure how probable, however). >> >> JTreg currently has no process tree handling - there is work in progress to add it as it is clearly desirable. > > Ok. These are valid reasons for not using waitFor() - http://cr.openjdk.java.net/~jbachorik/8059034/webrev.01 > > -JB- > >> >> /Staffan >> >> >>> >>> -JB- >>> >>>> >>>> /Staffan >>>> >>>> >>>> On 25 sep 2014, at 11:54, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote: >>>> >>>>> Please, review the following change to the JDK test library class >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 >>>>> >>>>> Currently, the ProcessTools.startProcess() might leave a dangling process behind when a timeout or interrupt happens. The solution is to try and forcibly terminate the forked process when this happens. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- From chris.hegarty at oracle.com Thu Sep 25 12:21:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 25 Sep 2014 05:21:49 -0700 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <5423EA9B.7010400@oracle.com> References: <5423C758.3060904@oracle.com> <5423E535.90908@oracle.com> <5423EA9B.7010400@oracle.com> Message-ID: <D99F3797-2E25-4FFA-87AF-C07DB873014D@oracle.com> On 25 Sep 2014, at 03:12, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote: > Thank you Daniel for the comments! > > On 25.09.2014 13:49, Daniel Fuchs wrote: >> Hi Ivan, >> >> When setting output & input, I wonder if it would be simpler >> to use an 'if else if' construct in order to avoid the '-a' >> in the 'if' that follows. >> > We would still need that -a in if, as the user could pass /dev/stdin and /dev/stdout as the arguments to the script. > Dashes are meant to be the shortcut for these long names, but we should allow the long names to be passed too. > >> something like this (pseudo code) might be easier to read: >> >> if "x$output" is "x-" then >> substitute - with /dev/stdout >> else if $output file exists >> complain >> endif >> >> Also the script uses echo to print warnings & error. >> It should probably be changed to print those on stderr ( >&2 ) >> so that they don't mix with the patch when the output is '-'. >> > Agreed! > Redirected all the error messages to stderr. > >> Similarly - I feel that either verbose should redirect to >> stderr, or the script should complain and exit if output >> is '-' and verbose is on. >> > Done. > > Please see the updated webrev: > http://cr.openjdk.java.net/~igerasim/8059101/1/webrev/ This looks ok to me. -Chris. > > Sincerely yours, > Ivan > From chris.hegarty at oracle.com Thu Sep 25 12:23:17 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 25 Sep 2014 05:23:17 -0700 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <5423C758.3060904@oracle.com> References: <5423C758.3060904@oracle.com> Message-ID: <0EE3C3EF-AC19-45F7-A842-4D7CD7298125@oracle.com> On 25 Sep 2014, at 00:42, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote: > Hello! > > This is a proposal to enhance the unshuffle_patch.sh script so that it will be able to read from stdin and write to stdout. > This would let us use the script in a pipe chain. > > For example, the following line could be used to apply a patch directly from a remote repository: > wget -q -O - http://path.to.the.raw.patch | bash ~/jdk9/common/bin/unshuffle_patch.sh jdk - - | hg patch - --no-commit > > (Note, that it would only work, if the repository provides the patches in the git format, which is not currently the case with hg.openjdk.java.net.) It would be nice to start a thread with ops at o.j.n to request that this be changed. -Chris. > Would you please help review/approve this enhancement? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059101 > WEBREV: http://cr.openjdk.java.net/~igerasim/8059101/0/webrev/ > > Sincerely yours, > Ivan > From daniel.fuchs at oracle.com Thu Sep 25 12:57:46 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 25 Sep 2014 14:57:46 +0200 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <5423EDC5.8030701@oracle.com> References: <5423C758.3060904@oracle.com> <5423E535.90908@oracle.com> <5423EA9B.7010400@oracle.com> <5423EBE5.6020901@oracle.com> <5423EDC5.8030701@oracle.com> Message-ID: <5424114A.9030508@oracle.com> On 25/09/14 12:26, Ivan Gerasimov wrote: > > On 25.09.2014 14:18, Daniel Fuchs wrote: >> Hi Ivan, >> >> Should 'usage' also be redirected? >> > This would be inconsistent with other command line utilities. > They usually print help/usage to stdout. Right. I suspected something like that. This looks good! thanks, -- daniel > > Sincerely yours, > Ivan > >> best regards, >> >> -- daniel >> >> On 25/09/14 12:12, Ivan Gerasimov wrote: >>> Thank you Daniel for the comments! >>> >>> On 25.09.2014 13:49, Daniel Fuchs wrote: >>>> Hi Ivan, >>>> >>>> When setting output & input, I wonder if it would be simpler >>>> to use an 'if else if' construct in order to avoid the '-a' >>>> in the 'if' that follows. >>>> >>> We would still need that -a in if, as the user could pass /dev/stdin and >>> /dev/stdout as the arguments to the script. >>> Dashes are meant to be the shortcut for these long names, but we should >>> allow the long names to be passed too. >>> >>>> something like this (pseudo code) might be easier to read: >>>> >>>> if "x$output" is "x-" then >>>> substitute - with /dev/stdout >>>> else if $output file exists >>>> complain >>>> endif >>>> >>>> Also the script uses echo to print warnings & error. >>>> It should probably be changed to print those on stderr ( >&2 ) >>>> so that they don't mix with the patch when the output is '-'. >>>> >>> Agreed! >>> Redirected all the error messages to stderr. >>> >>>> Similarly - I feel that either verbose should redirect to >>>> stderr, or the script should complain and exit if output >>>> is '-' and verbose is on. >>>> >>> Done. >>> >>> Please see the updated webrev: >>> http://cr.openjdk.java.net/~igerasim/8059101/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >> >> >> > From ivan.gerasimov at oracle.com Thu Sep 25 13:25:54 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 25 Sep 2014 17:25:54 +0400 Subject: RFR [9] 8059101: unshuffle_patch.sh should be able to deal with stdin/stdout In-Reply-To: <D99F3797-2E25-4FFA-87AF-C07DB873014D@oracle.com> References: <5423C758.3060904@oracle.com> <5423E535.90908@oracle.com> <5423EA9B.7010400@oracle.com> <D99F3797-2E25-4FFA-87AF-C07DB873014D@oracle.com> Message-ID: <542417E2.4050204@oracle.com> Thank you Daniel and Chris for your review! Sincerely yous, Ivan Please see the updated webrev: http://cr.openjdk.java.net/~igerasim/8059101/1/webrev/ > This looks ok to me. > From roger.riggs at oracle.com Thu Sep 25 13:39:02 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 25 Sep 2014 09:39:02 -0400 Subject: RFR 8059034: ProcessTools.startProcess() might leak processes In-Reply-To: <5423ED46.8040407@oracle.com> References: <5423E64E.6060004@oracle.com> <53FF3542-B53D-4BAD-AE2D-C96F6BBFD698@oracle.com> <5423ED46.8040407@oracle.com> Message-ID: <54241AF6.3040907@oracle.com> Hi, The spec for destroyForcibly goes on to say that ProcessBuilder implements destroyForcibly correctly. " Invoking this method on Process objects returned by ProcessBuilder.start() and Runtime.exec(java.lang.String) will forcibly terminate the process. " Roger On 9/25/2014 6:24 AM, Jaroslav Bachorik wrote: > On 09/25/2014 12:13 PM, Staffan Larsen wrote: >> I wonder if the p.waitFor() is needed? What if the process launching >> expired with a timeout and now we are still waiting for the process >> to end - wouldn?t that kind of defeat the timeout? In any case, the >> destroyForcibly() should end the process whether we wait for it or not. > > It would be wonderful but the javadoc states that the result of > destroyForcibly() call depends on the implementation and may actually > not force close the process and one should use waitFor() to make sure > that the process has in fact died. > > I wonder whether JTReg kills the process tree on timeout - in case it > does using waitFor() would guarantee that there would be no zombies > left. Without using waitFor() and semantics of destroyForcibly() there > might be situations when non-functional stuck processes are left > behind (not sure how probable, however). > > -JB- > >> >> /Staffan >> >> >> On 25 sep 2014, at 11:54, Jaroslav Bachorik >> <jaroslav.bachorik at oracle.com> wrote: >> >>> Please, review the following change to the JDK test library class >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8059034 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00 >>> >>> Currently, the ProcessTools.startProcess() might leave a dangling >>> process behind when a timeout or interrupt happens. The solution is >>> to try and forcibly terminate the forked process when this happens. >>> >>> Thanks, >>> >>> -JB- >> > From omajid at redhat.com Fri Sep 26 20:15:51 2014 From: omajid at redhat.com (Omair Majid) Date: Fri, 26 Sep 2014 16:15:51 -0400 Subject: RFC: JDK 9 Sandbox Forest Proposal In-Reply-To: <5420880E.8050009@oracle.com> References: <C712C3CA-10AD-4C8D-BB29-953E70D00D80@oracle.com> <B0628A45-89D5-40BD-B077-91FC9DCBA03C@oracle.com> <CA+3eh1335gBvv6Ap6nCXSQ_nXrG7An=mLT2Z2NktRfdroond3Q@mail.gmail.com> <EC6D0F06-52ED-42F0-9350-0A2792A7EA6A@oracle.com> <5420880E.8050009@oracle.com> Message-ID: <20140926201551.GB2389@redhat.com> * Joe Darcy <joe.darcy at oracle.com> [2014-09-22 16:36]: > One reason I'd like to see the JDK organization uses branches for this > project is so that branches could be included in our toolbox of features to > use for multi-release work. Please also consider including 'bookmarks' in the toolbox too. What mercurial calls 'bookmarks' is what other version control systems (such as git) call branches. It seems like 'bookmarks' make much more sense for use in feature-branches than 'branches'. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From alejandro.murillo at oracle.com Tue Sep 30 16:01:55 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 30 Sep 2014 10:01:55 -0600 Subject: jdk9-dev: HotSpot Message-ID: <542AD3F3.7060001@oracle.com> jdk9-hs-2014-09-26 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/ee584a8ce1f0 http://hg.openjdk.java.net/jdk9/dev/corba/rev/0e38044a6f85 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/c5ad82e4b5a7 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/46b360454dad http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/77a45995dd3b http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4dc46f07109f http://hg.openjdk.java.net/jdk9/dev/langtools/rev/1a77eeed0c06 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/dee18a93b53f Component : VM Status : Go for integration Date : 09/30/2014 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-09-26-091034.amurillo.jdk9-hs-2014-09-26-snapshot Testing: 235 new failures, 3097 known failures, 382421 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8058863: jdk9/hs-comp fails in jprt with "-testset hotspot" from top-level -- Alejandro