From kelly.ohair at oracle.com Wed Jun 1 10:44:03 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Wed, 01 Jun 2011 17:44:03 +0000 Subject: hg: jdk7/tl/jaxws: 7049699: Problem with xml/jax-ws Message-ID: <20110601174403.EC7BA47AC8@hg.openjdk.java.net> Changeset: bcca8afc019f Author: ohair Date: 2011-06-01 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/bcca8afc019f 7049699: Problem with xml/jax-ws Reviewed-by: ramap ! jaxws.properties From jonathan.gibbons at oracle.com Wed Jun 1 11:27:46 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 01 Jun 2011 18:27:46 +0000 Subject: hg: jdk7/tl/langtools: 7042623: Regression: javac silently crash when attributing non-existent annotation Message-ID: <20110601182750.84FAF47AD1@hg.openjdk.java.net> Changeset: 6762754eb7c0 Author: jjg Date: 2011-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6762754eb7c0 7042623: Regression: javac silently crash when attributing non-existent annotation Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T7042623.java + test/tools/javac/T7042623.out From daniel.daugherty at oracle.com Wed Jun 1 20:44:37 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 02 Jun 2011 03:44:37 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110602034531.498AF47AED@hg.openjdk.java.net> Changeset: 0da0a4d22fba Author: dcubed Date: 2011-06-01 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0da0a4d22fba 7048308: 4/4 LoggingDeadlock3 test timeout is too small Summary: Change timeout for test from 15 seconds to 80 seconds. Reviewed-by: dholmes ! test/java/util/logging/LoggingDeadlock3.java Changeset: 4a221501079a Author: dcubed Date: 2011-06-01 17:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a221501079a 7045594: 4/4 fix for 6977677 introduced a ResourceBundle race Summary: Fix Logger.getLogger() ResourceBundle name race. Reviewed-by: dholmes, mchung ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerResourceBundleRace.java + test/java/util/logging/RacingThreadsTest.java From joe.darcy at oracle.com Wed Jun 1 23:56:48 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 02 Jun 2011 06:56:48 +0000 Subject: hg: jdk8/tl/langtools: 7025784: Add SourceVersion.RELEASE_8; ... Message-ID: <20110602065653.A193C47AF5@hg.openjdk.java.net> Changeset: defdd98cb7ce Author: darcy Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/defdd98cb7ce 7025784: Add SourceVersion.RELEASE_8 7025786: Add -source 8 and -target 8 to javac 7025789: Change javac source and target default to 8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/javax/lang/model/SourceVersion.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/quid/T6999438.java ! test/tools/javac/versions/check.sh From lance.andersen at oracle.com Thu Jun 2 09:03:03 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 02 Jun 2011 16:03:03 +0000 Subject: hg: jdk7/tl/jdk: 7049107: Cannot call initCause() on BatchUpdateException Message-ID: <20110602160345.151E547B0B@hg.openjdk.java.net> Changeset: a00f48c96345 Author: lancea Date: 2011-06-02 12:02 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a00f48c96345 7049107: Cannot call initCause() on BatchUpdateException Reviewed-by: darcy ! src/share/classes/java/sql/BatchUpdateException.java From lana.steuck at oracle.com Fri Jun 3 21:50:26 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 04 Jun 2011 04:50:26 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20110604045026.DD14A47B87@hg.openjdk.java.net> Changeset: 4373d87e6f37 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4373d87e6f37 Added tag jdk7-b144 for changeset 7203965666a4 ! .hgtags Changeset: 55e9ebf03218 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/55e9ebf03218 Merge From lana.steuck at oracle.com Fri Jun 3 21:50:31 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 04 Jun 2011 04:50:31 +0000 Subject: hg: jdk7/tl/jaxp: 2 new changesets Message-ID: <20110604045031.B05D047B88@hg.openjdk.java.net> Changeset: bee49f47043f Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bee49f47043f Added tag jdk7-b144 for changeset 39bf6dcaab23 ! .hgtags Changeset: 10ca7570f47f Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/10ca7570f47f Merge From lana.steuck at oracle.com Fri Jun 3 21:50:25 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 04 Jun 2011 04:50:25 +0000 Subject: hg: jdk7/tl/corba: 3 new changesets Message-ID: <20110604045032.D2E3747B89@hg.openjdk.java.net> Changeset: 7033a5756ad5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/7033a5756ad5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java Changeset: 74eb715474f2 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/74eb715474f2 Added tag jdk7-b144 for changeset 7033a5756ad5 ! .hgtags Changeset: 77ec0541aa2a Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/77ec0541aa2a Merge From lana.steuck at oracle.com Fri Jun 3 21:50:36 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 04 Jun 2011 04:50:36 +0000 Subject: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20110604045036.36B9C47B8A@hg.openjdk.java.net> Changeset: 6158298d2b94 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/6158298d2b94 Added tag jdk7-b144 for changeset 6bd683f2d527 ! .hgtags Changeset: 42bfba80beb7 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/42bfba80beb7 Merge From lana.steuck at oracle.com Fri Jun 3 21:50:43 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 04 Jun 2011 04:50:43 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20110604045052.325F747B8B@hg.openjdk.java.net> Changeset: 8eb952f43b11 Author: katleman Date: 2011-05-25 13:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8eb952f43b11 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! test/tools/javac/4241573/T4241573.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/TryWithResources/DuplicateResource.java ! test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/T6838467.java ! test/tools/javac/api/T6877206.java ! test/tools/javac/api/TestClientCodeWrapper.java ! test/tools/javac/api/TestJavacTask_Lock.java ! test/tools/javac/api/TestJavacTask_Multiple.java ! test/tools/javac/api/TestJavacTask_ParseAttrGen.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/tree/T6963934.java Changeset: 9f25c6a3ac23 Author: schien Date: 2011-05-26 20:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9f25c6a3ac23 Added tag jdk7-b144 for changeset 8eb952f43b11 ! .hgtags Changeset: c455e2ae5c93 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c455e2ae5c93 Merge From lana.steuck at oracle.com Fri Jun 3 21:50:38 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 04 Jun 2011 04:50:38 +0000 Subject: hg: jdk7/tl/hotspot: 32 new changesets Message-ID: <20110604045141.EEF5447B8C@hg.openjdk.java.net> Changeset: 2aa9ddbb9e60 Author: jmasa Date: 2011-05-03 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2aa9ddbb9e60 7041789: 30% perf regression with c2/arm following 7017732 Summary: Implement a more accurate is_scavengable() Reviewed-by: stefank, jcoomes, ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/instanceRefKlass.cpp Changeset: 69293e516993 Author: johnc Date: 2011-05-17 00:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/69293e516993 7041440: G1: assert(obj->is_oop_or_null(true )) failed: Error # Summary: During an evacuation pause clear the region fields of any concurrent marking task whose local finger points into the collection set as the values in the region fields will become stale. Clearing these fields causes the concurrent mark task to claim a new region when marking restarts after the pause. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: ea4859d7fee7 Author: brutisso Date: 2011-05-18 13:19 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ea4859d7fee7 Merge Changeset: 03b943e6c025 Author: dholmes Date: 2011-05-15 23:57 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/03b943e6c025 7035744: jprt no longer does open-only builds Summary: Added Open (OpenJDK) and Emb (Embedded) build flavours to JPRT. Added a few open builds and basic sanity tests to the normal JDK7 JPRT submission job. Reviewed-by: ohair, jcoomes, bobv, kvn ! make/jprt.gmk ! make/jprt.properties Changeset: 8bec9b249a6e Author: dholmes Date: 2011-05-17 09:29 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8bec9b249a6e Merge Changeset: 3f3325361b86 Author: kamg Date: 2011-05-18 10:12 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f3325361b86 Merge Changeset: 38569792a45a Author: kvn Date: 2011-05-16 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/38569792a45a 7044725: -XX:-UnrollLimitCheck -Xcomp : Exception: String index out of range: 29488 Summary: Fix problems in new RCE code. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp Changeset: f52ed367b66d Author: never Date: 2011-05-16 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f52ed367b66d 6996747: SIGSEGV in nmethod::cleanup_inline_caches / CompiledIC::verify Reviewed-by: kvn, iveresov ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 33ae33516634 Author: bdelsart Date: 2011-05-17 16:50 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/33ae33516634 7045515: ARM assembly code for JSR 292 ricochet frames Summary: ARM ricochet port and minor fixes in shared debug code Reviewed-by: jrose, vladidan ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 231c2b41ea4d Author: kvn Date: 2011-05-17 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/231c2b41ea4d 7045570: compiler/5091921/Test7005594.java failed because not enough space for object heap Summary: fixed tests. Reviewed-by: iveresov, never ! test/compiler/5091921/Test6890943.sh ! test/compiler/5091921/Test7005594.java + test/compiler/5091921/Test7005594.sh Changeset: 2848194272f4 Author: jrose Date: 2011-05-17 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2848194272f4 7044892: JSR 292: API entry points sometimes throw the wrong exceptions or doesn't throw the expected one Summary: Fix to 7042656: JSR292: invokeExact/Generic doesn't throw UnsupportedOperationException if invoked via Method.invoke Reviewed-by: never ! src/share/vm/prims/methodHandles.cpp Changeset: a80577f854f9 Author: never Date: 2011-05-17 19:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a80577f854f9 7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp Reviewed-by: jrose ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java + agent/src/share/classes/sun/jvm/hotspot/code/AdapterBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java + agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b79e8b4ecd76 Author: never Date: 2011-05-17 19:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b79e8b4ecd76 Merge ! src/share/vm/prims/methodHandles.cpp Changeset: 1be2f0c40a34 Author: never Date: 2011-05-18 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1be2f0c40a34 Merge Changeset: 62f39d40ebf1 Author: trims Date: 2011-05-20 05:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/62f39d40ebf1 7040781: Bump the HS21 build number to 14 Summary: Update the HS21 build number to 14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 278445be9145 Author: trims Date: 2011-05-24 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/278445be9145 Added tag hs21-b13 for changeset c149193c768b ! .hgtags Changeset: 01e01c25d24a Author: trims Date: 2011-05-24 14:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/01e01c25d24a Merge ! .hgtags Changeset: fe189d4a44e9 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fe189d4a44e9 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! make/linux/README ! make/windows/projectfiles/kernel/Makefile ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: d920485ae93b Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d920485ae93b Added tag jdk7-b144 for changeset fe189d4a44e9 ! .hgtags Changeset: 2b27ef5c2173 Author: kvn Date: 2011-05-20 12:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2b27ef5c2173 7046096: SEGV IN C2 WITH 6U25 Summary: Missing fail flag set in strings concatenation code. Reviewed-by: never ! src/share/vm/opto/stringopts.cpp Changeset: cfbca4d74a61 Author: jcoomes Date: 2011-05-20 22:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cfbca4d74a61 Merge Changeset: 789d04408ca3 Author: kvn Date: 2011-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/789d04408ca3 7045693: java/util/EnumSet/EnumSetBash.java still failing intermittently Summary: New limit for unrolled loop should be set only for zero trip guard and loop iteration test. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: b55f5bd7ec66 Author: kvn Date: 2011-05-21 13:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b55f5bd7ec66 7045506: assert(!can_reshape || !new_phi) failed: for igvn new phi should be hooked Summary: Replace the assert in PhiNode::Ideal with check to avoid transformation of new phi. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp Changeset: 7523488edce5 Author: kvn Date: 2011-05-24 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7523488edce5 7047300: VM crashes with assert(_base == InstPtr) failed: Not an object pointer Summary: The code incorrectly used is_instptr() instead of is_oopptr() to get const_oop. Reviewed-by: never ! src/share/vm/opto/output.cpp Changeset: ccf072cdba91 Author: iveresov Date: 2011-05-24 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ccf072cdba91 7046893: LP64 problem with double_quadword in c1_LIRAssembler_x86.cpp Summary: Fixed invalid casts in address computation Reviewed-by: kvn, never Contributed-by: thomas.salter at unisys.com ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 28a9fe9534ea Author: kvn Date: 2011-05-24 20:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/28a9fe9534ea 7048030: is_scavengable changes causing compiler to embed more constants Summary: ciObject::can_be_constant() and should_be_constant() should use is_perm() instead of !is_scavengable() Reviewed-by: never, jrose ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp Changeset: 7db2b9499c36 Author: never Date: 2011-05-25 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7db2b9499c36 7046732: JSR 292 assert(result == cpce->f1()) failed: expected result for assembly code Reviewed-by: kvn, iveresov, jrose ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 2d4b2b833d29 Author: coleenp Date: 2011-05-27 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2d4b2b833d29 7033141: assert(has_cp_cache(i)) failed: oob Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache. Reviewed-by: dcubed, acorn, never ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 8cbcd406c42e Author: ysr Date: 2011-05-27 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8cbcd406c42e 7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557 Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/blockOffsetTable.cpp Changeset: b36598cf2c62 Author: jcoomes Date: 2011-05-27 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b36598cf2c62 Merge Changeset: 472fc37e14a9 Author: jcoomes Date: 2011-05-27 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/472fc37e14a9 7049385: Bump the HS21 build number to 15 Summary: Update the HS21 build number to 15 Reviewed-by: trims ! make/hotspot_version Changeset: 63d3fb179034 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/63d3fb179034 Merge From lana.steuck at oracle.com Fri Jun 3 21:51:02 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 04 Jun 2011 04:51:02 +0000 Subject: hg: jdk7/tl/jdk: 26 new changesets Message-ID: <20110604045527.2A4D347B8D@hg.openjdk.java.net> Changeset: 20bf5b0970e9 Author: jrose Date: 2011-05-17 19:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/20bf5b0970e9 7032850: MethodHandle.invokeGeneric throws unspecified RuntimeException if parameterized method is called Summary: Implement invocation corner cases, including correct type conversions and interface type enforcement. Reviewed-by: never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/InvokeGeneric.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/6991596/Test6991596.java ! test/java/lang/invoke/InvokeGenericTest.java Changeset: 9828d98bcf18 Author: jrose Date: 2011-05-17 19:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9828d98bcf18 7044892: JSR 292: API entry points sometimes throw the wrong exceptions or doesn't throw the expected one Summary: point-fixes for 7038847, 7038860, 7042656, 7042829, 7041853, and several other reports Reviewed-by: never, kvn ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/FilterGeneric.java ! src/share/classes/java/lang/invoke/FilterOneArgument.java ! src/share/classes/java/lang/invoke/FromGeneric.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/invoke/SpreadGeneric.java ! src/share/classes/java/lang/invoke/ToGeneric.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: be4b9e596352 Author: trims Date: 2011-05-20 05:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be4b9e596352 Merge Changeset: 127560d6f6e6 Author: trims Date: 2011-05-24 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/127560d6f6e6 Merge Changeset: 23bdcede4e39 Author: katleman Date: 2011-05-25 13:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23bdcede4e39 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/keytool.1 ! src/share/classes/java/io/SerialCallbackContext.java ! src/share/classes/sun/io/ByteToCharCp833.java ! src/share/classes/sun/io/CharToByteCp833.java ! src/share/classes/sun/misc/FpUtils.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! test/com/sun/net/httpserver/Test10.java ! test/java/awt/List/ScrollOutside/ScrollOut.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_1.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_4.java ! test/java/awt/image/IncorrectSampleMaskTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/util/EnumMap/DistinctEntrySetElements.java ! test/java/util/EnumMap/EntrySetIteratorRemoveInvalidatesEntry.java ! test/java/util/EnumMap/SimpleSerialization.java ! test/java/util/EnumSet/LargeEnumIteratorRemoveResilience.java ! test/java/util/EnumSet/SmallEnumIteratorRemoveResilience.java ! test/java/util/Hashtable/SerializationDeadlock.java ! test/java/util/Hashtable/SimpleSerialization.java ! test/java/util/IdentityHashMap/DistinctEntrySetElements.java ! test/java/util/IdentityHashMap/EntrySetIteratorRemoveInvalidatesEntry.java ! test/java/util/Vector/SerializationDeadlock.java ! test/java/util/Vector/SimpleSerialization.java ! test/java/util/concurrent/ConcurrentHashMap/DistinctEntrySetElements.java ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java ! test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor ! test/tools/launcher/TestHelper.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/Utils.java Changeset: c344779fab58 Author: schien Date: 2011-05-26 20:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c344779fab58 Added tag jdk7-b144 for changeset 23bdcede4e39 ! .hgtags Changeset: f09930d526ba Author: jrose Date: 2011-05-26 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f09930d526ba 7032323: code changes for JSR 292 EG adjustments to API, through Public Review Summary: API code changes and javadoc changes following JSR 292 Public Review comments, through PFD Reviewed-by: never ! src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/6998541/Test6998541.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/indify/Indify.java Changeset: 81f957f86ba5 Author: jcoomes Date: 2011-05-27 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/81f957f86ba5 Merge Changeset: bc97b962330e Author: mfang Date: 2011-05-26 20:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc97b962330e 7045184: GTK L&F doesn't have hotkeys in jdk7 b141, while b139 has. Reviewed-by: yhuang, ogino ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties Changeset: 6943c4d9caa3 Author: mfang Date: 2011-05-31 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6943c4d9caa3 Merge Changeset: 7c5bc5a807ee Author: dholmes Date: 2011-05-27 19:04 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c5bc5a807ee 7024120: Verify reduced JRE contents for java 7 Summary: stripped all symbols from libs and executables to reduce JRE size. Restored missing classes needed to pass JCK in headless mode Reviewed-by: bobv, ohair ! make/common/Defs-embedded.gmk ! make/common/Release-embedded.gmk Changeset: f4895b3fe1be Author: dholmes Date: 2011-05-31 17:28 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4895b3fe1be Merge Changeset: eab27338b3d9 Author: schien Date: 2011-06-01 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eab27338b3d9 Merge Changeset: 8d91855a1f4e Author: prr Date: 2011-05-27 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8d91855a1f4e 7046587: Outlines in OTF/CFF fonts are misclassified as quadratic curves Reviewed-by: igor ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0b0b92707cf5 Author: bae Date: 2011-05-30 12:05 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0b0b92707cf5 7032904: XRender: Java2Demo : Infinite loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64 Reviewed-by: prr ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 290daca0a693 Author: prr Date: 2011-05-30 22:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/290daca0a693 7049874: OpenJDK Build breakage fix: freetypescaler.c needs to match updated signature Reviewed-by: lana, igor ! src/share/native/sun/font/freetypeScaler.c Changeset: b351af09bfa3 Author: lana Date: 2011-06-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b351af09bfa3 Merge Changeset: d2081a1f417f Author: bagiras Date: 2011-05-27 11:45 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d2081a1f417f 7045174: Most of the tests in awt area fails with jdk 7b142 on windows with -Xcheck:jni Reviewed-by: art, denis ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 000a845b1e38 Author: denis Date: 2011-05-28 12:56 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/000a845b1e38 7046325: Broken links in java.awt.Toolkit's javadoc Reviewed-by: dav, yan ! src/share/classes/java/awt/Toolkit.java Changeset: eab94f59b6dc Author: dcherepanov Date: 2011-05-30 13:25 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eab94f59b6dc 7045354: Korean IME's Hanja candidate window is not displayed on IMFDemo Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp Changeset: f05164caa490 Author: serb Date: 2011-05-30 17:16 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f05164caa490 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail Reviewed-by: dcherepanov, dav, art, denis ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: b955226868af Author: lana Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b955226868af Merge Changeset: 1fbaf2b688a6 Author: rupashka Date: 2011-05-24 11:37 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1fbaf2b688a6 7045593: Possible Regression : JTextfield cursor placement behavior algorithm has changed. Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java + test/javax/swing/text/Utilities/bug7045593.java Changeset: 442237d3ec2c Author: rupashka Date: 2011-05-28 11:55 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/442237d3ec2c 7048204: NPE from NimbusLookAndFeel.addDefault Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/Test7048204.java Changeset: 386516fdf40b Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/386516fdf40b Merge Changeset: 39de8937c1d8 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39de8937c1d8 Merge From alan.bateman at oracle.com Sat Jun 4 03:19:35 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 04 Jun 2011 10:19:35 +0000 Subject: hg: jdk7/tl/jdk: 7050358: (fs spec) Path.toUri doesn't allow custom providers to use opaque URIs Message-ID: <20110604101958.B7C1647BA3@hg.openjdk.java.net> Changeset: 53d759eb580c Author: alanb Date: 2011-06-04 11:18 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/53d759eb580c 7050358: (fs spec) Path.toUri doesn't allow custom providers to use opaque URIs Reviewed-by: sherman ! src/share/classes/java/nio/file/Path.java From sean.mullan at oracle.com Sat Jun 4 06:54:53 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Sat, 04 Jun 2011 13:54:53 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110604135522.BDF2B47BAB@hg.openjdk.java.net> Changeset: 49aef5a5416e Author: mullan Date: 2011-06-04 06:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49aef5a5416e 7050329: test/java/security/Policy/GetPermissions/JarURL.java fails on Windows Reviewed-by: alanb ! test/java/security/Policy/GetPermissions/JarURL.java + test/java/security/Policy/GetPermissions/JarURL.policy Changeset: 1f39ca0b9598 Author: mullan Date: 2011-06-04 06:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f39ca0b9598 Merge From neal at gafter.com Mon Jun 6 08:10:00 2011 From: neal at gafter.com (Neal Gafter) Date: Mon, 6 Jun 2011 08:10:00 -0700 Subject: java 6 compiler bug or ... In-Reply-To: <4DECA6EA.2030408@oracle.com> References: <4DECA6EA.2030408@oracle.com> Message-ID: That doesn't make sense as a fix. The reason for this error message is to enable compiling generics via erasure, but methods with return types whose erasures differ don't have VM signatures that conflict. One would think that maintaining backward compatibility is more important that mindless compliance with a specification that matches no previous implementation. Wouldn't it make more sense to fix the specification to allow what makes sense to allow rather than break compatibility? On Mon, Jun 6, 2011 at 3:07 AM, maurizio cimadamore < maurizio.cimadamore at oracle.com> wrote: > On 06/06/2011 09:31, Ali Ebrahimi wrote: > > Hi all, > > > > This test case compiles with java 6 compiler, but current compiler > rejects > > that. > > > > public class Test { > > > > static Integer call(List ls) { > > System.out.println("ls"); > > return 0; > > } > > > > static void call(List> lls) { > > System.out.println("lls"); > > } > > > > public static void main(String[] args) { > > > > } > > } > > > > current compiler error message: > > error: name clash: call(List>) and call(List) have > the > > same erasure > > > > Best Regards, > > Ali Ebrahimi > > > Hi Ali, > this is a JDK 6 bug that has been fixed in JDK 7 - as a result of a > merge, the lambda compiler picked up that fix. > > Maurizio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110606/8ca514ff/attachment.html From forax at univ-mlv.fr Mon Jun 6 15:58:06 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 07 Jun 2011 00:58:06 +0200 Subject: java 6 compiler bug or ... In-Reply-To: References: <4DECA6EA.2030408@oracle.com> Message-ID: <4DED5B7E.4020001@univ-mlv.fr> I agree with Neal, the spec should be fixed not the implementation. On 06/06/2011 05:10 PM, Neal Gafter wrote: > That doesn't make sense as a fix. The reason for this error message > is to enable compiling generics via erasure, but methods with return > types whose erasures differ don't have VM signatures that conflict. > One would think that maintaining backward compatibility is more > important that mindless compliance with a specification that matches > no previous implementation. In fact, it matches Eclipse JDT implementation. > Wouldn't it make more sense to fix the specification to allow what > makes sense to allow rather than break compatibility? R?mi > > On Mon, Jun 6, 2011 at 3:07 AM, maurizio cimadamore > > wrote: > > On 06/06/2011 09:31, Ali Ebrahimi wrote: > > Hi all, > > > > This test case compiles with java 6 compiler, but current > compiler rejects > > that. > > > > public class Test { > > > > static Integer call(List ls) { > > System.out.println("ls"); > > return 0; > > } > > > > static void call(List> lls) { > > System.out.println("lls"); > > } > > > > public static void main(String[] args) { > > > > } > > } > > > > current compiler error message: > > error: name clash: call(List>) and > call(List) have the > > same erasure > > > > Best Regards, > > Ali Ebrahimi > > > Hi Ali, > this is a JDK 6 bug that has been fixed in JDK 7 - as a result of a > merge, the lambda compiler picked up that fix. > > Maurizio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110607/ce37d24e/attachment.html From daniel.smith at oracle.com Mon Jun 6 17:41:07 2011 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 6 Jun 2011 17:41:07 -0700 Subject: java 6 compiler bug or ... In-Reply-To: <4DED5B7E.4020001@univ-mlv.fr> References: <4DECA6EA.2030408@oracle.com> <4DED5B7E.4020001@univ-mlv.fr> Message-ID: As background, this kind of thing comes up all the time in addressing bug reports. The typical process is: 1) observe a discrepancy between javac and the JLS, where neither is clearly in error; 2) try to characterize what javac is actually doing; 3) see what Eclipse does; 4) Compare the specified and implemented behavior, and try to find a minimally-invasive way to reconcile them. Frequently, the solution is as simple as changing a line in the JLS. Sometimes, the solution is a source-incompatible implementation change. There are costs in both directions, and we try to balance those costs appropriately. Of course this process is subjective, but it is also reasonably careful, I think. I misread Remi's comment about Eclipse, but that observation was probably influential in this particular case: javac was accepting programs that both the JLS and Eclipse considered malformed. ?Dan On Jun 6, 2011, at 3:58 PM, R?mi Forax wrote: > I agree with Neal, the spec should be fixed not the implementation. > > On 06/06/2011 05:10 PM, Neal Gafter wrote: >> That doesn't make sense as a fix. The reason for this error message is to enable compiling generics via erasure, but methods with return types whose erasures differ don't have VM signatures that conflict. One would think that maintaining backward compatibility is more important that mindless compliance with a specification that matches no previous implementation. > > In fact, it matches Eclipse JDT implementation. > >> Wouldn't it make more sense to fix the specification to allow what makes sense to allow rather than break compatibility? > > R?mi > >> >> On Mon, Jun 6, 2011 at 3:07 AM, maurizio cimadamore wrote: >> On 06/06/2011 09:31, Ali Ebrahimi wrote: >> > Hi all, >> > >> > This test case compiles with java 6 compiler, but current compiler rejects >> > that. >> > >> > public class Test { >> > >> > static Integer call(List ls) { >> > System.out.println("ls"); >> > return 0; >> > } >> > >> > static void call(List> lls) { >> > System.out.println("lls"); >> > } >> > >> > public static void main(String[] args) { >> > >> > } >> > } >> > >> > current compiler error message: >> > error: name clash: call(List>) and call(List) have the >> > same erasure >> > >> > Best Regards, >> > Ali Ebrahimi >> > >> Hi Ali, >> this is a JDK 6 bug that has been fixed in JDK 7 - as a result of a >> merge, the lambda compiler picked up that fix. >> >> Maurizio >> >> >> > From neal at gafter.com Tue Jun 7 07:02:55 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 7 Jun 2011 07:02:55 -0700 Subject: java 6 compiler bug or ... In-Reply-To: References: <4DECA6EA.2030408@oracle.com> <4DED5B7E.4020001@univ-mlv.fr> Message-ID: On Mon, Jun 6, 2011 at 5:41 PM, Dan Smith wrote: > As background, this kind of thing comes up all the time in addressing bug > reports. The typical process is: 1) observe a discrepancy between javac and > the JLS, where neither is clearly in error; 2) try to characterize what > javac is actually doing; 3) see what Eclipse does; 4) Compare the specified > and implemented behavior, and try to find a minimally-invasive way to > reconcile them. > > Frequently, the solution is as simple as changing a line in the JLS. > Sometimes, the solution is a source-incompatible implementation change. > There are costs in both directions, and we try to balance those costs > appropriately. Of course this process is subjective, but it is also > reasonably careful, I think. > > I misread Remi's comment about Eclipse, but that observation was probably > influential in this particular case: javac was accepting programs that both > the JLS and Eclipse considered malformed. > Having followed this kind of process as maintainer of javac and contributor to the JLS for some years, I am quite familiar with the process. In step (2), what javac used to be doing was quite straightforward (the rule about conflicting methods also takes into account the erasure of the return type). The backward-compatible and least-invasive (to the customer) way to fix it is obviously to add a line in the JLS and relax the Eclipse implementation. I cannot imagine what considerations would lead to the current result (other than, perhaps, that the JLS maintainer is too busy to make the necessary change to the specification). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110607/e7fe8dec/attachment.html From neal at gafter.com Tue Jun 7 13:17:09 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 7 Jun 2011 13:17:09 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: <4DEE5AAB.2060206@oracle.com> References: <4D9AD1B4.7020402@univ-mlv.fr> <4DEE5AAB.2060206@oracle.com> Message-ID: On Tue, Jun 7, 2011 at 10:06 AM, Joe Darcy wrote: > The JCP SE/EE executive committee voted to approve the JSR 336 public > review > > http://www.jcp.org/en/jsr/results?id=5207 > > and the JSR 336 public review describes JSR 292 as including Java language > changes. > *The jsr292 specification which was published for public review does not propose any changes to the Java Language Specification.* You said on April 18 that "Changes to the JSR 292 specification to clarify [sic] the Java language changes that support MethodHandle are in process". That process appears not to have occurred, as there are no further public drafts of the jsr292 specification. The jsr336 specification doesn't propose any changes to the Java Language Specification either, other than pointing to other jsrs. jsr901, the language "maintenance" jsr, does specify language changes, but it has no independent approval process. The public review period for its changes coincided with an outage in Oracle's public website for viewing the issues it is alleged to address, which made impossible any practical review of the changes. In any case, jsr901 contains no jsr292-related changes such as polymorphic method signatures. Of course, with no public access to the expert group discussions it is very hard for me to know precisely what it was that was decided in either case. But based on the documents that have been published, jsr336 didn't appear to approve for inclusion into SE 7 any language changes that relate to jsr292. Cheers, Neal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110607/6ad49365/attachment.html From forax at univ-mlv.fr Tue Jun 7 15:17:24 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 08 Jun 2011 00:17:24 +0200 Subject: java 6 compiler bug or ... In-Reply-To: References: <4DECA6EA.2030408@oracle.com> <4DED5B7E.4020001@univ-mlv.fr> Message-ID: <4DEEA374.4010203@univ-mlv.fr> On 06/07/2011 04:02 PM, Neal Gafter wrote: > On Mon, Jun 6, 2011 at 5:41 PM, Dan Smith > wrote: > > As background, this kind of thing comes up all the time in > addressing bug reports. The typical process is: 1) observe a > discrepancy between javac and the JLS, where neither is clearly in > error; 2) try to characterize what javac is actually doing; 3) see > what Eclipse does; 4) Compare the specified and implemented > behavior, and try to find a minimally-invasive way to reconcile them. > > Frequently, the solution is as simple as changing a line in the > JLS. Sometimes, the solution is a source-incompatible > implementation change. There are costs in both directions, and we > try to balance those costs appropriately. Of course this process > is subjective, but it is also reasonably careful, I think. > > I misread Remi's comment about Eclipse, but that observation was > probably influential in this particular case: javac was accepting > programs that both the JLS and Eclipse considered malformed. > > > Having followed this kind of process as maintainer of javac and > contributor to the JLS for some years, I am quite familiar with the > process. In step (2), what javac used to be doing was quite > straightforward (the rule about conflicting methods also takes into > account the erasure of the return type). The backward-compatible and > least-invasive (to the customer) way to fix it is obviously to add a > line in the JLS and relax the Eclipse implementation. I cannot > imagine what considerations would lead to the current result (other > than, perhaps, that the JLS maintainer is too busy to make the > necessary change to the specification). Dan, again, I agree with Neal: - if two erased methods with different return types can create a clash, I need to understand why. (I think it's better to understand JLS rules than memorize them all :) - it's not a source compatible change. So why introducing a source incompatible change that blurs a restriction (name clash) which is easy* to understand. I am interested to have an explanation. R?mi * compared to other rules related to generics. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110608/673eaa15/attachment.html From neal at gafter.com Tue Jun 7 17:38:44 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 7 Jun 2011 17:38:44 -0700 Subject: hg: jdk7/tl/langtools: 2 new changesets In-Reply-To: <20110511111649.BA27B4747D@hg.openjdk.java.net> References: <20110511111649.BA27B4747D@hg.openjdk.java.net> Message-ID: Regarding the fix for "bug" 7041730... I was under the impression that recent changes to the language and compiler were intended to allow assignment conversions as casting conversions too. The conversion from the constant zero (0) to a Byte is among the assignment conversions. Draft SE7 JLS 5.2 (Assignment Conversion) says In addition, if the expression is a constant expression (?15.28) of type ... int ... a narrowing primitive conversion followed by a boxing conversion may be used if the type of the variable is ... Byte and the value of the constant expression is representable in the type byte... And 5.5 (Casting Conversion) says ...casting conversions are more inclusive than assignment or method invocation conversions: a cast can do any permitted conversion other than a string conversion or a capture conversion (?5.1.10). Yet this change claims to "fix" the bug 7041730, which requests that the casting conversion from "0" to "Byte" be illegal; that violates this JLS quote. Cheers, Neal On Wed, May 11, 2011 at 4:16 AM, wrote: > Changeset: 95fc7fd39be2 > Author: mcimadamore > Date: 2011-05-11 13:12 +0200 > URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/95fc7fd39be2 > > 7041730: Regression: compiler accepts invalid cast from int to Byte > Summary: Implementation of cast conversion rules between primitive and > boxed types is too liberal > Reviewed-by: jjg > > ! src/share/classes/com/sun/tools/javac/code/Types.java > ! test/tools/javac/types/BoxingConversionTest.java > ! test/tools/javac/types/CastTest.java > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110607/180fc746/attachment.html From neal at gafter.com Tue Jun 7 17:46:47 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 7 Jun 2011 17:46:47 -0700 Subject: hg: jdk7/tl/langtools: 2 new changesets In-Reply-To: References: <20110511111649.BA27B4747D@hg.openjdk.java.net> Message-ID: One more thing: the casting conversion from "0" to "Byte" is also required to be allowed by the draft JLS by this curious sentence: The compile-time legality of a casting conversion is as follows: ? ... ? An expression of a primitive type can always be [sic] undergo casting conversion to a reference type without error, by boxing conversion. Since 0 is an expression of primitive type and Byte is a reference type, the former can "always" undergo a casting conversion to the latter "without error". On Tue, Jun 7, 2011 at 5:38 PM, Neal Gafter wrote: > Regarding the fix for "bug" 7041730... I was under the impression that > recent changes to the language and compiler were intended to allow > assignment conversions as casting conversions too. The conversion from the > constant zero (0) to a Byte is among the assignment conversions. Draft SE7 > JLS 5.2 (Assignment Conversion) says > > In addition, if the expression is a constant expression (?15.28) of type > ... int ... a narrowing primitive conversion followed by a boxing conversion > may be used if the type of the variable is ... Byte and the value of the > constant expression is representable in the type byte... > > And 5.5 (Casting Conversion) says > > ...casting conversions are more inclusive than assignment or method > invocation conversions: a cast can do any permitted conversion other than a > string conversion or a capture conversion (?5.1.10). > > Yet this change claims to "fix" the bug 7041730, which requests that the > casting conversion from "0" to "Byte" be illegal; that violates this JLS > quote. > > Cheers, > Neal > > > On Wed, May 11, 2011 at 4:16 AM, wrote: > >> Changeset: 95fc7fd39be2 >> Author: mcimadamore >> Date: 2011-05-11 13:12 +0200 >> URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/95fc7fd39be2 >> >> 7041730: Regression: compiler accepts invalid cast from int to Byte >> Summary: Implementation of cast conversion rules between primitive and >> boxed types is too liberal >> Reviewed-by: jjg >> >> ! src/share/classes/com/sun/tools/javac/code/Types.java >> ! test/tools/javac/types/BoxingConversionTest.java >> ! test/tools/javac/types/CastTest.java >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110607/390e6a4c/attachment.html From alex.buckley at oracle.com Tue Jun 7 18:24:12 2011 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 07 Jun 2011 18:24:12 -0700 Subject: hg: jdk7/tl/langtools: 2 new changesets In-Reply-To: References: <20110511111649.BA27B4747D@hg.openjdk.java.net> Message-ID: <4DEECF3C.7040201@oracle.com> Bunch of spec issues here. The text claiming casting conversion is more inclusive than assignment conversion is not new, and is only a discussion note, but I agree it's false - a casting conversion does not allow narrowing-primitive-then-boxing whereas an assignment conversion sometimes does. Rather than complicating the note with if's and but's about the assignment/casting relationship, I will remove the note for JLS7. The compiler was compliant in rejecting (Byte)0 in the past, and it's compliant in rejecting it now. We are aware of improvements possible when casting primitive values, but they will not be specified for SE 7. Regarding the "compile-time legality" clauses, they are a centralization and rewording of existing clauses. I was too strong with "always ... without error", since exceptions may occur as in 5.2. I softened the wording so an expression of primitive type _may_ undergo casting conversion to a reference type without error, by boxing conversion. (These clauses are an example of normative text which should not be tested, since it's an overview of rules elsewhere.) Alex On 6/7/2011 5:46 PM, Neal Gafter wrote: > One more thing: the casting conversion from "0" to "Byte" is also > required to be allowed by the draft JLS by this curious sentence: > > The compile-time legality of a casting conversion is as follows: > ? ... > ? An expression of a primitive type can always be [sic] undergo casting > conversion to a reference type without error, by boxing conversion. > > Since 0 is an expression of primitive type and Byte is a reference type, > the former can "always" undergo a casting conversion to the latter > "without error". > > On Tue, Jun 7, 2011 at 5:38 PM, Neal Gafter > wrote: > > Regarding the fix for "bug" 7041730... I was under the impression > that recent changes to the language and compiler were intended to > allow assignment conversions as casting conversions too. The > conversion from the constant zero (0) to a Byte is among the > assignment conversions. Draft SE7 JLS 5.2 (Assignment Conversion) says > > In addition, if the expression is a constant expression (?15.28) of > type ... int ... a narrowing primitive conversion followed by a > boxing conversion may be used if the type of the variable is ... > Byte and the value of the constant expression is representable in > the type byte... > > And 5.5 (Casting Conversion) says > > ...casting conversions are more inclusive than assignment or method > invocation conversions: a cast can do any permitted conversion other > than a string conversion or a capture conversion (?5.1.10). > > Yet this change claims to "fix" the bug 7041730, which requests that > the casting conversion from "0" to "Byte" be illegal; that violates > this JLS quote. > > Cheers, > Neal > > > On Wed, May 11, 2011 at 4:16 AM, > wrote: > > Changeset: 95fc7fd39be2 > Author: mcimadamore > Date: 2011-05-11 13:12 +0200 > URL: > http://hg.openjdk.java.net/jdk7/tl/langtools/rev/95fc7fd39be2 > > 7041730: Regression: compiler accepts invalid cast from int to Byte > Summary: Implementation of cast conversion rules between > primitive and boxed types is too liberal > Reviewed-by: jjg > > ! src/share/classes/com/sun/tools/javac/code/Types.java > ! test/tools/javac/types/BoxingConversionTest.java > ! test/tools/javac/types/CastTest.java > > > From weijun.wang at oracle.com Tue Jun 7 23:03:56 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 08 Jun 2011 06:03:56 +0000 Subject: hg: jdk8/tl/jdk: 7043737: klist does not detect non-existing keytab Message-ID: <20110608060420.4C85047CBE@hg.openjdk.java.net> Changeset: 9b678733fa51 Author: weijun Date: 2011-06-08 14:01 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b678733fa51 7043737: klist does not detect non-existing keytab Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java + test/sun/security/krb5/tools/ktmissing.sh From michael.x.mcmahon at oracle.com Wed Jun 8 02:58:35 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 08 Jun 2011 09:58:35 +0000 Subject: hg: jdk7/tl/jdk: 7050028: ISE "zip file closed" from JarURLConnection.getInputStream on JDK 7 when !useCaches Message-ID: <20110608095855.20FCB47CCB@hg.openjdk.java.net> Changeset: 6e961c328276 Author: michaelm Date: 2011-06-08 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e961c328276 7050028: ISE "zip file closed" from JarURLConnection.getInputStream on JDK 7 when !useCaches Reviewed-by: chegar, alanb ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B7050028.java From forax at univ-mlv.fr Thu Jun 9 06:51:04 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 09 Jun 2011 15:51:04 +0200 Subject: Fwd: [jvm-l] Newly introduced OpenJDK javac bug? Message-ID: <4DF0CFC8.2030809@univ-mlv.fr> add compiler dev-list to the loop. My analysis is that this is a fix for a previously existing bug, so the behavior of javac is now correct. With method("str", 1), no method are applicable without considering boxing and varargs, so we ends up with phase 3. Here, both boxing and varargs are enabled so the two method are applicable and not one is most specific. So the call is ambiguous. R?mi -------- Original Message -------- Subject: [jvm-l] Newly introduced OpenJDK javac bug? Date: Thu, 9 Jun 2011 08:26:04 -0500 From: Charles Oliver Nutter Reply-To: jvm-languages at googlegroups.com To: JVM Languages CC: Mark Reinhold Recent OpenJDK 7 builds seem to have introduced a bug into javac. Correct me if I'm wrong. https://gist.github.com/1016436 public class Foo { public static void main(String[] args) { method("str"); method("str", 1); method("str", 1, "data"); } public static void method(String str, int num, Object... data) { // do nothing } public static void method(String str, Object... data) { // do nothing } } It seems that the order in which it attempts to apply varargs and boxing has changed. On OpenJDK/Hotspot 1.6.x and OpenJDK 7 builds prior to 143, this compiles fine and calls the first signature for all calls. My interpretation of the Java specification is that this is correct behavior; the more exact signature that requires no boxing is chosen rather than the second signature which does require boxing. However on later builds, we get the following errors for this case: Foo.java:4: error: reference to method is ambiguous, both method method(String,int,Object...) in Foo and method method(String,Object...) in Foo match method("str", 1); ^ Foo.java:5: error: reference to method is ambiguous, both method method(String,int,Object...) in Foo and method method(String,Object...) in Foo match method("str", 1, "data"); Both invocations fall through to phase 3 of method selection, variable arity. But in this case, I believe the first signature (with int) should resolve as "more specific" than the second, and should be chosen for both invocations. I admit it's a grey area, however, and I can't find a specific clause in the Java spec to back me up. I'm not sure who to talk to about this, or whether I'm right in thinking this is a new bug in javac. Thoughts? - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages at googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscribe at googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110609/ced34cb4/attachment.html From maurizio.cimadamore at oracle.com Thu Jun 9 07:24:45 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 09 Jun 2011 15:24:45 +0100 Subject: Fwd: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: <4DF0CFC8.2030809@univ-mlv.fr> References: <4DF0CFC8.2030809@univ-mlv.fr> Message-ID: <4DF0D7AD.80204@oracle.com> Remi, your analysis is correct. Consider the method call: method("str", 1); Now, you have two potentially applicable methods, namely - method(String str, int num, Object... data) - method(String str, Object... data) Since both are varargs method, both methods can only be applicable by variable arity method conversion (see JLS 15.12.2.4). Both methods are applicable (note that the second method is applicable since there exist a method invocation conversion to go from int to Object). Since both are applicable we have now to choose the most specific (see 15.12.2.5) - the rules says that: "In addition, one variable arity member method named m is more specific than another variable arity member method of the same name if either: *) One member method has n parameters and the other has k parameters, where n >= k. The types of the parameters of the first member method are T1, . . . , Tn-1 , Tn[], the types of the parameters of the other method are U1, . . . , Uk-1, Uk[]. [...] otherwise let Si = Ui, 1 < i <=k. Then: - for all j from 1 to k-1, Tj <: Sj, and, - for all j from k to n, Tj <: Sk, and, *) One member method has k parameters and the other has n parameters, where n>=k. The types of the parameters of the first method are U1, . . . , Uk-1, Uk[], the types of the parameters of the other method are T1, . . ., Tn-1, Tn[]. [...] otherwise let Si = Ti, 1 T1 <: S1 ? Yes, because String <: String j = 1 --> T2 <: S2 ? No, because int is not a subtype of Object Which means method(String str, int num, Object... data) is not more specific than method(String str, Object... data). Let's try the other way around. *** Part 2 So, is M1 = method(String str, Object... data) more specific than M2 = method(String str, int i, Object... data) ? Since arity of M1 is smaller than arity of M2, the second bullet apply. More specifically, n is 2, k is 3, U = { String, Object }, S = T = { String, int, Object }. We have to prove that: - for all j from 1 to 2 (as k is 3), Uj <: Sj, and, - for all j from 3 to 3, Uj <: S3, and, Which means: j = 1 --> U1 <: S1 ? Yes, because String <: String j = 1 --> U2 <: S2 ? No, because int is not a subtype of Object Which means method(String str, Object... data) is not more specific than method(String str, int i, Object... data). The conclusion is that neither method is more specific than the other, so the compile-time error is legitimate. Maurizio On 09/06/11 14:51, R?mi Forax wrote: > add compiler dev-list to the loop. > > My analysis is that this is a fix for a previously existing bug, > so the behavior of javac is now correct. > > With method("str", 1), no method are applicable without considering > boxing and varargs, > so we ends up with phase 3. Here, both boxing and varargs are enabled so > the two method are applicable and not one is most specific. > So the call is ambiguous. > > R?mi > > -------- Original Message -------- > Subject: [jvm-l] Newly introduced OpenJDK javac bug? > Date: Thu, 9 Jun 2011 08:26:04 -0500 > From: Charles Oliver Nutter > Reply-To: jvm-languages at googlegroups.com > To: JVM Languages > CC: Mark Reinhold > > > > Recent OpenJDK 7 builds seem to have introduced a bug into javac. > Correct me if I'm wrong. > > https://gist.github.com/1016436 > > public class Foo { > public static void main(String[] args) { > method("str"); > method("str", 1); > method("str", 1, "data"); > } > > public static void method(String str, int num, Object... data) { > // do nothing > } > > public static void method(String str, Object... data) { > // do nothing > } > } > > It seems that the order in which it attempts to apply varargs and > boxing has changed. On OpenJDK/Hotspot 1.6.x and OpenJDK 7 builds > prior to 143, this compiles fine and calls the first signature for all > calls. My interpretation of the Java specification is that this is > correct behavior; the more exact signature that requires no boxing is > chosen rather than the second signature which does require boxing. > > However on later builds, we get the following errors for this case: > > Foo.java:4: error: reference to method is ambiguous, both method > method(String,int,Object...) in Foo and method > method(String,Object...) in Foo match > method("str", 1); > ^ > Foo.java:5: error: reference to method is ambiguous, both method > method(String,int,Object...) in Foo and method > method(String,Object...) in Foo match > method("str", 1, "data"); > > Both invocations fall through to phase 3 of method selection, variable > arity. But in this case, I believe the first signature (with int) > should resolve as "more specific" than the second, and should be > chosen for both invocations. I admit it's a grey area, however, and I > can't find a specific clause in the Java spec to back me up. > > I'm not sure who to talk to about this, or whether I'm right in > thinking this is a new bug in javac. Thoughts? > > - Charlie > > -- > You received this message because you are subscribed to the Google Groups "JVM Languages" group. > To post to this group, send email tojvm-languages at googlegroups.com. > To unsubscribe from this group, send email tojvm-languages+unsubscribe at googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/jvm-languages?hl=en. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110609/4c4490fb/attachment.html From headius at headius.com Thu Jun 9 07:36:14 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 9 Jun 2011 09:36:14 -0500 Subject: Fwd: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: <4DF0D7AD.80204@oracle.com> References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> Message-ID: I accept this analysis as written. I do however have a few questions/comments. * This seems like it only affects cases where you have primitives butting up against a varargs Object..., correct? Only in those cases do you have a method invocation conversion from a type that does not subclass Object. Edge-casey. * It is unexpected, albeit correct according to specification. A few reasons: ** The int => Object conversion is via Integer, which *is* a subtype relationship. I know the spec does not provide for reevaluating specificity after a method invocation conversion...but perhaps it should. ** int *is* more specific than Object from a programmer/development perspective. Another way of looking at specificity would be "fewer combinations of argument types apply". That's clearly the case here. I suspect I won't be the only one to run into this new behavior. As it stands, the methods in question in JRuby no longer need the varargs forms, so I'm removing them. - Charlie On Thu, Jun 9, 2011 at 9:24 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Remi, your analysis is correct. > > Consider the method call: > > method("str", 1); > > Now, you have two potentially applicable methods, namely > > - method(String str, int num, Object... data) > - method(String str, Object... data) > > Since both are varargs method, both methods can only be applicable by > variable arity method conversion (see JLS 15.12.2.4). Both methods are > applicable (note that the second method is applicable since there exist a > method invocation conversion to go from int to Object). > > Since both are applicable we have now to choose the most specific (see > 15.12.2.5) - the rules says that: > > "In addition, one variable arity member method named m is more specific > than another variable arity member method of the same name if either: > > *) One member method has n parameters and the other has k parameters, where > n >= k. The types of the parameters of the first member method are T1, . . . > , Tn-1 , Tn[], the types of the parameters of the other method are U1, . . . > , Uk-1, Uk[]. [...] otherwise let Si = Ui, 1 < i <=k. Then: > > - for all j from 1 to k-1, Tj <: Sj, and, > - for all j from k to n, Tj <: Sk, and, > > *) One member method has k parameters and the other has n parameters, where > n>=k. The types of the parameters of the first method are U1, . . . , Uk-1, > Uk[], the types of the parameters of the other method are T1, . . ., Tn-1, > Tn[]. [...] otherwise let Si = Ti, 1 > - for all j from 1 to k-1 , Uj <: Sj, and, > - for all j from k to n , Uk <: Sj, and," > > *** Part 1 > > So, is M1 = method(String str, int num, Object... data) more specific than > M2 = method(String str, Object... data) ? Since arity of M1 is bigger than > arity of M2, the first bullet apply. More specifically, n is 3, k is 2, T = > { String, int, Object }, while S = U = { String, Object }. We have to prove > that: > > - for all j from 1 to 1 (as k is 2), Tj <: Sj, and, > - for all j from 2 to 3, Tj <: S2, and, > > Which means: > > j = 1 --> T1 <: S1 ? Yes, because String <: String > j = 1 --> T2 <: S2 ? No, because int is not a subtype of Object > > Which means method(String str, int num, Object... data) is not more > specific than method(String str, Object... data). Let's try the other way > around. > > *** Part 2 > > So, is M1 = method(String str, Object... data) more specific than M2 = > method(String str, int i, Object... data) ? Since arity of M1 is smaller > than arity of M2, the second bullet apply. More specifically, n is 2, k is > 3, U = { String, Object }, S = T = { String, int, Object }. We have to prove > that: > > - for all j from 1 to 2 (as k is 3), Uj <: Sj, and, > - for all j from 3 to 3, Uj <: S3, and, > > Which means: > > j = 1 --> U1 <: S1 ? Yes, because String <: String > j = 1 --> U2 <: S2 ? No, because int is not a subtype of Object > > Which means method(String str, Object... data) is not more specific than > method(String str, int i, Object... data). The conclusion is that neither > method is more specific than the other, so the compile-time error is > legitimate. > > Maurizio > > > > > On 09/06/11 14:51, R?mi Forax wrote: > > add compiler dev-list to the loop. > > My analysis is that this is a fix for a previously existing bug, > so the behavior of javac is now correct. > > With method("str", 1), no method are applicable without considering boxing > and varargs, > so we ends up with phase 3. Here, both boxing and varargs are enabled so > the two method are applicable and not one is most specific. > So the call is ambiguous. > > R?mi > > -------- Original Message -------- Subject: [jvm-l] Newly introduced > OpenJDK javac bug? Date: Thu, 9 Jun 2011 08:26:04 -0500 From: Charles > Oliver Nutter Reply-To: > jvm-languages at googlegroups.com To: JVM Languages > CC: Mark > Reinhold > > Recent OpenJDK 7 builds seem to have introduced a bug into javac. > Correct me if I'm wrong. > https://gist.github.com/1016436 > > public class Foo { > public static void main(String[] args) { > method("str"); > method("str", 1); > method("str", 1, "data"); > } > > public static void method(String str, int num, Object... data) { > // do nothing > } > > public static void method(String str, Object... data) { > // do nothing > } > } > > It seems that the order in which it attempts to apply varargs and > boxing has changed. On OpenJDK/Hotspot 1.6.x and OpenJDK 7 builds > prior to 143, this compiles fine and calls the first signature for all > calls. My interpretation of the Java specification is that this is > correct behavior; the more exact signature that requires no boxing is > chosen rather than the second signature which does require boxing. > > However on later builds, we get the following errors for this case: > > Foo.java:4: error: reference to method is ambiguous, both method > method(String,int,Object...) in Foo and method > method(String,Object...) in Foo match > method("str", 1); > ^ > Foo.java:5: error: reference to method is ambiguous, both method > method(String,int,Object...) in Foo and method > method(String,Object...) in Foo match > method("str", 1, "data"); > > Both invocations fall through to phase 3 of method selection, variable > arity. But in this case, I believe the first signature (with int) > should resolve as "more specific" than the second, and should be > chosen for both invocations. I admit it's a grey area, however, and I > can't find a specific clause in the Java spec to back me up. > > I'm not sure who to talk to about this, or whether I'm right in > thinking this is a new bug in javac. Thoughts? > > - Charlie > > -- > You received this message because you are subscribed to the Google Groups "JVM Languages" group. > To post to this group, send email to jvm-languages at googlegroups.com. > To unsubscribe from this group, send email to jvm-languages+unsubscribe at googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110609/923ffa2c/attachment.html From forax at univ-mlv.fr Thu Jun 9 08:23:13 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 09 Jun 2011 17:23:13 +0200 Subject: Fwd: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> Message-ID: <4DF0E561.6000307@univ-mlv.fr> On 06/09/2011 04:36 PM, Charles Oliver Nutter wrote: > I accept this analysis as written. I do however have a few > questions/comments. > > * This seems like it only affects cases where you have primitives > butting up against a varargs Object..., correct? Only in those cases > do you have a method invocation conversion from a type that does not > subclass Object. Edge-casey. > > * It is unexpected, albeit correct according to specification. A few > reasons: > > ** The int => Object conversion is via Integer, which *is* a subtype > relationship. I know the spec does not provide for reevaluating > specificity after a method invocation conversion...but perhaps it should. int => Object is a not a subtyping conversion, remember that subtype as defined by Liskov is a relation between objects. int is not an object type in Java. > > ** int *is* more specific than Object from a programmer/development > perspective. Another way of looking at specificity would be "fewer > combinations of argument types apply". That's clearly the case here. more specific means is the a most specific subtype, so int is not more specific than Object here because there is not subtype/supertype relation between int and Object in Java. > > I suspect I won't be the only one to run into this new behavior. As it > stands, the methods in question in JRuby no longer need the varargs > forms, so I'm removing them. > > - Charlie cheers, R?mi From forax at univ-mlv.fr Thu Jun 9 08:26:02 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 09 Jun 2011 17:26:02 +0200 Subject: Fwd: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> Message-ID: <4DF0E60A.6080301@univ-mlv.fr> On 06/09/2011 04:52 PM, Robert Fischer wrote: > I've been using precisely the pattern that Charlie lays out in some of > my code, as well, so I'm going to have to code around it now. I didn't > realize that it was technically ambiguous ? it's really surprising to > my intuition, which (I'm now realizing as I think about it) tries to > match arguments left to right, and only drops to varargs if it can't > find a match. That intuition is obviously wrong compared to the spec, > but does that mean we have a bug in the spec? What's the justification > for this behavior? > > For the record, both Scala and Groovy resolve methods more in line > with intuition: > Groovy > https://gist.github.com/1016878 > Scala > https://gist.github.com/1016880 > Yes, because either in Scala or in Groovy int is a subtype of Object. There is no point to make a difference between int and Integer in a dynamic language. > ~~ Robert. R?mi From maurizio.cimadamore at oracle.com Thu Jun 9 08:30:28 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 09 Jun 2011 16:30:28 +0100 Subject: Fwd: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> Message-ID: <4DF0E714.2080107@oracle.com> On 09/06/11 15:52, Robert Fischer wrote: > I've been using precisely the pattern that Charlie lays out in some of > my code, as well, so I'm going to have to code around it now. I didn't > realize that it was technically ambiguous ? it's really surprising to > my intuition, which (I'm now realizing as I think about it) tries to > match arguments left to right, and only drops to varargs if it can't > find a match. That intuition is obviously wrong compared to the spec, > but does that mean we have a bug in the spec? What's the justification > for this behavior? This seems to be an area where things can be improved. Note that the JDK 7 algorithm has been brought in sync with the spec because we had other bugs in which the compiler was issuing bad error messages (esp. with varargs with primitive types, see [1] and related issues). [1] - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6199075 Maurizio > > For the record, both Scala and Groovy resolve methods more in line > with intuition: > Groovy > https://gist.github.com/1016878 > Scala > https://gist.github.com/1016880 > > ~~ Robert. > > On Thu, Jun 9, 2011 at 10:36 AM, Charles Oliver Nutter > > wrote: > > I accept this analysis as written. I do however have a few > questions/comments. > > * This seems like it only affects cases where you have primitives > butting up against a varargs Object..., correct? Only in those > cases do you have a method invocation conversion from a type that > does not subclass Object. Edge-casey. > > * It is unexpected, albeit correct according to specification. A > few reasons: > > ** The int => Object conversion is via Integer, which *is* a > subtype relationship. I know the spec does not provide for > reevaluating specificity after a method invocation > conversion...but perhaps it should. > > ** int *is* more specific than Object from a > programmer/development perspective. Another way of looking at > specificity would be "fewer combinations of argument types apply". > That's clearly the case here. > > I suspect I won't be the only one to run into this new behavior. > As it stands, the methods in question in JRuby no longer need the > varargs forms, so I'm removing them. > > - Charlie > > On Thu, Jun 9, 2011 at 9:24 AM, Maurizio Cimadamore > > wrote: > > Remi, your analysis is correct. > > Consider the method call: > > method("str", 1); > > Now, you have two potentially applicable methods, namely > > - method(String str, int num, Object... data) > - method(String str, Object... data) > > Since both are varargs method, both methods can only be > applicable by variable arity method conversion (see JLS > 15.12.2.4). Both methods are applicable (note that the second > method is applicable since there exist a method invocation > conversion to go from int to Object). > > Since both are applicable we have now to choose the most > specific (see 15.12.2.5) - the rules says that: > > "In addition, one variable arity member method named m is more > specific than another variable arity member method of the same > name if either: > > *) One member method has n parameters and the other has k > parameters, where n >= k. The types of the parameters of the > first member method are T1, . . . , Tn-1 , Tn[], the types of > the parameters of the other method are U1, . . . , Uk-1, Uk[]. > [...] otherwise let Si = Ui, 1 < i <=k. Then: > > - for all j from 1 to k-1, Tj <: Sj, and, > - for all j from k to n, Tj <: Sk, and, > > *) One member method has k parameters and the other has n > parameters, where n>=k. The types of the parameters of the > first method are U1, . . . , Uk-1, Uk[], the types of the > parameters of the other method are T1, . . ., Tn-1, Tn[]. > [...] otherwise let Si = Ti, 1 > - for all j from 1 to k-1 , Uj <: Sj, and, > - for all j from k to n , Uk <: Sj, and," > > *** Part 1 > > So, is M1 = method(String str, int num, Object... data) more > specific than M2 = method(String str, Object... data) ? Since > arity of M1 is bigger than arity of M2, the first bullet > apply. More specifically, n is 3, k is 2, T = { String, int, > Object }, while S = U = { String, Object }. We have to prove that: > > - for all j from 1 to 1 (as k is 2), Tj <: Sj, and, > - for all j from 2 to 3, Tj <: S2, and, > > Which means: > > j = 1 --> T1 <: S1 ? Yes, because String <: String > j = 1 --> T2 <: S2 ? No, because int is not a subtype of Object > > Which means method(String str, int num, Object... data) is not > more specific than method(String str, Object... data). Let's > try the other way around. > > *** Part 2 > > So, is M1 = method(String str, Object... data) more specific > than M2 = method(String str, int i, Object... data) ? Since > arity of M1 is smaller than arity of M2, the second bullet > apply. More specifically, n is 2, k is 3, U = { String, Object > }, S = T = { String, int, Object }. We have to prove that: > > - for all j from 1 to 2 (as k is 3), Uj <: Sj, and, > - for all j from 3 to 3, Uj <: S3, and, > > Which means: > > j = 1 --> U1 <: S1 ? Yes, because String <: String > j = 1 --> U2 <: S2 ? No, because int is not a subtype of Object > > Which means method(String str, Object... data) is not more > specific than method(String str, int i, Object... data). The > conclusion is that neither method is more specific than the > other, so the compile-time error is legitimate. > > Maurizio > > > > > On 09/06/11 14:51, R?mi Forax wrote: >> add compiler dev-list to the loop. >> >> My analysis is that this is a fix for a previously existing bug, >> so the behavior of javac is now correct. >> >> With method("str", 1), no method are applicable without >> considering boxing and varargs, >> so we ends up with phase 3. Here, both boxing and varargs are >> enabled so >> the two method are applicable and not one is most specific. >> So the call is ambiguous. >> >> R?mi >> >> -------- Original Message -------- >> Subject: [jvm-l] Newly introduced OpenJDK javac bug? >> Date: Thu, 9 Jun 2011 08:26:04 -0500 >> From: Charles Oliver Nutter >> >> Reply-To: jvm-languages at googlegroups.com >> >> To: JVM Languages >> >> CC: Mark Reinhold >> >> >> >> >> Recent OpenJDK 7 builds seem to have introduced a bug into javac. >> Correct me if I'm wrong. >> >> https://gist.github.com/1016436 >> >> public class Foo { >> public static void main(String[] args) { >> method("str"); >> method("str", 1); >> method("str", 1, "data"); >> } >> >> public static void method(String str, int num, Object... data) { >> // do nothing >> } >> >> public static void method(String str, Object... data) { >> // do nothing >> } >> } >> >> It seems that the order in which it attempts to apply varargs and >> boxing has changed. On OpenJDK/Hotspot 1.6.x and OpenJDK 7 builds >> prior to 143, this compiles fine and calls the first signature for all >> calls. My interpretation of the Java specification is that this is >> correct behavior; the more exact signature that requires no boxing is >> chosen rather than the second signature which does require boxing. >> >> However on later builds, we get the following errors for this case: >> >> Foo.java:4: error: reference to method is ambiguous, both method >> method(String,int,Object...) in Foo and method >> method(String,Object...) in Foo match >> method("str", 1); >> ^ >> Foo.java:5: error: reference to method is ambiguous, both method >> method(String,int,Object...) in Foo and method >> method(String,Object...) in Foo match >> method("str", 1, "data"); >> >> Both invocations fall through to phase 3 of method selection, variable >> arity. But in this case, I believe the first signature (with int) >> should resolve as "more specific" than the second, and should be >> chosen for both invocations. I admit it's a grey area, however, and I >> can't find a specific clause in the Java spec to back me up. >> >> I'm not sure who to talk to about this, or whether I'm right in >> thinking this is a new bug in javac. Thoughts? >> >> - Charlie >> >> -- >> You received this message because you are subscribed to the Google Groups "JVM Languages" group. >> To post to this group, send email tojvm-languages at googlegroups.com . >> To unsubscribe from this group, send email tojvm-languages+unsubscribe at googlegroups.com . >> For more options, visit this group athttp://groups.google.com/group/jvm-languages?hl=en. >> > > > -- > You received this message because you are subscribed to the Google > Groups "JVM Languages" group. > To post to this group, send email to > jvm-languages at googlegroups.com > . > To unsubscribe from this group, send email to > jvm-languages+unsubscribe at googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110609/82caf335/attachment.html From neal at gafter.com Thu Jun 9 08:41:58 2011 From: neal at gafter.com (Neal Gafter) Date: Thu, 9 Jun 2011 08:41:58 -0700 Subject: hg: jdk7/tl/langtools: 2 new changesets In-Reply-To: <4DEECF3C.7040201@oracle.com> References: <20110511111649.BA27B4747D@hg.openjdk.java.net> <4DEECF3C.7040201@oracle.com> Message-ID: Alex- Thanks! Cheers, Neal On Tue, Jun 7, 2011 at 6:24 PM, Alex Buckley wrote: > Bunch of spec issues here. > > The text claiming casting conversion is more inclusive than assignment > conversion is not new, and is only a discussion note, but I agree it's false > - a casting conversion does not allow narrowing-primitive-then-boxing > whereas an assignment conversion sometimes does. > > Rather than complicating the note with if's and but's about the > assignment/casting relationship, I will remove the note for JLS7. > > The compiler was compliant in rejecting (Byte)0 in the past, and it's > compliant in rejecting it now. We are aware of improvements possible when > casting primitive values, but they will not be specified for SE 7. > > Regarding the "compile-time legality" clauses, they are a centralization > and rewording of existing clauses. I was too strong with "always ... without > error", since exceptions may occur as in 5.2. I softened the wording so an > expression of primitive type _may_ undergo casting conversion to a reference > type without error, by boxing conversion. (These clauses are an example of > normative text which should not be tested, since it's an overview of rules > elsewhere.) > > Alex > > > On 6/7/2011 5:46 PM, Neal Gafter wrote: > >> One more thing: the casting conversion from "0" to "Byte" is also required >> to be allowed by the draft JLS by this curious sentence: >> >> The compile-time legality of a casting conversion is as follows: >> ? ... >> ? An expression of a primitive type can always be [sic] undergo casting >> conversion to a reference type without error, by boxing conversion. >> >> Since 0 is an expression of primitive type and Byte is a reference type, >> the former can "always" undergo a casting conversion to the latter "without >> error". >> >> On Tue, Jun 7, 2011 at 5:38 PM, Neal Gafter > neal at gafter.com>> wrote: >> >> Regarding the fix for "bug" 7041730... I was under the impression >> that recent changes to the language and compiler were intended to >> allow assignment conversions as casting conversions too. The >> conversion from the constant zero (0) to a Byte is among the >> assignment conversions. Draft SE7 JLS 5.2 (Assignment Conversion) says >> >> In addition, if the expression is a constant expression (?15.28) of >> type ... int ... a narrowing primitive conversion followed by a >> boxing conversion may be used if the type of the variable is ... >> Byte and the value of the constant expression is representable in >> the type byte... >> >> And 5.5 (Casting Conversion) says >> >> ...casting conversions are more inclusive than assignment or method >> invocation conversions: a cast can do any permitted conversion other >> than a string conversion or a capture conversion (?5.1.10). >> >> Yet this change claims to "fix" the bug 7041730, which requests that >> the casting conversion from "0" to "Byte" be illegal; that violates >> this JLS quote. >> >> Cheers, >> Neal >> >> >> On Wed, May 11, 2011 at 4:16 AM, > > wrote: >> >> Changeset: 95fc7fd39be2 >> Author: mcimadamore >> Date: 2011-05-11 13:12 +0200 >> URL: >> http://hg.openjdk.java.net/jdk7/tl/langtools/rev/95fc7fd39be2 >> >> 7041730: Regression: compiler accepts invalid cast from int to Byte >> Summary: Implementation of cast conversion rules between >> primitive and boxed types is too liberal >> Reviewed-by: jjg >> >> ! src/share/classes/com/sun/tools/javac/code/Types.java >> ! test/tools/javac/types/BoxingConversionTest.java >> ! test/tools/javac/types/CastTest.java >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110609/c4b2e822/attachment.html From Ulf.Zibis at gmx.de Thu Jun 9 10:17:24 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 09 Jun 2011 19:17:24 +0200 Subject: Fwd: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: <4DF0E60A.6080301@univ-mlv.fr> References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> <4DF0E60A.6080301@univ-mlv.fr> Message-ID: <4DF10024.3030503@gmx.de> Am 09.06.2011 17:26, schrieb R?mi Forax: > On 06/09/2011 04:52 PM, Robert Fischer wrote: >> I've been using precisely the pattern that Charlie lays out in some of my code, as well, so I'm >> going to have to code around it now. I didn't realize that it was technically ambiguous ? it's >> really surprising to my intuition, which (I'm now realizing as I think about it) tries to match >> arguments left to right, and only drops to varargs if it can't find a match. That intuition is >> obviously wrong compared to the spec, but does that mean we have a bug in the spec? What's the >> justification for this behavior? >> >> For the record, both Scala and Groovy resolve methods more in line with intuition: >> Groovy > https://gist.github.com/1016878 >> Scala > https://gist.github.com/1016880 >> > > Yes, because either in Scala or in Groovy int is a subtype of Object. > There is no point to make a difference between int and Integer in a dynamic language. I think, C++ would be the more appropriate language to compare here. Does anybody here know, how C++ would solve this problem? what's about: method("str", new Integer(1)); Because Integer can be unboxed to int, there should be an ambiguity too according given rules, which feels more weird to me. The only cases, which are not ambiguous here, seem to be: method("str", true); method("str", 1.0); method("str", 1L); So allowing the coexistence of those 2 signatures would seem weird too. IMO, not (un)boxed matches should be valued as "more specific"! -Ulf From daniel.smith at oracle.com Thu Jun 9 12:07:33 2011 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 9 Jun 2011 12:07:33 -0700 Subject: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: <4DF10024.3030503@gmx.de> References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> <4DF0E60A.6080301@univ-mlv.fr> <4DF10024.3030503@gmx.de> Message-ID: <713D9524-A62C-48C5-8C70-AC130A60D0EC@oracle.com> On Jun 9, 2011, at 10:17 AM, Ulf Zibis wrote: > Am 09.06.2011 17:26, schrieb R?mi Forax: >> On 06/09/2011 04:52 PM, Robert Fischer wrote: >>> I've been using precisely the pattern that Charlie lays out in some of my code, as well, so I'm going to have to code around it now. I didn't realize that it was technically ambiguous ? it's really surprising to my intuition, which (I'm now realizing as I think about it) tries to match arguments left to right, and only drops to varargs if it can't find a match. That intuition is obviously wrong compared to the spec, but does that mean we have a bug in the spec? What's the justification for this behavior? >>> >>> For the record, both Scala and Groovy resolve methods more in line with intuition: >>> Groovy > https://gist.github.com/1016878 >>> Scala > https://gist.github.com/1016880 >>> >> >> Yes, because either in Scala or in Groovy int is a subtype of Object. >> There is no point to make a difference between int and Integer in a dynamic language. > > I think, C++ would be the more appropriate language to compare here. Does anybody here know, how C++ would solve this problem? > > what's about: > method("str", new Integer(1)); > Because Integer can be unboxed to int, there should be an ambiguity too according given rules, which feels more weird to me. > > The only cases, which are not ambiguous here, seem to be: > method("str", true); > method("str", 1.0); > method("str", 1L); > So allowing the coexistence of those 2 signatures would seem weird too. > > IMO, not (un)boxed matches should be valued as "more specific"! "more specific" is a relation among method signatures, so it would not be easy to adjust its definition in this way. The process has two steps: 1) find applicable methods, using the argument types; 2) choose the most specific method, ignoring the argument types. Seems like the right way to express what you're after within the current framework is to have a fourth applicability phase: 1) Applicable by subtyping 2) Applicable by method invocation *3) Applicable by subtyping with varargs* 4) Applicable by method invocation with varargs This would also address the original concern, although I think people might debate whether it's the correct behavior for: void method(String s, int n, Object... os); void method(String s, Object... os); method("abc", new Integer(3)); ?Dan From headius at headius.com Thu Jun 9 12:26:48 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 9 Jun 2011 14:26:48 -0500 Subject: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: <713D9524-A62C-48C5-8C70-AC130A60D0EC@oracle.com> References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> <4DF0E60A.6080301@univ-mlv.fr> <4DF10024.3030503@gmx.de> <713D9524-A62C-48C5-8C70-AC130A60D0EC@oracle.com> Message-ID: Yay cross-posting. I include the content of my post to jvm-l here for compiler-dev to muse upon: On Thu, Jun 9, 2011 at 1:11 PM, Attila Szegedi wrote: > The question however is whether these solutions we perceive as intuitive can indeed be formally valid under some set of consistent rules, without running into a contradiction. In answer to you and Neal, it seems there's a simple way to improve the spec to provide the "intuitive" result (or at least the result most people here seem to find intuitive: treat primitives as more specific than Object (and potentially over boxed numeric types as well). My (mis)interpretation of the Java spec for Mirah's compiler works this way currently; primitives are given priority over reference types unconditionally, since the alternative *requires* a boxing conversion. If you have to walk through a conversion to get there, you're walking into a less-specific signature. Walking back through phase 3 and specificity (and I apologize for the informality of this..I'm not a spec writer): Given: void foo(String, int, Object...) void foo(String, Object...) foo("bar", 1) or foo("bar", 1, "baz") * phase three is selected because only varargs can apply * the second signature is only valid for the given arguments with a method invocation conversion of int => Integer * Integer is a subclass of Object, so we arrive at the ambiguity from before * ...BUT...primitive is always more specific than reference, and so the int method is chosen I know many folks hate the special treatment of primitives in Java, but this sort of exception is nothing new. Yes, primitives and reference types live in different worlds and do not share a hierarchy. I would argue that their disjointedness explicitly makes the strict subtype specificity check invalid; subtyping has no meaning to primitives, so you're measuring specificity of an int parameter with an invalid metric. It would be like measuring the specificity of Integer versus Long based on their bit sizes and bit-level widening conversions. Since that doesn't make sense, neither does forcing subtype-driven specificity constraints on primitive types. - Charlie On Thu, Jun 9, 2011 at 2:07 PM, Dan Smith wrote: > On Jun 9, 2011, at 10:17 AM, Ulf Zibis wrote: > >> Am 09.06.2011 17:26, schrieb R?mi Forax: >>> On 06/09/2011 04:52 PM, Robert Fischer wrote: >>>> I've been using precisely the pattern that Charlie lays out in some of my code, as well, so I'm going to have to code around it now. I didn't realize that it was technically ambiguous ? it's really surprising to my intuition, which (I'm now realizing as I think about it) tries to match arguments left to right, and only drops to varargs if it can't find a match. That intuition is obviously wrong compared to the spec, but does that mean we have a bug in the spec? What's the justification for this behavior? >>>> >>>> For the record, both Scala and Groovy resolve methods more in line with intuition: >>>> Groovy > https://gist.github.com/1016878 >>>> Scala > https://gist.github.com/1016880 >>>> >>> >>> Yes, because either in Scala or in Groovy int is a subtype of Object. >>> There is no point to make a difference between int and Integer in a dynamic language. >> >> I think, C++ would be the more appropriate language to compare here. Does anybody here know, how C++ would solve this problem? >> >> what's about: >> ? ?method("str", new Integer(1)); >> Because Integer can be unboxed to int, there should be an ambiguity too according given rules, which feels more weird to me. >> >> The only cases, which are not ambiguous here, seem to be: >> ? ?method("str", true); >> ? ?method("str", 1.0); >> ? ?method("str", 1L); >> So allowing the coexistence of those 2 signatures would seem weird too. >> >> IMO, not (un)boxed matches should be valued as "more specific"! > > "more specific" is a relation among method signatures, so it would not be easy to adjust its definition in this way. > > The process has two steps: 1) find applicable methods, using the argument types; 2) choose the most specific method, ignoring the argument types. ?Seems like the right way to express what you're after within the current framework is to have a fourth applicability phase: > > 1) Applicable by subtyping > 2) Applicable by method invocation > *3) Applicable by subtyping with varargs* > 4) Applicable by method invocation with varargs > > This would also address the original concern, although I think people might debate whether it's the correct behavior for: > > void method(String s, int n, Object... os); > void method(String s, Object... os); > method("abc", new Integer(3)); > > ?Dan > > From jim.holmlund at sun.com Thu Jun 9 15:27:51 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Thu, 09 Jun 2011 22:27:51 +0000 Subject: hg: jdk7/tl/langtools: 7052782: Two langtools regression tests fail due to fix for 7034977 which removed the invokeGeneric method Message-ID: <20110609222758.066F447DE6@hg.openjdk.java.net> Changeset: 347349c981f2 Author: jjh Date: 2011-06-09 09:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/347349c981f2 7052782: Two langtools regression tests fail due to fix for 7034977 which removed the invokeGeneric method Summary: Change the tests to call invoke instead of invokeGeneric Reviewed-by: jrose, mcimadamore ! test/tools/javac/meth/InvokeMH.java ! test/tools/javac/meth/XlintWarn.java From headius at headius.com Fri Jun 10 08:20:57 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 10 Jun 2011 10:20:57 -0500 Subject: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> <65B8CD06-AF12-4A65-B91B-511493460A40@gmail.com> <4DF0DE6A.50605@univ-mlv.fr> <1882FC81-6166-4B41-A851-AFA99D33DA3D@gmail.com> <4DF14561.2050204@univ-mlv.fr> Message-ID: Re-posting this back to compiler-dev to see if there's any chance of fixing this before Java 7 (assuming the answer is "no"). See my analysis below Neal's response. Even if it's impossible to get in, I'd like to play with the idea a bit and see if it feels like a correct change for some time in the future. - Charlie On Fri, Jun 10, 2011 at 10:01 AM, Neal Gafter wrote: > Charles- > > This makes a lot of sense.? My concern is that such a change may break an > unknown number of other, different examples. > > Rather than trying to construct an overload resolution algorithm that makes > this example work as expected, I think the right solution would be to > characterize what javac used to do.? If that characterization is as > straightforward as the current specification, then the spec (rather than the > compiler) ought to be adjusted. > > However, unless someone at Oracle does this quite soon, I fear it is a lost > cause, as SE 7 is about to be unleashed. > > Cheers, > Neal > > On Thu, Jun 9, 2011 at 9:49 PM, Charles Oliver Nutter > wrote: >> >> It would probably help to spell out the paths through specificity >> separately, rather than have everyone try to parse the rules, but it >> seems that Integer fits the subclass match *without* a method >> invocation conversion, and therefore Object is a better fit. As I said >> previously, a match via conversion should be considered of lower >> desirability than a match that does not require conversion. That makes >> both cases work. >> >> * primitive => primitive outweighs primitive => reference because a >> conversion is required (int => int preferred over int => Object or int >> => Integer) >> * boxed => object outweighs boxed => primitive because a conversion is >> required (Integer => Object or Integer => Integer preferred over >> Integer => int) >> >> For my benefit and the benefit of others, let me try to spell it out. >> >> What you're saying by "the input doesn't matter" is that the >> specificity tests are done independent of the actual incoming argument >> types. A set of matching methods is found based on the incoming types, >> and then that pool of methods enters the octagon with hopefully only >> one "most specific" winner emerging. That's true. However, going back >> to my earlier email, specificity is currently based subclass >> relationships. Subclass relationships do not make sense in the context >> of primitives, so we're using subclass specificity tests to choose a >> method for an incoming argument type that doesn't subclass and doesn't >> even live in the type hierarchy we're using to determine specificity. >> >> And if I continue from that understanding, what you mean by "int can't >> be both more and less specific than Integer" is that without knowledge >> of the actual incoming types, you can't make a rule whether to use the >> int signature or the Integer signature in a way consistent with how we >> want both int and Integer inputs to work. If you say int > Integer so >> that int inputs choose int signatures, then you can't get to say >> Integer > int when a later Integer call should call the Integer >> signature. >> >> I think Dan Smith has it right when he said we need to insert a phase: >> >> 1) Applicable by subtyping >> 2) Applicable by method invocation >> *3) Applicable by subtyping with varargs* >> 4) Applicable by method invocation with varargs >> >> This allows my original example to resolve the way most here think it >> should. It also allows Integer to go to Object as appropriate. It's >> not perfect though. >> >> Original example >> >> void method(String s, int n, Object... os); >> void method(String s, Object... os); >> method("abc", 3); >> >> Resolves to the int, Object... signature as expected. But Dan pointed >> out that the same example with Integer would behave differently. >> >> void method(String s, int n, Object... os); >> void method(String s, Object... os); >> method("abc", new Integer(3)); >> >> Currently this is ambiguous since we go immediately to resolution >> using conversion *and* varargs. Both int, Object... and Object... >> signatures enter the octagon. Under the new four-phase mechanism, it >> would resolve to the Object... signature because subtyping + varargs >> takes precedence over conversion + varargs, resulting in the Object... >> signature entering the octagon at the new phase three. >> >> This is a change, but it's more consistent with the first two >> phases...and of course since it was ambiguous before, no code like >> this exists in the wild. Given another example that does not hit >> varargs: >> >> void method(String s, int n); >> void method(String s, Object os); >> method("abc", new Integer(3)); >> >> Obviously the Object signature is chosen for exactly the same reason: >> subclassing rules over conversion. And people expect this. So rather >> than making selection inconsistent, it actually makes the varargs >> phases more consistent with the non-varargs phases. >> >> Why shouldn't varargs phase(s) obey the same precedence of subclassing >> over conversion? >> >> - Charlie >> >> On Thu, Jun 9, 2011 at 5:44 PM, Neal Gafter wrote: >> > The input doesn't matter to Java's "more specific" test. >> > >> > What if the input is Integer and the choices are int and Object.? Do you >> > really prefer the NullPointerException-causing unboxing conversion to >> > the >> > safe widening reference conversion? >> > >> > On Thu, Jun 9, 2011 at 3:30 PM, Charles Oliver Nutter >> > >> > wrote: >> >> >> >> On Thu, Jun 9, 2011 at 5:12 PM, R?mi Forax wrote: >> >> > You can, just consider int and Integer has the same node: >> >> > ? int <= Integer && int >= Integer because int == Integer >> >> >> >> In addition, I don't see how Integer would ever need to be considered >> >> more specific than int, for an int input. In what case does that >> >> happen? >> >> >> >> - Charlie >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "JVM Languages" group. >> >> To post to this group, send email to jvm-languages at googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> jvm-languages+unsubscribe at googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/jvm-languages?hl=en. >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "JVM Languages" group. >> > To post to this group, send email to jvm-languages at googlegroups.com. >> > To unsubscribe from this group, send email to >> > jvm-languages+unsubscribe at googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/jvm-languages?hl=en. >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "JVM Languages" group. >> To post to this group, send email to jvm-languages at googlegroups.com. >> To unsubscribe from this group, send email to >> jvm-languages+unsubscribe at googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jvm-languages?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to jvm-languages at googlegroups.com. > To unsubscribe from this group, send email to > jvm-languages+unsubscribe at googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > From maurizio.cimadamore at oracle.com Fri Jun 10 08:54:16 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 10 Jun 2011 16:54:16 +0100 Subject: [jvm-l] Newly introduced OpenJDK javac bug? In-Reply-To: References: <4DF0CFC8.2030809@univ-mlv.fr> <4DF0D7AD.80204@oracle.com> <65B8CD06-AF12-4A65-B91B-511493460A40@gmail.com> <4DF0DE6A.50605@univ-mlv.fr> <1882FC81-6166-4B41-A851-AFA99D33DA3D@gmail.com> <4DF14561.2050204@univ-mlv.fr> Message-ID: <4DF23E28.2030702@oracle.com> Hi Charles, we're definitively out of time to be playing with overload resolution at this stage. Note that the old javac algorithm for most specific was working 'by accident' - moreover, when performing the most specific check, javac ended up comparing the underlying method signatures with the varargs parameter turned into an array, thus leading to even more confusion. All this to say that changing the spec to match the old javac behavior is out of question. Going forward, we might have room to revise the most specific varargs algorithm as currently specified, so that it will give an answer that might be more intuitive for developers. In my opinion, the root of all the problems is the fact that the most specific algorithm for varargs invocation uses straight subtyping checks (<:) instead of method conversion checks. This point-wise change would enable javac to accept example like yours (but we should check with our spec gurus ;-) ). Maurizio On 10/06/11 16:20, Charles Oliver Nutter wrote: > Re-posting this back to compiler-dev to see if there's any chance of > fixing this before Java 7 (assuming the answer is "no"). See my > analysis below Neal's response. Even if it's impossible to get in, I'd > like to play with the idea a bit and see if it feels like a correct > change for some time in the future. > > - Charlie > > On Fri, Jun 10, 2011 at 10:01 AM, Neal Gafter wrote: >> Charles- >> >> This makes a lot of sense. My concern is that such a change may break an >> unknown number of other, different examples. >> >> Rather than trying to construct an overload resolution algorithm that makes >> this example work as expected, I think the right solution would be to >> characterize what javac used to do. If that characterization is as >> straightforward as the current specification, then the spec (rather than the >> compiler) ought to be adjusted. >> >> However, unless someone at Oracle does this quite soon, I fear it is a lost >> cause, as SE 7 is about to be unleashed. >> >> Cheers, >> Neal >> >> On Thu, Jun 9, 2011 at 9:49 PM, Charles Oliver Nutter >> wrote: >>> It would probably help to spell out the paths through specificity >>> separately, rather than have everyone try to parse the rules, but it >>> seems that Integer fits the subclass match *without* a method >>> invocation conversion, and therefore Object is a better fit. As I said >>> previously, a match via conversion should be considered of lower >>> desirability than a match that does not require conversion. That makes >>> both cases work. >>> >>> * primitive => primitive outweighs primitive => reference because a >>> conversion is required (int => int preferred over int => Object or int >>> => Integer) >>> * boxed => object outweighs boxed => primitive because a conversion is >>> required (Integer => Object or Integer => Integer preferred over >>> Integer => int) >>> >>> For my benefit and the benefit of others, let me try to spell it out. >>> >>> What you're saying by "the input doesn't matter" is that the >>> specificity tests are done independent of the actual incoming argument >>> types. A set of matching methods is found based on the incoming types, >>> and then that pool of methods enters the octagon with hopefully only >>> one "most specific" winner emerging. That's true. However, going back >>> to my earlier email, specificity is currently based subclass >>> relationships. Subclass relationships do not make sense in the context >>> of primitives, so we're using subclass specificity tests to choose a >>> method for an incoming argument type that doesn't subclass and doesn't >>> even live in the type hierarchy we're using to determine specificity. >>> >>> And if I continue from that understanding, what you mean by "int can't >>> be both more and less specific than Integer" is that without knowledge >>> of the actual incoming types, you can't make a rule whether to use the >>> int signature or the Integer signature in a way consistent with how we >>> want both int and Integer inputs to work. If you say int> Integer so >>> that int inputs choose int signatures, then you can't get to say >>> Integer> int when a later Integer call should call the Integer >>> signature. >>> >>> I think Dan Smith has it right when he said we need to insert a phase: >>> >>> 1) Applicable by subtyping >>> 2) Applicable by method invocation >>> *3) Applicable by subtyping with varargs* >>> 4) Applicable by method invocation with varargs >>> >>> This allows my original example to resolve the way most here think it >>> should. It also allows Integer to go to Object as appropriate. It's >>> not perfect though. >>> >>> Original example >>> >>> void method(String s, int n, Object... os); >>> void method(String s, Object... os); >>> method("abc", 3); >>> >>> Resolves to the int, Object... signature as expected. But Dan pointed >>> out that the same example with Integer would behave differently. >>> >>> void method(String s, int n, Object... os); >>> void method(String s, Object... os); >>> method("abc", new Integer(3)); >>> >>> Currently this is ambiguous since we go immediately to resolution >>> using conversion *and* varargs. Both int, Object... and Object... >>> signatures enter the octagon. Under the new four-phase mechanism, it >>> would resolve to the Object... signature because subtyping + varargs >>> takes precedence over conversion + varargs, resulting in the Object... >>> signature entering the octagon at the new phase three. >>> >>> This is a change, but it's more consistent with the first two >>> phases...and of course since it was ambiguous before, no code like >>> this exists in the wild. Given another example that does not hit >>> varargs: >>> >>> void method(String s, int n); >>> void method(String s, Object os); >>> method("abc", new Integer(3)); >>> >>> Obviously the Object signature is chosen for exactly the same reason: >>> subclassing rules over conversion. And people expect this. So rather >>> than making selection inconsistent, it actually makes the varargs >>> phases more consistent with the non-varargs phases. >>> >>> Why shouldn't varargs phase(s) obey the same precedence of subclassing >>> over conversion? >>> >>> - Charlie >>> >>> On Thu, Jun 9, 2011 at 5:44 PM, Neal Gafter wrote: >>>> The input doesn't matter to Java's "more specific" test. >>>> >>>> What if the input is Integer and the choices are int and Object. Do you >>>> really prefer the NullPointerException-causing unboxing conversion to >>>> the >>>> safe widening reference conversion? >>>> >>>> On Thu, Jun 9, 2011 at 3:30 PM, Charles Oliver Nutter >>>> >>>> wrote: >>>>> On Thu, Jun 9, 2011 at 5:12 PM, R?mi Forax wrote: >>>>>> You can, just consider int and Integer has the same node: >>>>>> int<= Integer&& int>= Integer because int == Integer >>>>> In addition, I don't see how Integer would ever need to be considered >>>>> more specific than int, for an int input. In what case does that >>>>> happen? >>>>> >>>>> - Charlie >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "JVM Languages" group. >>>>> To post to this group, send email to jvm-languages at googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> jvm-languages+unsubscribe at googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/jvm-languages?hl=en. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "JVM Languages" group. >>>> To post to this group, send email to jvm-languages at googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> jvm-languages+unsubscribe at googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/jvm-languages?hl=en. >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "JVM Languages" group. >>> To post to this group, send email to jvm-languages at googlegroups.com. >>> To unsubscribe from this group, send email to >>> jvm-languages+unsubscribe at googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/jvm-languages?hl=en. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "JVM Languages" group. >> To post to this group, send email to jvm-languages at googlegroups.com. >> To unsubscribe from this group, send email to >> jvm-languages+unsubscribe at googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jvm-languages?hl=en. >> From joe.darcy at oracle.com Fri Jun 10 12:10:41 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 10 Jun 2011 12:10:41 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: References: <4D9AD1B4.7020402@univ-mlv.fr> <4DEE5AAB.2060206@oracle.com> Message-ID: <4DF26C31.3050600@oracle.com> Hi Neal. Neal Gafter wrote: > On Tue, Jun 7, 2011 at 10:06 AM, Joe Darcy > wrote: > > The JCP SE/EE executive committee voted to approve the JSR 336 > public review > > http://www.jcp.org/en/jsr/results?id=5207 > > and the JSR 336 public review describes JSR 292 as including Java > language changes. > > > *The jsr292 specification which was published for public review does > not propose any changes to the Java Language Specification.* > > You said on April 18 that "Changes to the JSR 292 specification to > clarify [sic] the Java language changes that support MethodHandle are > in process". That process appears not to have occurred, as there are > no further public drafts of the jsr292 specification. > > The jsr336 specification doesn't propose any changes to the Java > Language Specification either, other than pointing to other jsrs. > > jsr901, the language "maintenance" jsr, does specify language changes, > but it has no independent approval process. The public review period > for its changes coincided with an outage in Oracle's public website > for viewing the issues it is alleged to address, which made impossible > any practical review of the changes. In any case, jsr901 contains no > jsr292-related changes such as polymorphic method signatures. > > Of course, with no public access to the expert group discussions it is > very hard for me to know precisely what it was that was decided in > either case. But based on the documents that have been published, > jsr336 didn't appear to approve for inclusion into SE 7 any language > changes that relate to jsr292. > > Cheers, > Neal The javadoc of the JSR 292 Public Review identified changes to the JVM Specification and discussed method handle invocation from the Java language. Admittedly the review could have done a better job of explicitly calling out the implied Java Language Specification changes. The forthcoming JSR 292 Proposed Final Draft will identify in detail its changes to both the JVM Specification and the Java Language Specification. The JVMS and JLS Maintenance Reviews earlier in 2011 were not related to JSR 292. Specifically, changes to casting conversion that turn out to be of use to JSR 292 were proposed independently years ago, see http://bugs.sun.com/view_bug.do?bug_id=6526446. The JVMS and JLS updated for JSR 292 (and JSR 334) will included as part of JSR 336's Proposed Final Draft; those specifications will also reflect the accumulated maintenance changes from JSR 901, etc. -Joe From dag.wanvik at oracle.com Fri Jun 10 09:16:39 2011 From: dag.wanvik at oracle.com (dag.wanvik at oracle.com) Date: Fri, 10 Jun 2011 16:16:39 +0000 Subject: hg: jdk7/tl/jdk: 7046557: Changes to the Java DB README files in JDK7 Message-ID: <20110610161651.7858847E9C@hg.openjdk.java.net> Changeset: b6ced5ad7a62 Author: dwanvik Date: 2011-06-10 17:44 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b6ced5ad7a62 7046557: Changes to the Java DB README files in JDK7 Summary: Update /README.html with correct mention of Java DB, add JDK specific README files to /db and /demo/db. Reviewed-by: ohair ! make/common/Release.gmk From neal at gafter.com Fri Jun 10 15:35:54 2011 From: neal at gafter.com (Neal Gafter) Date: Fri, 10 Jun 2011 15:35:54 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: <4DF26C31.3050600@oracle.com> References: <4D9AD1B4.7020402@univ-mlv.fr> <4DEE5AAB.2060206@oracle.com> <4DF26C31.3050600@oracle.com> Message-ID: On Fri, Jun 10, 2011 at 12:10 PM, Joe Darcy wrote: > The javadoc of the JSR 292 Public Review identified changes to the JVM > Specification and discussed method handle invocation from the Java language. > Admittedly the review could have done a better job of explicitly calling > out the implied Java Language Specification changes. > I would have said "alluded to" rather than "identified". There are no specific changes called out. > The forthcoming JSR 292 Proposed Final Draft will identify in detail its > changes to both the JVM Specification and the Java Language Specification. > Isn't it late in the process to begin specifying language changes? As language changes are the most delicate and difficult to retract changes in the platform, how many months of review do you anticipate once the proposed language spec changes.have been published? Cheers, Neal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110610/1d85a8af/attachment.html From schlosna at gmail.com Sat Jun 11 18:07:29 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 11 Jun 2011 21:07:29 -0400 Subject: Proposed javac argument processing performance improvement Message-ID: I'd like to propose a minor change for javac to improve performance processing large numbers of filename arguments, especially on Windows. The main issue is that com.sun.tools.javac.main.Main currently uses a ListBuffer for the collection of filenames. Main.addFile calls ListBuffer.contains before calling ListBuffer.add, both of which are linear searches leading to O(N^2) performance. Additionally, the implementation of java.io.File.equals uses the underlying filesystem's compare method which on Windows requires an expensive case insensitive string comparison. For large numbers of files (I work with several modules of approximately 10,000 Java input files for a single javac invocation) so this is a big performance hit. The simple fix is to use a LinkedHashSet instead of ListBuffer for the filenames field in com.sun.tools.javac.main.Main (see attached patch). My preliminary tests show that execution time of com.sun.tools.javac.main.Main.processArgs method for 10,000 input files on my Windows machine went from around 15 seconds to around 300 milliseconds with the patch. The performance improvement on case-sensitive filesystems isn't as good, but still seems to be an order of magnitude as seen in the following results on my main Mac OS X machine for com.sun.tools.javac.main.Main.processArgs method execution time. # files Before (ms) After (ms) Delta (ms) ------- ----------- ---------- ---------- 1 0.6 1.1 0.5 1000 39.4 39.7 0.3 2000 94.4 41.4 (53.1) 3000 184.8 61.4 (123.4) 4000 185.2 77.2 (108.0) 5000 257.9 89.1 (168.7) 6000 358.5 119.9 (238.6) 7000 422.1 126.7 (295.4) 8000 624.9 137.8 (487.2) 9000 620.1 139.8 (480.4) 10000 1,054.9 149.4 (905.5) Thanks, Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: javac-filenames-args.patch Type: application/octet-stream Size: 2423 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110611/8f45a374/javac-filenames-args.patch From daniel.smith at oracle.com Mon Jun 13 11:57:43 2011 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 13 Jun 2011 11:57:43 -0700 Subject: Proposed javac argument processing performance improvement In-Reply-To: References: Message-ID: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> Thank you very much for this useful analysis and patch! I'll work on getting this problem addressed. The current target for new patches is JDK 8; I'll also create a request to backport the fix to a JDK 7 update. Out of curiosity, what sort of an impact does this have on total compilation time? Given the n^2 growth, does processArgs start to dominate compilation time as n gets larger, or does it remain a fixed (probably small?) proportion of the total compilation time? ?Dan On Jun 11, 2011, at 6:07 PM, David Schlosnagle wrote: > I'd like to propose a minor change for javac to improve performance > processing large numbers of filename arguments, especially on Windows. > The main issue is that com.sun.tools.javac.main.Main currently uses a > ListBuffer for the collection of filenames. Main.addFile calls > ListBuffer.contains before calling ListBuffer.add, both of which are > linear searches leading to O(N^2) performance. Additionally, the > implementation of java.io.File.equals uses the underlying filesystem's > compare method which on Windows requires an expensive case insensitive > string comparison. For large numbers of files (I work with several > modules of approximately 10,000 Java input files for a single javac > invocation) so this is a big performance hit. The simple fix is to use > a LinkedHashSet instead of ListBuffer for the filenames > field in com.sun.tools.javac.main.Main (see attached patch). > > My preliminary tests show that execution time of > com.sun.tools.javac.main.Main.processArgs method for 10,000 input > files on my Windows machine went from around 15 seconds to around 300 > milliseconds with the patch. The performance improvement on > case-sensitive filesystems isn't as good, but still seems to be an > order of magnitude as seen in the following results on my main Mac OS > X machine for com.sun.tools.javac.main.Main.processArgs method > execution time. > > # files Before (ms) After (ms) Delta (ms) > ------- ----------- ---------- ---------- > 1 0.6 1.1 0.5 > 1000 39.4 39.7 0.3 > 2000 94.4 41.4 (53.1) > 3000 184.8 61.4 (123.4) > 4000 185.2 77.2 (108.0) > 5000 257.9 89.1 (168.7) > 6000 358.5 119.9 (238.6) > 7000 422.1 126.7 (295.4) > 8000 624.9 137.8 (487.2) > 9000 620.1 139.8 (480.4) > 10000 1,054.9 149.4 (905.5) > > > Thanks, > Dave > From jonathan.gibbons at oracle.com Mon Jun 13 11:59:56 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 13 Jun 2011 11:59:56 -0700 Subject: Proposed javac argument processing performance improvement In-Reply-To: References: Message-ID: <4DF65E2C.9000104@oracle.com> David, Nice patch. Thanks for submitting it. -- Jon On 06/11/2011 06:07 PM, David Schlosnagle wrote: > I'd like to propose a minor change for javac to improve performance > processing large numbers of filename arguments, especially on Windows. > The main issue is that com.sun.tools.javac.main.Main currently uses a > ListBuffer for the collection of filenames. Main.addFile calls > ListBuffer.contains before calling ListBuffer.add, both of which are > linear searches leading to O(N^2) performance. Additionally, the > implementation of java.io.File.equals uses the underlying filesystem's > compare method which on Windows requires an expensive case insensitive > string comparison. For large numbers of files (I work with several > modules of approximately 10,000 Java input files for a single javac > invocation) so this is a big performance hit. The simple fix is to use > a LinkedHashSet instead of ListBuffer for the filenames > field in com.sun.tools.javac.main.Main (see attached patch). > > My preliminary tests show that execution time of > com.sun.tools.javac.main.Main.processArgs method for 10,000 input > files on my Windows machine went from around 15 seconds to around 300 > milliseconds with the patch. The performance improvement on > case-sensitive filesystems isn't as good, but still seems to be an > order of magnitude as seen in the following results on my main Mac OS > X machine for com.sun.tools.javac.main.Main.processArgs method > execution time. > > # files Before (ms) After (ms) Delta (ms) > ------- ----------- ---------- ---------- > 1 0.6 1.1 0.5 > 1000 39.4 39.7 0.3 > 2000 94.4 41.4 (53.1) > 3000 184.8 61.4 (123.4) > 4000 185.2 77.2 (108.0) > 5000 257.9 89.1 (168.7) > 6000 358.5 119.9 (238.6) > 7000 422.1 126.7 (295.4) > 8000 624.9 137.8 (487.2) > 9000 620.1 139.8 (480.4) > 10000 1,054.9 149.4 (905.5) > > > Thanks, > Dave From joe.darcy at oracle.com Mon Jun 13 12:20:59 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 13 Jun 2011 19:20:59 +0000 Subject: hg: jdk8/tl/jdk: 7052122: Update JDK_MINOR_VERSION for JDK 8 Message-ID: <20110613192128.2A2EB47FDB@hg.openjdk.java.net> Changeset: 958eea7dd46e Author: darcy Date: 2011-06-13 12:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/958eea7dd46e 7052122: Update JDK_MINOR_VERSION for JDK 8 Reviewed-by: mr, katleman ! make/common/shared/Defs.gmk ! make/docs/Makefile From joe.darcy at oracle.com Mon Jun 13 12:21:36 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 13 Jun 2011 19:21:36 +0000 Subject: hg: jdk8/tl/langtools: 7052122: Update JDK_MINOR_VERSION for JDK 8 Message-ID: <20110613192141.A20EA47FDC@hg.openjdk.java.net> Changeset: 3b1fd4ac2e71 Author: darcy Date: 2011-06-13 12:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b1fd4ac2e71 7052122: Update JDK_MINOR_VERSION for JDK 8 Reviewed-by: mr, katleman + test/tools/javac/processing/model/TestSourceVersion.java From schlosna at gmail.com Mon Jun 13 16:06:45 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Mon, 13 Jun 2011 19:06:45 -0400 Subject: Proposed javac argument processing performance improvement In-Reply-To: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> Message-ID: On Mon, Jun 13, 2011 at 2:57 PM, Dan Smith wrote: > Thank you very much for this useful analysis and patch! > > I'll work on getting this problem addressed. ?The current target for new patches is JDK 8; I'll also create a request to backport the fix to a JDK 7 update. Excellent, if there is anything I can do to help get this back ported into JDK 7 and ideally 6, let me know. > Out of curiosity, what sort of an impact does this have on total compilation time? ?Given the n^2 growth, does processArgs start to dominate compilation time as n gets larger, or does it remain a fixed (probably small?) proportion of the total compilation time? After profiling the current implementation on Windows, processArgs does end up taking just over 51% overall javac execution time for large numbers of input files with around 4000 input files. If you're interested in the details, I attached output from a YourKit tracing profile session for javac with 4411 files as input on Windows. (Note that the execution times are extremely long due to the tracing overhead for including java.* and com.sun.* traces.) For 4411 input files on Windows, com.sun.tools.javac.util.List.contains, java.io.File.equals, java.io.File.compareTo, java.io.Win32FileSystem.compare, java.lang.String.compareToIgnoreCase, and java.lang.String$CaseInsensitiveComparator.compare are all executed (N+1)*(N/2) = 9,730,666 times each. On non-Windows filesystems, the implementation of java.io.File.compareTo just uses String.compareTo, so it is not as expensive as the case insensitive comparison of Windows. With the proposed patch, there will only be O(N) invocations of java.io.File.hashCode (and java.io.File.equals on collision). Unfortunately I don't have an OpenJDK Windows build right now, but I gathered some stats from a single pass on my Mac OS X OpenJDK 7 build compiling essentially a empty classes "public class TestN {}". Before: ======= # files processArgs javac real javac user javac sys 1 4.987ms 0m2.576s 0m0.725s 0m0.136s 1000 40.397ms 0m2.032s 0m3.470s 0m0.368s 2000 86.796ms 0m3.551s 0m5.275s 0m0.625s 3000 219.402ms 0m6.076s 0m8.510s 0m1.121s 4000 217.765ms 0m7.272s 0m11.209s 0m1.219s 5000 320.309ms 0m10.277s 0m16.011s 0m1.910s 6000 425.571ms 0m11.712s 0m18.127s 0m2.181s 7000 503.229ms 0m12.089s 0m18.869s 0m1.960s 8000 618.292ms 0m15.680s 0m21.288s 0m2.109s 9000 783.368ms 0m16.208s 0m22.597s 0m2.289s 10000 926.978ms 0m18.804s 0m25.991s 0m2.382s After: ====== # files processArgs javac real javac user javac sys 1 2.062ms 0m0.869s 0m0.887s 0m0.121s 1000 32.369ms 0m4.702s 0m3.729s 0m0.415s 2000 63.746ms 0m6.610s 0m5.914s 0m0.768s 3000 67.950ms 0m5.936s 0m8.116s 0m1.050s 4000 76.996ms 0m7.306s 0m11.667s 0m1.293s 5000 93.124ms 0m9.083s 0m15.092s 0m1.812s 6000 111.525ms 0m10.497s 0m17.183s 0m2.038s 7000 136.811ms 0m12.383s 0m19.278s 0m2.214s 8000 136.578ms 0m12.343s 0m18.999s 0m1.902s 9000 231.338ms 0m15.045s 0m21.841s 0m2.199s 10000 156.525ms 0m17.555s 0m25.835s 0m2.393s - Dave -------------- next part -------------- YourKit profiling details for 4411 Java input files to javac. Note: execution times are extremely long due to the tracing overhead for including java.* and com.sun.* traces. Call tree (all threads together) +-----------------------------------------------------------------------------------------------------------------------------------------+--------------------+------------------+-----------------+--------------------+ | Name | Time (ms) | Avg. Time (ms) | Own Time (ms) | Invocation Count | +-----------------------------------------------------------------------------------------------------------------------------------------+--------------------+------------------+-----------------+--------------------+ | +--- | 6,270,195 100 % | | | | | | | | | | | | +---com.sun.tools.javac.Main.main(String[]) | 6,267,570 100 % | 6,267,570 | 0 | 1 | | | | | | | | | | | +---com.sun.tools.javac.Main.compile(String[]) | 6,267,570 100 % | 6,267,570 | 0 | 1 | | | | | | | | | | | +---com.sun.tools.javac.main.Main.compile(String[]) | 6,267,479 100 % | 6,267,479 | 0 | 1 | | | | | | | | | | | | | +---com.sun.tools.javac.main.Main.compile(String[], Context) | 6,267,447 100 % | 6,267,447 | 0 | 1 | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.Main.compile(String[], Context, List, Iterable) | 6,267,447 100 % | 6,267,447 | 0 | 1 | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.Main.processArgs(String[]) | 3,251,385 52 % | 3,251,385 | 0 | 1 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.RecognizedOptions$26.process(Options, String) | 3,251,338 52 % | 736 | 0 | 4,412 | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.Main$1.addFile(File) | 3,249,763 52 % | 736 | 0 | 4,412 | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.ListBuffer.contains(Object) | 3,249,685 52 % | 736 | 0 | 4,412 | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.List.contains(Object) | 3,249,685 52 % | 736 | 0 | 4,412 | | | | | | | | | | | | | | | | | | | | | | | +---java.io.File.equals(Object) | 3,249,685 52 % | 0 | 13,024 | 9,730,666 | | | | | | | | | | | | | | | | | | | | | | | +---java.io.File.compareTo(File) | 3,236,660 52 % | 0 | 12,340 | 9,730,666 | | | | | | | | | | | | | | | | | | | | | | | +---java.io.Win32FileSystem.compare(File, File) | 3,224,320 51 % | 0 | 12,680 | 9,730,666 | | | | | | | | | | | | | | | | | | | | | | | +---java.lang.String.compareToIgnoreCase(String) | 3,211,640 51 % | 0 | 13,535 | 9,730,666 | | | | | | | | | | | | | | | | | | | | | | | +---java.lang.String$CaseInsensitiveComparator.compare(Object, Object) | 3,198,105 51 % | 0 | 13,021 | 9,730,666 | | | | | | | | | | | | | | | | | | | | | | | +---java.lang.String$CaseInsensitiveComparator.compare(String, String) | 3,185,083 51 % | 0 | 1,438,561 | 9,730,666 | | | | | | | | | | | | | | | | | | | | | | | +---java.lang.String.charAt(int) | 1,556,862 25 % | 0 | 1,556,862 | 2,209,281,822 | | | | | | | | | | | | | | | | | | | | | | | +---java.lang.Character.toUpperCase(char) | 95,618 2 % | 0 | 26,685 | 19,549,020 | | | | | | | | | | | | | | | | | | | | | | | +---java.lang.Character.toLowerCase(char) | 94,041 1 % | 0 | 27,076 | 19,461,332 | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.ListBuffer.append(Object) | 78 0 % | 0 | 15 | 4,412 | | | | | | | | | | | | | | | | | | | +---java.io.File.(String) | 1,105 0 % | 0 | 12 | 4,412 | | | | | | | | | | | | | | | | | | | +---java.io.File.exists() | 374 0 % | 0 | 15 | 4,412 | | | | | | | | | | | | | | | | | | | +---java.io.File.isFile() | 93 0 % | 0 | 15 | 4,412 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavacOption$Option.hasArg() | 15 0 % | 0 | 15 | 4,419 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.RecognizedOptions$26.matches(String) | 15 0 % | 0 | 0 | 4,412 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.RecognizedOptions$13.process(Options, String, String) | 15 0 % | 15 | 0 | 1 | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.compile(List, List, Iterable) | 3,011,780 48 % | 3,011,780 | 0 | 1 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.compile2() | 2,657,963 42 % | 2,657,963 | 0 | 1 | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.attribute(Env) | 1,816,560 29 % | 581 | 0 | 3,124 | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClass(JCDiagnostic$DiagnosticPosition, Symbol$ClassSymbol) | 1,816,513 29 % | 581 | 0 | 3,124 | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClass(Symbol$ClassSymbol) | 1,816,498 29 % | 581 | 0 | 3,124 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClass(Symbol$ClassSymbol) | 1,621,719 26 % | 560 | 0 | 2,893 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClass(Symbol$ClassSymbol) | 1,567,987 25 % | 569 | 0 | 2,751 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClass(Symbol$ClassSymbol) | 906,889 14 % | 333 | 0 | 2,719 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClassBody(Env, Symbol$ClassSymbol) | 772,356 12 % | 3,387 | 0 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkCompatibleSupertypes(JCDiagnostic$DiagnosticPosition, Type) | 457,541 7 % | 2,006 | 0 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribStat(JCTree, Env) | 289,004 5 % | 38 | 0 | 7,500 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkImplementations(JCTree$JCClassDecl) | 20,887 0 % | 91 | 0 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkAllDefined(JCDiagnostic$DiagnosticPosition, Symbol$ClassSymbol) | 3,072 0 % | 139 | 0 | 22 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkClassBounds(JCDiagnostic$DiagnosticPosition, Type) | 1,710 0 % | 7 | 0 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.validateAnnotations(List, Symbol) | 93 0 % | 0 | 0 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkCyclicConstructors(JCTree$JCClassDecl) | 30 0 % | 0 | 30 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.validate(List) | 15 0 % | 0 | 15 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClass(Symbol$ClassSymbol) | 134,501 2 % | 53 | 0 | 2,501 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkNonCyclic(JCDiagnostic$DiagnosticPosition, Type) | 15 0 % | 0 | 15 | 2,719 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.code.Lint.augment(List, long) | 15 0 % | 0 | 15 | 228 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClassBody(Env, Symbol$ClassSymbol) | 661,067 11 % | 1,916 | 0 | 345 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribStat(JCTree, Env) | 350,687 6 % | 27 | 0 | 12,951 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkCompatibleSupertypes(JCDiagnostic$DiagnosticPosition, Type) | 283,727 5 % | 822 | 0 | 345 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkImplementations(JCTree$JCClassDecl) | 24,779 0 % | 71 | 0 | 345 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkClassBounds(JCDiagnostic$DiagnosticPosition, Type) | 1,591 0 % | 4 | 0 | 345 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.validateAnnotations(List, Symbol) | 218 0 % | 0 | 0 | 345 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkCyclicConstructors(JCTree$JCClassDecl) | 31 0 % | 0 | 0 | 345 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.List.nonEmpty() | 31 0 % | 0 | 31 | 13,641 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.code.Types.supertype(Type) | 31 0 % | 0 | 0 | 2,751 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClassBody(Env, Symbol$ClassSymbol) | 53,622 1 % | 89 | 0 | 602 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.code.Types.supertype(Type) | 31 0 % | 0 | 0 | 2,893 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkNonCyclic(JCDiagnostic$DiagnosticPosition, Type) | 31 0 % | 0 | 0 | 2,893 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.Log.useSource(JavaFileObject) | 15 0 % | 0 | 15 | 1,204 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---java.util.HashMap.get(Object) | 15 0 % | 0 | 15 | 602 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.code.Lint.augment(List, long) | 15 0 % | 0 | 0 | 602 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribClassBody(Env, Symbol$ClassSymbol) | 194,590 3 % | 121 | 0 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkAllDefined(JCDiagnostic$DiagnosticPosition, Symbol$ClassSymbol) | 120,811 2 % | 84 | 0 | 1,437 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkImplementations(JCTree$JCClassDecl) | 49,259 1 % | 30 | 0 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Attr.attribStat(JCTree, Env) | 20,063 0 % | 2 | 0 | 8,770 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkClassBounds(JCDiagnostic$DiagnosticPosition, Type) | 3,807 0 % | 2 | 0 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.validateAnnotations(List, Symbol) | 444 0 % | 0 | 25 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkCyclicConstructors(JCTree$JCClassDecl) | 124 0 % | 0 | 15 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.validate(JCTree) | 31 0 % | 0 | 0 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkCompatibleSupertypes(JCDiagnostic$DiagnosticPosition, Type) | 31 0 % | 0 | 0 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.validate(List) | 15 0 % | 0 | 15 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkNonCyclic(JCDiagnostic$DiagnosticPosition, Type) | 93 0 % | 0 | 0 | 3,124 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.code.Lint.augment(List, long) | 31 0 % | 0 | 0 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.code.Symbol$ClassSymbol.flags() | 15 0 % | 0 | 15 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.code.Types.supertype(Type) | 15 0 % | 0 | 0 | 3,124 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.Log.useSource(JavaFileObject) | 15 0 % | 0 | 15 | 3,194 | | | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Check.checkDeprecatedAnnotation(JCDiagnostic$DiagnosticPosition, Symbol) | 15 0 % | 0 | 15 | 1,597 | | | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.comp.Annotate.flush() | 15 0 % | 0 | 15 | 3,124 | | | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.Log.useSource(JavaFileObject) | 46 0 % | 0 | 31 | 6,247 | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.desugar(List) | 774,275 12 % | 247 | 0 | 3,123 | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.generate(List) | 56,904 1 % | 18 | 0 | 3,123 | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.flow(Env) | 10,160 0 % | 3 | 0 | 3,123 | | | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.ListBuffer.next() | 46 0 % | 0 | 46 | 3,124 | | | | | | | | | | | | | | | | | | | +---java.lang.ClassLoader.loadClass(String) | 15 0 % | 15 | 0 | 1 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.enterTrees(List) | 227,960 4 % | 227,960 | 0 | 1 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.parseFiles(List) | 122,709 2 % | 122,709 | 0 | 1 | | | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.initProcessAnnotations(Iterable) | 3,147 0 % | 3,147 | 0 | 1 | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.CommandLine.parse(String[]) | 3,146 0 % | 3,146 | 0 | 1 | | | | | | | | | | | | | | | +---com.sun.tools.javac.main.JavaCompiler.instance(Context) | 683 0 % | 341 | 0 | 2 | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.DefaultFileManager.getJavaFileObjectsFromFiles(Iterable) | 296 0 % | 296 | 0 | 1 | | | | | | | | | | | | | | | +---java.lang.ClassLoader.loadClass(String) | 61 0 % | 2 | 0 | 25 | | | | | | | | | | | | | | | +---java.util.AbstractList$Itr.next() | 46 0 % | 0 | 46 | 4,412 | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.Context.get(Class) | 31 0 % | 31 | 0 | 1 | | | | | | | | | | | | | | | +---com.sun.tools.javac.util.List.prepend(Object) | 15 0 % | 0 | 0 | 8,824 | | | | | | | | | | | | | +---java.lang.ClassLoader.loadClass(String) | 31 0 % | 1 | 0 | 23 | | | | | | | | | | | +---com.sun.tools.javac.main.Main.(String) | 76 0 % | 76 | 0 | 1 | | | | | | | | | | | +---java.lang.ClassLoader.loadClass(String) | 15 0 % | 0 | 0 | 20 | | | | | | | | | +---java.lang.ref.Finalizer$FinalizerThread.run() | 2,146 0 % | 2,146 | 0 | 1 | | | | | | | | | +---java.lang.ref.Reference$ReferenceHandler.run() | 404 0 % | 404 | 123 | 1 | | | | | | | | | +---java.lang.ClassLoader.loadClass(String) | 57 0 % | 9 | 0 | 6 | | | | | | | | | +---java.lang.String.(byte[], String) | 15 0 % | 1 | 0 | 14 | +-----------------------------------------------------------------------------------------------------------------------------------------+--------------------+------------------+-----------------+--------------------+ CPU hot spots +-------------------------------------------------------------------------------------------+--------------------+--------------------+ | Name | Time (ms) | Invocation Count | +-------------------------------------------------------------------------------------------+--------------------+--------------------+ | +---java.lang.String$CaseInsensitiveComparator.compare(String, String) | 3,187,016 51 % | 9,739,721 | | +---com.sun.tools.javac.code.Type$ClassType.accept(Type$Visitor, Object) | 1,886,220 30 % | 291,986,289 | | +---com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Type, Object) | 1,664,501 27 % | 87,588,294 | | +---java.lang.String.charAt(int) | 1,560,565 25 % | 2,214,530,911 | | +---com.sun.tools.javac.code.Types.asSuper(Type, Symbol) | 1,389,993 22 % | 67,933,035 | | +---com.sun.tools.javac.code.Types$14.visitClassType(Type$ClassType, Object) | 1,377,241 22 % | 67,890,233 | | +---com.sun.tools.javac.code.Types$14.visitClassType(Type$ClassType, Symbol) | 1,373,419 22 % | 67,890,233 | | +---com.sun.tools.javac.code.Types$UnaryVisitor.visit(Type) | 1,150,529 18 % | 215,522,154 | | +---com.sun.tools.javac.code.Types.supertype(Type) | 776,346 12 % | 120,203,422 | | +---com.sun.tools.javac.code.Types.interfaces(Type) | 564,352 9 % | 87,001,829 | | +---com.sun.tools.javac.comp.Resolve.findMemberType(Env, Type, Name, Symbol$TypeSymbol) | 368,939 6 % | 19,660,229 | | +---com.sun.tools.javac.code.Types$18.visitClassType(Type$ClassType, Object) | 262,150 4 % | 120,065,634 | | +---com.sun.tools.javac.code.Types$19.visitClassType(Type$ClassType, Object) | 189,477 3 % | 86,867,419 | +-------------------------------------------------------------------------------------------+--------------------+--------------------+ Back traces +-------------------------------------------------------------------------------------------------------------------------+--------------------+--------------------+ | Name | Time (ms) | Invocation Count | +-------------------------------------------------------------------------------------------------------------------------+--------------------+--------------------+ | +---java.lang.String$CaseInsensitiveComparator.compare(String, String) | 3,187,016 100 % | 9,739,721 100 % | | +---java.lang.String$CaseInsensitiveComparator.compare(Object, Object) | | | | +---java.lang.String.compareToIgnoreCase(String) | | | | +---java.io.Win32FileSystem.compare(File, File) | | | | +---java.io.File.compareTo(File) | | | | +---java.io.File.equals(Object) | | | | +---com.sun.tools.javac.util.List.contains(Object) | 3,185,083 100 % | 9,730,666 100 % | | | +---com.sun.tools.javac.util.ListBuffer.contains(Object) | | | | | +---com.sun.tools.javac.main.Main$1.addFile(File) | | | | | +---com.sun.tools.javac.main.RecognizedOptions$26.process(Options, String) | | | | | +---com.sun.tools.javac.main.Main.processArgs(String[]) | | | | | +---com.sun.tools.javac.main.Main.compile(String[], Context, List, Iterable) | | | | | +---com.sun.tools.javac.main.Main.compile(String[], Context) | | | | | +---com.sun.tools.javac.main.Main.compile(String[]) | | | | | +---com.sun.tools.javac.Main.compile(String[]) | | | | | +---com.sun.tools.javac.Main.main(String[]) | | | | +---com.sun.tools.javac.util.DefaultFileManager.inferBinaryName(JavaFileManager$Location, JavaFileObject) | 1,932 0 % | 8,832 0 % | | +---com.sun.tools.javac.util.DefaultFileManager.openArchive(File) | 0 0 % | 1 0 % | | +---com.sun.tools.javac.util.DefaultFileManager$RegularFileObject.equals(Object) | 0 0 % | 2 0 % | | +---com.sun.tools.javac.util.Paths.computeBootClassPath() | 0 0 % | 9 0 % | | +---com.sun.tools.javac.util.Paths.isBootClassPathRtJar(File) | 0 0 % | 196 0 % | | +---java.util.concurrent.ConcurrentHashMap$Segment.get(Object, int) | 0 0 % | 10 0 % | | +---java.util.HashMap.getEntry(Object) | 0 0 % | 5 0 % | +-------------------------------------------------------------------------------------------------------------------------+--------------------+--------------------+ From sean.coffey at oracle.com Tue Jun 14 10:02:19 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 14 Jun 2011 17:02:19 +0000 Subject: hg: jdk8/tl/jdk: 7049774: UID construction appears to hang if time changed backwards Message-ID: <20110614170229.3352B47012@hg.openjdk.java.net> Changeset: 08fdfdb19ad6 Author: coffeys Date: 2011-06-14 18:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08fdfdb19ad6 7049774: UID construction appears to hang if time changed backwards Reviewed-by: alanb, dholmes, chegar, mduigou ! src/share/classes/java/rmi/server/UID.java From joe.darcy at oracle.com Tue Jun 14 12:31:57 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 14 Jun 2011 19:31:57 +0000 Subject: hg: jdk8/tl/jdk: 7054669: javadoc warnings from java.awt.Toolkit Message-ID: <20110614193222.3762D47019@hg.openjdk.java.net> Changeset: 4e7a9fa84dea Author: darcy Date: 2011-06-14 12:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e7a9fa84dea 7054669: javadoc warnings from java.awt.Toolkit Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java From jonathan.gibbons at oracle.com Tue Jun 14 16:34:14 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 14 Jun 2011 16:34:14 -0700 Subject: Proposed javac argument processing performance improvement In-Reply-To: References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> Message-ID: <4DF7EFF6.2030300@oracle.com> David, Looking at your patch, you take a hit at the end by converting the Set to a List by way of an array. At a minimum, it would be worth overloading List.from to accept an Iterable -- that would allow you to eliminate the intermediate array. For bonus points, you could change the return type of processArgs to Iterable and avoid the copy altogether. However, in that case, you would need to fix up a couple of isEmpty() calls in Main. The primary use of the result is in Main.java:412, which already accepts Iterable. There are no other uses that I can see within the main javac source code. I found 3 uses in the regression tests that would be unaffected. I believe there are a couple of regression tests that need to be fixed up if you change the type of JavaCompiler.filenames. -- Jon On 06/13/2011 04:06 PM, David Schlosnagle wrote: > On Mon, Jun 13, 2011 at 2:57 PM, Dan Smith wrote: >> Thank you very much for this useful analysis and patch! >> >> I'll work on getting this problem addressed. The current target for new patches is JDK 8; I'll also create a request to backport the fix to a JDK 7 update. > Excellent, if there is anything I can do to help get this back ported > into JDK 7 and ideally 6, let me know. > >> Out of curiosity, what sort of an impact does this have on total compilation time? Given the n^2 growth, does processArgs start to dominate compilation time as n gets larger, or does it remain a fixed (probably small?) proportion of the total compilation time? > After profiling the current implementation on Windows, processArgs > does end up taking just over 51% overall javac execution time for > large numbers of input files with around 4000 input files. If you're > interested in the details, I attached output from a YourKit tracing > profile session for javac with 4411 files as input on Windows. (Note > that the execution times are extremely long due to the tracing > overhead for including java.* and com.sun.* traces.) > > For 4411 input files on Windows, > com.sun.tools.javac.util.List.contains, java.io.File.equals, > java.io.File.compareTo, java.io.Win32FileSystem.compare, > java.lang.String.compareToIgnoreCase, and > java.lang.String$CaseInsensitiveComparator.compare are all executed > (N+1)*(N/2) = 9,730,666 times each. On non-Windows filesystems, the > implementation of java.io.File.compareTo just uses String.compareTo, > so it is not as expensive as the case insensitive comparison of > Windows. > > With the proposed patch, there will only be O(N) invocations of > java.io.File.hashCode (and java.io.File.equals on collision). > Unfortunately I don't have an OpenJDK Windows build right now, but I > gathered some stats from a single pass on my Mac OS X OpenJDK 7 build > compiling essentially a empty classes "public class TestN {}". > > Before: > ======= > # files processArgs javac real javac user javac sys > 1 4.987ms 0m2.576s 0m0.725s 0m0.136s > 1000 40.397ms 0m2.032s 0m3.470s 0m0.368s > 2000 86.796ms 0m3.551s 0m5.275s 0m0.625s > 3000 219.402ms 0m6.076s 0m8.510s 0m1.121s > 4000 217.765ms 0m7.272s 0m11.209s 0m1.219s > 5000 320.309ms 0m10.277s 0m16.011s 0m1.910s > 6000 425.571ms 0m11.712s 0m18.127s 0m2.181s > 7000 503.229ms 0m12.089s 0m18.869s 0m1.960s > 8000 618.292ms 0m15.680s 0m21.288s 0m2.109s > 9000 783.368ms 0m16.208s 0m22.597s 0m2.289s > 10000 926.978ms 0m18.804s 0m25.991s 0m2.382s > > After: > ====== > # files processArgs javac real javac user javac sys > 1 2.062ms 0m0.869s 0m0.887s 0m0.121s > 1000 32.369ms 0m4.702s 0m3.729s 0m0.415s > 2000 63.746ms 0m6.610s 0m5.914s 0m0.768s > 3000 67.950ms 0m5.936s 0m8.116s 0m1.050s > 4000 76.996ms 0m7.306s 0m11.667s 0m1.293s > 5000 93.124ms 0m9.083s 0m15.092s 0m1.812s > 6000 111.525ms 0m10.497s 0m17.183s 0m2.038s > 7000 136.811ms 0m12.383s 0m19.278s 0m2.214s > 8000 136.578ms 0m12.343s 0m18.999s 0m1.902s > 9000 231.338ms 0m15.045s 0m21.841s 0m2.199s > 10000 156.525ms 0m17.555s 0m25.835s 0m2.393s > > - Dave From joe.darcy at oracle.com Wed Jun 15 08:37:50 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 15 Jun 2011 15:37:50 +0000 Subject: hg: jdk8/tl/jdk: 7041252: Use j.u.Objects.equals in security classes Message-ID: <20110615153816.E9AF74704F@hg.openjdk.java.net> Changeset: 33e6291f3251 Author: darcy Date: 2011-06-15 08:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33e6291f3251 7041252: Use j.u.Objects.equals in security classes Reviewed-by: weijun ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/x509/DistributionPoint.java ! src/share/classes/sun/security/x509/DistributionPointName.java From schlosna at gmail.com Thu Jun 16 20:16:22 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 16 Jun 2011 23:16:22 -0400 Subject: Proposed javac argument processing performance improvement In-Reply-To: <4DF7EFF6.2030300@oracle.com> References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> <4DF7EFF6.2030300@oracle.com> Message-ID: On Tue, Jun 14, 2011 at 7:34 PM, Jonathan Gibbons wrote: > David, > > Looking at your patch, you take a hit at the end by converting the Set to a > List by way of an array. ?At a minimum, it would be worth overloading > List.from to accept an Iterable -- that would allow you to eliminate the > intermediate array. For bonus points, you could change the return type of > processArgs to Iterable and avoid the copy altogether. However, in > that case, you would need to fix up a couple of isEmpty() calls in Main. The > primary use of the result is in Main.java:412, which already accepts > Iterable. ?There are no other uses that I can see within the main > javac source code. I found 3 uses in the regression tests that would be > unaffected. Jon, Thanks for the comments. I had debated refactoring the method signature, but held off initially. This weekend I'll try to put together a patch with Iterable and gather some more realistic stats across a few platforms. I did a few initial tests on a medium sized build and the results were very promising -- the total javac execution time for compiling a 5,522 file module went from 54 seconds to 39 seconds, a reduction of 15 seconds all due to reducing processArgs execution time from 15.890 seconds to 0.350 seconds. For smaller numbers of input files, the gains were proportional to the number of input files. With the Iterable changes, I hope to see even more gains. > I believe there are a couple of regression tests that need to be fixed up if > you change the type of JavaCompiler.filenames. I'll include these changes in the patch and run jtreg. Do you typically create performance related regression tests? Are there any new tests you'd recommend for me to add? On a side note, are there any langtools jtreg tests that are currently known to fail? I saw 3 failed javadoc tests that seem to be Mac OS X specific and probably related to http://java.net/jira/browse/MACOSX_PORT-38. - Dave From jonathan.gibbons at oracle.com Thu Jun 16 21:03:00 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Jun 2011 21:03:00 -0700 Subject: Proposed javac argument processing performance improvement In-Reply-To: References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> <4DF7EFF6.2030300@oracle.com> Message-ID: <4DFAD1F4.8090503@oracle.com> On 06/16/2011 08:16 PM, David Schlosnagle wrote: > On Tue, Jun 14, 2011 at 7:34 PM, Jonathan Gibbons > wrote: >> David, >> >> Looking at your patch, you take a hit at the end by converting the Set to a >> List by way of an array. At a minimum, it would be worth overloading >> List.from to accept an Iterable -- that would allow you to eliminate the >> intermediate array. For bonus points, you could change the return type of >> processArgs to Iterable and avoid the copy altogether. However, in >> that case, you would need to fix up a couple of isEmpty() calls in Main. The >> primary use of the result is in Main.java:412, which already accepts >> Iterable. There are no other uses that I can see within the main >> javac source code. I found 3 uses in the regression tests that would be >> unaffected. > Jon, > > Thanks for the comments. I had debated refactoring the method > signature, but held off initially. This weekend I'll try to put > together a patch with Iterable and gather some more realistic > stats across a few platforms. I did a few initial tests on a medium > sized build and the results were very promising -- the total javac > execution time for compiling a 5,522 file module went from 54 seconds > to 39 seconds, a reduction of 15 seconds all due to reducing > processArgs execution time from 15.890 seconds to 0.350 seconds. For > smaller numbers of input files, the gains were proportional to the > number of input files. With the Iterable changes, I hope to see even > more gains. > >> I believe there are a couple of regression tests that need to be fixed up if >> you change the type of JavaCompiler.filenames. > I'll include these changes in the patch and run jtreg. Do you > typically create performance related regression tests? Are there any > new tests you'd recommend for me to add? > > On a side note, are there any langtools jtreg tests that are currently > known to fail? I saw 3 failed javadoc tests that seem to be Mac OS X > specific and probably related to > http://java.net/jira/browse/MACOSX_PORT-38. > > - Dave Dave, Thanks for the update, and for looking at making your patch work even faster. For a perf-related change like this, no new regression tests will be necessary. The normal rules in a case like this are to make sure that nothing is broken, meaning that all the (langtools) tests should still pass and that it should still be capable to build the OpenJDK forest. Normally, it is sufficient to do a regular build of OpenJDK; in some circumstances, it would be expected to pass a build with SKIP_BOOT_CYCLE=false, meaning that it should be able to build OpenJDK -- and the result should itself be capable of building OpenJDK. This double build verifies that the bits from the first build are good enough to function as a BOOT_JDK. But, I don't think the double build is necessary in this case, since this is a relatively simple change related to command line processing. Normally, all the langtools tests should pass all time time, on all supported platforms (Linux, Windows, Solaris.) I haven't checked out the Mac port recently to see how the tests perform on that platform. -- Jon From alan.bateman at oracle.com Fri Jun 17 08:58:49 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 17 Jun 2011 15:58:49 +0000 Subject: hg: jdk7/tl/jdk: 7055508: (aio) EXCEPTION_ACCESS_VIOLATION in AsynchronousSocketChannel.connect on Windows 7 Message-ID: <20110617155901.5FBA9470D2@hg.openjdk.java.net> Changeset: c46f97579fe6 Author: alanb Date: 2011-06-17 16:47 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c46f97579fe6 7055508: (aio) EXCEPTION_ACCESS_VIOLATION in AsynchronousSocketChannel.connect on Windows 7 Reviewed-by: chegar ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c From joe.darcy at oracle.com Fri Jun 17 10:35:18 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 17 Jun 2011 17:35:18 +0000 Subject: hg: jdk8/tl/jdk: 7021922: java.lang.annoation.IncompleteExceptions throws NPE when type is null Message-ID: <20110617173544.D26B1470D6@hg.openjdk.java.net> Changeset: 85480980cd5e Author: darcy Date: 2011-06-17 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85480980cd5e 7021922: java.lang.annoation.IncompleteExceptions throws NPE when type is null Reviewed-by: alanb, forax ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java + test/java/lang/annotation/TestIncompleteAnnotationExceptionNPE.java From kumar.x.srinivasan at oracle.com Fri Jun 17 15:29:30 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 17 Jun 2011 22:29:30 +0000 Subject: hg: jdk8/tl/jdk: 7043125: TEST: tools/launcher/VersionCheck.java fails just against openjdk7 (b141 & b138-nightly) promoted Message-ID: <20110617222939.EF497470E3@hg.openjdk.java.net> Changeset: e373b4c95b4b Author: ksrini Date: 2011-06-17 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e373b4c95b4b 7043125: TEST: tools/launcher/VersionCheck.java fails just against openjdk7 (b141 & b138-nightly) promoted Reviewed-by: darcy ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/VersionCheck.java From alan.bateman at oracle.com Sun Jun 19 03:33:00 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Jun 2011 10:33:00 +0000 Subject: hg: jdk8/tl/jdk: 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java hangs or times out Message-ID: <20110619103331.744674713D@hg.openjdk.java.net> Changeset: b29888e74be3 Author: alanb Date: 2011-06-19 11:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b29888e74be3 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java hangs or times out Reviewed-by: forax, vinnie ! test/ProblemList.txt ! test/com/sun/jndi/ldap/ReadTimeoutTest.java From weijun.wang at oracle.com Mon Jun 20 02:39:20 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 20 Jun 2011 09:39:20 +0000 Subject: hg: jdk8/tl/jdk: 7054428: test/java/security/SecureClassLoader/DefineClassByteBuffer.java error Message-ID: <20110620093950.06BB54716C@hg.openjdk.java.net> Changeset: 82706552f7a3 Author: weijun Date: 2011-06-20 17:38 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82706552f7a3 7054428: test/java/security/SecureClassLoader/DefineClassByteBuffer.java error Reviewed-by: alanb ! test/ProblemList.txt ! test/java/security/SecureClassLoader/DefineClassByteBuffer.java From chris.hegarty at oracle.com Mon Jun 20 03:28:54 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 20 Jun 2011 10:28:54 +0000 Subject: hg: jdk8/tl/jdk: 7051516: ThreadLocalRandom seed is never initialized so all instances generate the same sequence Message-ID: <20110620102904.A01764716E@hg.openjdk.java.net> Changeset: 411d02c13385 Author: dl Date: 2011-06-20 12:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/411d02c13385 7051516: ThreadLocalRandom seed is never initialized so all instances generate the same sequence Reviewed-by: chegar, dholmes, mduigou ! src/share/classes/java/util/Random.java From weijun.wang at oracle.com Mon Jun 20 04:19:02 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 20 Jun 2011 11:19:02 +0000 Subject: hg: jdk8/tl/jdk: 7054918: jdk_security1 test target cleanup Message-ID: <20110620111912.6F3BA47171@hg.openjdk.java.net> Changeset: a015dda3bdc6 Author: weijun Date: 2011-06-20 19:17 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a015dda3bdc6 7054918: jdk_security1 test target cleanup Reviewed-by: alanb, smarks, vinnie ! test/ProblemList.txt ! test/java/security/BasicPermission/PermClass.java ! test/java/security/BasicPermission/SerialVersion.java ! test/java/security/KeyFactory/Failover.java ! test/java/security/KeyPairGenerator/Failover.java ! test/java/security/Provider/ChangeProviders.java ! test/java/security/Provider/GetInstance.java ! test/java/security/Provider/RemoveProvider.java ! test/java/security/Provider/Turkish.java ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/NoInstalledProviders.java ! test/java/security/Security/SynchronizedAccess.java ! test/java/security/Security/removing/RemoveProviders.java ! test/java/security/UnresolvedPermission/Equals.java ! test/java/security/spec/EllipticCurveMatch.java + test/java/security/testlibrary/ProvidersSnapshot.java From lana.steuck at oracle.com Mon Jun 20 14:56:21 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 20 Jun 2011 21:56:21 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b145 for changeset 55e9ebf03218 Message-ID: <20110620215622.1FE224718B@hg.openjdk.java.net> Changeset: 2d38c2a79c14 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2d38c2a79c14 Added tag jdk7-b145 for changeset 55e9ebf03218 ! .hgtags From lana.steuck at oracle.com Mon Jun 20 14:56:27 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 20 Jun 2011 21:56:27 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b145 for changeset 77ec0541aa2a Message-ID: <20110620215628.B977D4718C@hg.openjdk.java.net> Changeset: 770227a4087e Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/770227a4087e Added tag jdk7-b145 for changeset 77ec0541aa2a ! .hgtags From lana.steuck at oracle.com Mon Jun 20 14:56:40 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 20 Jun 2011 21:56:40 +0000 Subject: hg: jdk7/tl/jaxws: 11 new changesets Message-ID: <20110620215640.F3DDC4718D@hg.openjdk.java.net> Changeset: 6ec12c60ad13 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/6ec12c60ad13 Added tag jdk7-b145 for changeset 42bfba80beb7 ! .hgtags Changeset: 581dab3f0773 Author: asaha Date: 2011-04-21 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/581dab3f0773 Merge Changeset: 26610bb80151 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/26610bb80151 Merge Changeset: c6ff860428c7 Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/c6ff860428c7 Merge Changeset: f4e1caef46d0 Author: asaha Date: 2011-05-24 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/f4e1caef46d0 Merge Changeset: 9896cee00786 Author: asaha Date: 2011-05-26 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/9896cee00786 Merge Changeset: d1febdcb0351 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/d1febdcb0351 Merge Changeset: 239c80c331da Author: asaha Date: 2011-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/239c80c331da Merge Changeset: 09412171ca4b Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/09412171ca4b Merge Changeset: 9d8fd0982fb8 Author: asaha Date: 2011-06-06 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/9d8fd0982fb8 Merge Changeset: 05469dd4c366 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/05469dd4c366 Merge From lana.steuck at oracle.com Mon Jun 20 14:56:45 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 20 Jun 2011 21:56:45 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b145 for changeset 10ca7570f47f Message-ID: <20110620215645.0C0404718E@hg.openjdk.java.net> Changeset: bcd31fa1e3c6 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bcd31fa1e3c6 Added tag jdk7-b145 for changeset 10ca7570f47f ! .hgtags From lana.steuck at oracle.com Mon Jun 20 14:56:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 20 Jun 2011 21:56:54 +0000 Subject: hg: jdk7/tl/langtools: 15 new changesets Message-ID: <20110620215727.4C4C94718F@hg.openjdk.java.net> Changeset: 9ff91d0e7154 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9ff91d0e7154 Added tag jdk7-b145 for changeset c455e2ae5c93 ! .hgtags Changeset: b8a2c9c87018 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b8a2c9c87018 Merge Changeset: 588d366d96df Author: asaha Date: 2011-04-21 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/588d366d96df Merge Changeset: 219b522d09e4 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/219b522d09e4 Merge Changeset: 145d832616d3 Author: asaha Date: 2011-05-05 22:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/145d832616d3 Merge Changeset: 8b6e015ae7d0 Author: asaha Date: 2011-05-24 11:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8b6e015ae7d0 Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 35cc19ae29b5 Author: asaha Date: 2011-05-26 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/35cc19ae29b5 Merge Changeset: 8b65930602c3 Author: asaha Date: 2011-05-26 21:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8b65930602c3 Merge Changeset: 0adb806caf9d Author: asaha Date: 2011-06-06 10:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0adb806caf9d Merge Changeset: bb1fdcebde01 Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bb1fdcebde01 Merge Changeset: 8ed03b0e3c9c Author: asaha Date: 2011-06-06 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8ed03b0e3c9c Merge Changeset: f494ca4bca0d Author: lana Date: 2011-06-15 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f494ca4bca0d Merge Changeset: 7eba9df190ae Author: bpatel Date: 2011-06-17 20:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7eba9df190ae 7052425: Change the look and feel of the javadoc generate HTML pages using stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: c3a3440fe6e8 Author: bpatel Date: 2011-06-17 20:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c3a3440fe6e8 Merge Changeset: 9425dd4f53d5 Author: schien Date: 2011-06-18 09:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9425dd4f53d5 Merge From lana.steuck at oracle.com Mon Jun 20 14:57:16 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 20 Jun 2011 21:57:16 +0000 Subject: hg: jdk7/tl/hotspot: 42 new changesets Message-ID: <20110620215834.D28B147190@hg.openjdk.java.net> Changeset: 9340a27154cb Author: kvn Date: 2011-05-25 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9340a27154cb 7048332: Cadd_cmpLTMask doesn't handle 64-bit tmp register properly Summary: Use ins_encode %{ %} form to encode cadd_cmpLTMask() instruction and remove unused code. Reviewed-by: never ! src/cpu/x86/vm/x86_64.ad + test/compiler/7048332/Test7048332.java Changeset: ea0da5474c23 Author: kvn Date: 2011-05-27 12:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ea0da5474c23 7047069: Array can dynamically change size when assigned to an object field Summary: Fix initialization of a newly-allocated array with arraycopy Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/7047069/Test7047069.java Changeset: 88559690c95a Author: never Date: 2011-05-26 14:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/88559690c95a 7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly Reviewed-by: kvn, jrose ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: 442ef93966a9 Author: iveresov Date: 2011-05-26 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/442ef93966a9 7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub Summary: Save and restore the argument registers around the call to checkcast_arraycopy Reviewed-by: never, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 3f7a95be91ef Author: iveresov Date: 2011-06-01 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f7a95be91ef Merge Changeset: 7c907a50c1bb Author: iveresov Date: 2011-06-01 14:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7c907a50c1bb Merge Changeset: f88fb2fa90cf Author: kvn Date: 2011-05-31 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f88fb2fa90cf 6956668: misbehavior of XOR operator (^) with int Summary: optimize cmp_ne(xor(X,1),0) to cmp_eq(X,0) only for boolean values X. Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6956668/Test6956668.java Changeset: ba550512d3b2 Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba550512d3b2 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. Reviewed-by: never ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: c76d5f44a3fe Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c76d5f44a3fe 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM Summary: change the default setting of the flag AllowInvokeGeneric to false Reviewed-by: never ! src/share/vm/runtime/globals.hpp Changeset: deaa3ce90583 Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/deaa3ce90583 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Summary: Removed extra change from another bug fix that caused this regression Reviewed-by: phh, dcubed, kvn, kamg, never ! src/share/vm/oops/methodOop.cpp Changeset: e5ae807761b8 Author: trims Date: 2011-06-03 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e5ae807761b8 Added tag hs21-b14 for changeset 62f39d40ebf1 ! .hgtags Changeset: 82a81d5c5700 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/82a81d5c5700 Merge Changeset: 48ceeec759b6 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/48ceeec759b6 Added tag jdk7-b145 for changeset 82a81d5c5700 ! .hgtags Changeset: 12537a93a848 Author: asaha Date: 2011-04-08 21:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/12537a93a848 Merge Changeset: 540930dc854d Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/540930dc854d 7020373: JSR rewriting can overflow memory address size variables Summary: Abort if incoming classfile's parameters would cause overflows Reviewed-by: coleenp, dcubed, never ! src/share/vm/oops/generateOopMap.cpp + test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: f0914807c671 Author: asaha Date: 2011-04-20 07:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f0914807c671 Merge Changeset: bad27cd3f646 Author: asaha Date: 2011-04-21 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bad27cd3f646 Merge Changeset: 5e00ed79c8bb Author: asaha Date: 2011-04-21 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5e00ed79c8bb Merge Changeset: c97b08c7d72a Author: asaha Date: 2011-04-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c97b08c7d72a Merge Changeset: 5def270bc147 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5def270bc147 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls. Reviewed-by: acorn, dcubed, ohair, alanb ! make/windows/makefiles/compile.make ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp Changeset: 089aee76df10 Author: asaha Date: 2011-05-04 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/089aee76df10 Merge ! src/os/windows/vm/os_windows.cpp Changeset: ba2db55ddf8b Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba2db55ddf8b Merge - make/linux/makefiles/cscope.make - make/solaris/makefiles/cscope.make Changeset: 66c17ec20ee2 Author: asaha Date: 2011-05-06 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/66c17ec20ee2 Merge Changeset: 7c948af3e651 Author: asaha Date: 2011-05-24 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7c948af3e651 Merge ! src/os/windows/vm/os_windows.cpp Changeset: ec7055a259a6 Author: asaha Date: 2011-05-26 17:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ec7055a259a6 Merge Changeset: 8d5208b557b3 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8d5208b557b3 Merge Changeset: 7bf54248da9f Author: asaha Date: 2011-06-06 10:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7bf54248da9f Merge Changeset: a983caeb2b3e Author: asaha Date: 2011-06-03 07:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a983caeb2b3e Merge Changeset: 0e9653efc6ea Author: asaha Date: 2011-06-06 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e9653efc6ea Merge Changeset: a884a8b0ec6d Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a884a8b0ec6d 7055247: Ignore test of # 7020373 Reviewed-by: dcubed ! test/runtime/7020373/Test7020373.sh Changeset: 9d7c66d9a203 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9d7c66d9a203 Merge Changeset: f56542cb325a Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f56542cb325a 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: kvn, jrose ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: f7d55ea6ee56 Author: never Date: 2011-06-03 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f7d55ea6ee56 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 293f68bda347 Author: kvn Date: 2011-06-04 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/293f68bda347 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already. Reviewed-by: iveresov, never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp Changeset: 14d3cdeabc9f Author: trims Date: 2011-06-07 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/14d3cdeabc9f Added tag hs21-b15 for changeset 82a81d5c5700 ! .hgtags Changeset: 67c0f5f5deac Author: trims Date: 2011-06-07 16:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/67c0f5f5deac Merge Changeset: 07c2e7ffd1fc Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07c2e7ffd1fc 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Reviewed-by: never, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/code/pcDesc.cpp Changeset: 15e7628f9e92 Author: trims Date: 2011-06-16 19:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/15e7628f9e92 Merge Changeset: fc043ce2136c Author: trims Date: 2011-06-16 19:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc043ce2136c 7055788: Bump the HS21 build number to 16 Summary: Update the HS21 build number to 16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: a9b8b43b115f Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a9b8b43b115f 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Reviewed-by: twisti, kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: 3275a6560cf7 Author: twisti Date: 2011-06-14 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3275a6560cf7 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: iveresov, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 38fa55e5e792 Author: never Date: 2011-06-16 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/38fa55e5e792 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp From lana.steuck at oracle.com Mon Jun 20 14:59:22 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 20 Jun 2011 21:59:22 +0000 Subject: hg: jdk7/tl/jdk: 52 new changesets Message-ID: <20110620220803.CCB6947192@hg.openjdk.java.net> Changeset: 8318d03e1766 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8318d03e1766 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. Reviewed-by: never ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 0b8b6eace473 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0b8b6eace473 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. Reviewed-by: kvn, never ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: 34481a4012c3 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/34481a4012c3 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) Reviewed-by: never ! test/java/lang/invoke/RicochetTest.java Changeset: 802994506203 Author: jrose Date: 2011-06-03 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/802994506203 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Reviewed-by: kvn, never, ysr ! src/share/classes/java/lang/invoke/SwitchPoint.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: e8e6cdff5995 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8e6cdff5995 Merge Changeset: 8f19b165347b Author: bae Date: 2011-06-04 23:08 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8f19b165347b 7042594: 3 testis api/java_awt/Color/ICC_ProfileRGB/index.html fail against RI b138 OEL6x64. Reviewed-by: prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java + test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: bbb4cef2208b Author: lana Date: 2011-06-04 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bbb4cef2208b Merge Changeset: 03a828e368ca Author: rupashka Date: 2011-06-04 01:13 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03a828e368ca 6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Changeset: 6c9c55ae313b Author: lana Date: 2011-06-03 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c9c55ae313b Merge Changeset: e81d259442ed Author: lana Date: 2011-06-04 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e81d259442ed Merge Changeset: 1e04b38b3824 Author: lana Date: 2011-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1e04b38b3824 Merge Changeset: 7a341c412ea9 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7a341c412ea9 Added tag jdk7-b145 for changeset 1e04b38b3824 ! .hgtags Changeset: ae731399e525 Author: dav Date: 2011-06-07 22:58 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae731399e525 7048568: Crash in Java_sun_awt_Win32GraphicsEnvironment_isVistaOS Reviewed-by: dcherepanov, art, amenkov ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: f08fcae94813 Author: lana Date: 2011-06-10 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f08fcae94813 Merge Changeset: 646ab254ff80 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/646ab254ff80 Merge Changeset: aca0dc2b921c Author: weijun Date: 2011-02-09 11:50 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aca0dc2b921c 6618658: Deserialization allows creation of mutable SignedObject Reviewed-by: hawtin, mullan ! src/share/classes/java/security/SignedObject.java + test/java/security/SignedObject/Correctness.java Changeset: df445f522425 Author: bae Date: 2011-02-17 12:21 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df445f522425 7013519: [parfait] Integer overflows in 2D code Reviewed-by: prr, valeriep ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: ccb2fcfb6d6b Author: chegar Date: 2011-02-18 13:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ccb2fcfb6d6b 7013969: NetworkInterface.toString can reveal bindings Reviewed-by: alanb, michaelm, hawtin ! src/share/classes/java/net/NetworkInterface.java Changeset: 026adaac71f1 Author: dcherepanov Date: 2011-02-25 15:54 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/026adaac71f1 7012520: Heap overflow vulnerability in FileDialog.show() Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: d489f00d6c65 Author: flar Date: 2011-03-02 05:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d489f00d6c65 7016495: Crash in Java 2D transforming an image with scale close to zero Reviewed-by: prr, bae ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/java2d/loops/TransformHelper.c + test/java/awt/image/BufferedImage/TinyScale.java Changeset: fe27fe44ac51 Author: ksrini Date: 2011-03-03 14:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fe27fe44ac51 7016985: (launcher) implement safe secure dll loading Reviewed-by: mchung ! src/windows/bin/java_md.c Changeset: 0efa64f13302 Author: chegar Date: 2011-04-05 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0efa64f13302 7033865: JDK: Add private API for secure/restrictive loading of system dlls Reviewed-by: alanb ! src/share/native/common/jdk_util.h + src/solaris/native/common/jdk_util_md.h ! src/windows/native/common/jdk_util_md.c + src/windows/native/common/jdk_util_md.h Changeset: 67992a58bfba Author: ksrini Date: 2011-04-05 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/67992a58bfba 7032593: DLL_LOADING: Upgrade solution to 7016985 to reflect JDK7 solution Reviewed-by: mchung, asaha ! src/windows/bin/java_md.c Changeset: 7181441faf72 Author: dcherepanov Date: 2011-04-08 16:44 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7181441faf72 7003962: AWT: securely load DLLs and launch executables using fully qualified path Reviewed-by: art, bae, alanb ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/stdhdrs.h Changeset: 05a3923f516f Author: dcherepanov Date: 2011-04-08 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05a3923f516f 7035077: Minor addition to the changes for 7003962 Reviewed-by: chegar ! src/windows/native/sun/windows/DllUtil.cpp Changeset: afcc1530e68b Author: asaha Date: 2011-04-08 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/afcc1530e68b Merge - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/MethodType.java - src/share/classes/java/dyn/MethodTypeForm.java - src/share/classes/java/dyn/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/ValueConversions.java - src/share/classes/sun/dyn/util/VerifyAccess.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 557bd9b5d92f Author: asaha Date: 2011-04-08 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/557bd9b5d92f Merge Changeset: e142148d8b54 Author: asaha Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e142148d8b54 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 76e0e562b617 Author: dcherepanov Date: 2011-04-15 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/76e0e562b617 7036952: build warning after the changes for 7003962 Reviewed-by: art, bae ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h Changeset: f8eddc85cc02 Author: zgu Date: 2011-04-15 09:53 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8eddc85cc02 7003964: SERV: securely load DLLs and launch executables using fully qualified path Summary: Linked in Windows libraries that are available on jdk7 supported platforms, and used GetModuleHandle instead of LoadLibrary for already loaded Dlls. Reviewed-by: dcubed, alanb ! make/com/sun/tools/attach/Makefile ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h Changeset: 0865aa0ad9b2 Author: zgu Date: 2011-04-19 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0865aa0ad9b2 Merge Changeset: 6f8a4d334fb2 Author: asaha Date: 2011-04-20 09:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f8a4d334fb2 Merge ! make/com/sun/tools/attach/Makefile ! src/share/classes/java/net/NetworkInterface.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/windows/bin/java_md.c ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: f3645b5d6e62 Author: asaha Date: 2011-04-20 21:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f3645b5d6e62 Merge Changeset: b626f78c57e1 Author: asaha Date: 2011-04-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b626f78c57e1 Merge Changeset: cec45f3353be Author: asaha Date: 2011-04-21 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cec45f3353be Merge Changeset: 6133c9ee3a01 Author: asaha Date: 2011-04-21 08:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6133c9ee3a01 Merge Changeset: dd06e8d3da91 Author: asaha Date: 2011-04-21 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd06e8d3da91 Merge Changeset: b2295905901a Author: asaha Date: 2011-04-21 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b2295905901a Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 3fedf261fb4f Author: valeriep Date: 2011-04-26 15:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3fedf261fb4f 7003952: SEC: securely load DLLs and launch executables using fully qualified path Summary: Enforce full path when specifying library locations. Reviewed-by: wetmore, ohair ! make/sun/security/pkcs11/Makefile ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/native/sun/security/pkcs11/j2secmod.c + test/sun/security/pkcs11/Provider/Absolute.cfg + test/sun/security/pkcs11/Provider/Absolute.java Changeset: 94ea3b8288f1 Author: alexp Date: 2011-05-04 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94ea3b8288f1 7020198: ImageIcon creates Component with null acc Reviewed-by: rupashka, hawtin ! src/share/classes/javax/swing/ImageIcon.java Changeset: e6fdfb249e31 Author: asaha Date: 2011-05-04 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6fdfb249e31 Merge - src/share/native/sun/font/layout/Features.h ! src/windows/native/sun/windows/awt_FileDialog.cpp - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: 49244980d692 Author: asaha Date: 2011-05-05 22:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49244980d692 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java Changeset: 647b031200f0 Author: asaha Date: 2011-05-06 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/647b031200f0 Merge Changeset: 92b5197e9ff5 Author: asaha Date: 2011-05-26 21:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92b5197e9ff5 Merge ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: cca9ea306c6e Author: asaha Date: 2011-05-26 21:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cca9ea306c6e Merge Changeset: dab3e66ebda7 Author: lana Date: 2011-06-06 19:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dab3e66ebda7 Merge Changeset: 9f17be5136d1 Author: wetmore Date: 2011-06-09 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9f17be5136d1 7052537: java/security/Security/NotInstalledProviders.java is causing -samevm tests to fail. Reviewed-by: valeriep, asaha, alanb ! test/java/security/Security/NoInstalledProviders.java Changeset: 4961be00d3b5 Author: lana Date: 2011-06-15 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4961be00d3b5 Merge Changeset: cf0632d2db2c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf0632d2db2c 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/SwitchPoint.java + test/java/lang/invoke/PermuteArgsTest.java Changeset: a65fa0f6717e Author: trims Date: 2011-06-17 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a65fa0f6717e Merge Changeset: c102e1221afa Author: lana Date: 2011-06-17 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c102e1221afa Merge Changeset: 539e576793a8 Author: lana Date: 2011-06-18 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/539e576793a8 Merge From joe.darcy at oracle.com Mon Jun 20 17:21:09 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 21 Jun 2011 00:21:09 +0000 Subject: hg: jdk8/tl/jdk: 7055295: (reflect) add conventional constructor to GenericSignatureFormatError Message-ID: <20110621002131.4BCCA471A5@hg.openjdk.java.net> Changeset: 3c8f939ced1c Author: darcy Date: 2011-06-20 17:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c8f939ced1c 7055295: (reflect) add conventional constructor to GenericSignatureFormatError Reviewed-by: lancea, mduigou ! src/share/classes/java/lang/reflect/GenericSignatureFormatError.java From jperkins at redhat.com Mon Jun 20 17:24:24 2011 From: jperkins at redhat.com (James Perkins) Date: Mon, 20 Jun 2011 17:24:24 -0700 Subject: Filer.getResource() always throws FileNotFoundException Message-ID: <4DFFE4B8.1070505@redhat.com> The implementation of javax.annotation.processing.Filer (com.sun.tools.javac.processing.JavacFiler.java) always throws a FileNotFoundException when invoking getResource(). This appears to be a bug introduced in commit http://hg.openjdk.java.net/jdk7/jdk7/langtools/diff/f3323b1c65ee/src/share/classes/com/sun/tools/javac/processing/JavacFiler.java. The method should be using JavaFileManager.getFileForOutput() not JavaFileManager.getFileForInput(). My testing with the following change works: public FileObject getResource(JavaFileManager.Location location, CharSequence pkg, CharSequence relativeName) throws IOException { String strPkg = pkg.toString(); if (strPkg.length() > 0) checkName(strPkg); // TODO: Only support reading resources in selected output // locations? Only allow reading of non-source, non-class // files from the supported input locations? FileObject fileObject = fileManager.getFileForOutput(location, pkg.toString(), relativeName.toString(), null); if (fileObject == null) { String name = (pkg.length() == 0) ? relativeName.toString() : (pkg + "/" + relativeName); throw new FileNotFoundException(name); } // If the path was already opened for writing, throw an exception. checkFileReopening(fileObject, false); return new FilerInputFileObject(fileObject); } I have filed an issue for this already http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057153. Not sure what I did wrong, but the bugs not showing up for me yet. -- James R. Perkins JBoss by Red Hat From schlosna at gmail.com Tue Jun 21 05:40:48 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Tue, 21 Jun 2011 08:40:48 -0400 Subject: Proposed javac argument processing performance improvement In-Reply-To: <4DFAD1F4.8090503@oracle.com> References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> <4DF7EFF6.2030300@oracle.com> <4DFAD1F4.8090503@oracle.com> Message-ID: On Fri, Jun 17, 2011 at 12:03 AM, Jonathan Gibbons wrote: > Dave, > > Thanks for the update, and for looking at making your patch work even > faster. > > For a perf-related change like this, no new regression tests will be > necessary. > The normal rules in a case like this are to make sure that nothing is > broken, > meaning that all the (langtools) tests should still pass and that it should > still > be capable to build the OpenJDK forest. Normally, it is sufficient to do a > regular > build of OpenJDK; in some circumstances, it would be expected to pass a > build with SKIP_BOOT_CYCLE=false, meaning that it should be able to build > OpenJDK -- and the result should itself be capable of building OpenJDK. This > double build verifies that the bits from the first build are good enough to > function as a BOOT_JDK. ?But, I don't think the double build is necessary in > this case, > since this is a relatively simple change related to command line processing. > > Normally, all the langtools tests should pass all time time, on all > supported > platforms (Linux, Windows, Solaris.) I haven't checked out the Mac port > recently > to see how the tests perform on that platform. > > -- Jon Here's the updated patch using Iterable throughout, and the results are similar to the previous patch. Let me know if there is anything else I can do to get this through the process. On an aside, I tried to keep the IllegalArgumentException thrown in JavacTaskImpl consistent with the previous message; however, the code is much messier now (this just begs for something like Guava's Joiner) and I'd prefer using something simpler along the lines of throw new IllegalArgumentException("Malformed arguments " + filenames);. That would have the realistic effect of moving from a space delimited list of filename arguments to a comma and space delimited and surrounded by square brackets per AbstractCollection#toString(). I've included timings for several different size real world modules compiled with javac on Windows XP SP2 (where I had seen the worst performance to start). All times are in milliseconds. With the changes, processArgs is consistently sub-second, and linear in time relative to the number of input files. | Before | After | Delta | # files | processArgs | javac | processArgs | javac | processArgs | javac | --------+-------------+-------+-------------+-------+-------------+---------+ 5522 | 16170.863 | 48163 | 280.484 | 37087 | -15890.379 | -11075 | 4436 | 9498.519 | 61043 | 200.735 | 49452 | -9297.784 | -11591 | 268 | 57.270 | 5775 | 16.923 | 5641 | -40.347 | -134 | 154 | 28.571 | 3147 | 11.322 | 2985 | -17.249 | -161 | 101 | 14.486 | 40621 | 7.814 | 40214 | -6.672 | -407 | 73 | 12.277 | 12180 | 6.677 | 12125 | -5.600 | -55 | 8 | 1.695 | 1718 | 1.309 | 1643 | -0.386 | -74 | 4 | 1.500 | 2098 | 1.399 | 2000 | -0.101 | -98 | 1 | 1.035 | 1442 | 0.911 | 1294 | -0.124 | -148 | Thanks, - Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: javac-iterable-args.patch Type: application/octet-stream Size: 6864 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110621/e531406f/javac-iterable-args.patch From alan.bateman at oracle.com Tue Jun 21 08:12:39 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 Jun 2011 15:12:39 +0000 Subject: hg: jdk8/tl/jdk: 7056815: test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh times out intermittently on busy machine Message-ID: <20110621151248.EE68C471CF@hg.openjdk.java.net> Changeset: 70f14c2db078 Author: alanb Date: 2011-06-21 16:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70f14c2db078 7056815: test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh times out intermittently on busy machine Reviewed-by: mchung ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh From alan.bateman at oracle.com Wed Jun 22 07:14:39 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 22 Jun 2011 14:14:39 +0000 Subject: hg: jdk8/tl/jdk: 7056447: test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java fails in agentvm Message-ID: <20110622141507.DFCFC4721F@hg.openjdk.java.net> Changeset: 0bde4bed86e5 Author: alanb Date: 2011-06-22 15:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bde4bed86e5 7056447: test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java fails in agentvm Reviewed-by: emcmanus ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java From jeff.dinkins at oracle.com Wed Jun 22 11:06:38 2011 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Wed, 22 Jun 2011 18:06:38 +0000 Subject: hg: jdk7/tl: 7057046: Add embedded license to THIRD PARTY README Message-ID: <20110622180638.D316547228@hg.openjdk.java.net> Changeset: 8da980eedab6 Author: jeff Date: 2011-06-22 10:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/8da980eedab6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Wed Jun 22 11:06:57 2011 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Wed, 22 Jun 2011 18:06:57 +0000 Subject: hg: jdk7/tl/corba: 7057046: Add embedded license to THIRD PARTY README Message-ID: <20110622180659.42B9A47229@hg.openjdk.java.net> Changeset: bba0e37d7006 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/bba0e37d7006 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Wed Jun 22 11:07:33 2011 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Wed, 22 Jun 2011 18:07:33 +0000 Subject: hg: jdk7/tl/hotspot: 7057046: Add embedded license to THIRD PARTY README Message-ID: <20110622180742.DE82F4722A@hg.openjdk.java.net> Changeset: f6ba9007b2c6 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f6ba9007b2c6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Wed Jun 22 11:09:11 2011 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Wed, 22 Jun 2011 18:09:11 +0000 Subject: hg: jdk7/tl/jaxp: 7057046: Add embedded license to THIRD PARTY README Message-ID: <20110622180911.91F714722B@hg.openjdk.java.net> Changeset: eed2486cb10b Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/eed2486cb10b 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Wed Jun 22 11:09:26 2011 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Wed, 22 Jun 2011 18:09:26 +0000 Subject: hg: jdk7/tl/jaxws: 7057046: Add embedded license to THIRD PARTY README Message-ID: <20110622180926.B7A834722C@hg.openjdk.java.net> Changeset: 632e38191caa Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/632e38191caa 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Wed Jun 22 11:09:39 2011 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Wed, 22 Jun 2011 18:09:39 +0000 Subject: hg: jdk7/tl/jdk: 7057046: Add embedded license to THIRD PARTY README Message-ID: <20110622181012.A0AEC4722D@hg.openjdk.java.net> Changeset: cfd7602f5c52 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cfd7602f5c52 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Wed Jun 22 11:11:24 2011 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Wed, 22 Jun 2011 18:11:24 +0000 Subject: hg: jdk7/tl/langtools: 7057046: Add embedded license to THIRD PARTY README Message-ID: <20110622181128.193864722E@hg.openjdk.java.net> Changeset: a72412b148d7 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a72412b148d7 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README From joe.darcy at oracle.com Wed Jun 22 17:07:26 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 23 Jun 2011 00:07:26 +0000 Subject: hg: jdk8/tl/langtools: 6449184: Provide JavacProcessingEnvironment.getWriter Message-ID: <20110623000731.38FB24724B@hg.openjdk.java.net> Changeset: 4844a9fd3a62 Author: darcy Date: 2011-06-22 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4844a9fd3a62 6449184: Provide JavacProcessingEnvironment.getWriter Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/util/T6597678.java From weijun.wang at oracle.com Wed Jun 22 18:27:29 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 23 Jun 2011 01:27:29 +0000 Subject: hg: jdk8/tl/jdk: 7055362: jdk_security2 test target cleanup Message-ID: <20110623012748.1C45647250@hg.openjdk.java.net> Changeset: febb7f557135 Author: weijun Date: 2011-06-23 09:27 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/febb7f557135 7055362: jdk_security2 test target cleanup Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt ! test/com/sun/crypto/provider/Cipher/DES/Sealtest.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP_KAT.java ! test/javax/crypto/EncryptedPrivateKeyInfo/GetKeySpecException.java ! test/javax/crypto/JceSecurity/SunJCE_BC_LoadOrdering.java From xuelei.fan at oracle.com Wed Jun 22 19:39:34 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 23 Jun 2011 02:39:34 +0000 Subject: hg: jdk8/tl/jdk: 6952814: sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java failing in PIT Message-ID: <20110623023944.952C147253@hg.openjdk.java.net> Changeset: 3b7193ab0d87 Author: xuelei Date: 2011-06-22 19:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b7193ab0d87 6952814: sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java failing in PIT Reviewed-by: alanb - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java From xuelei.fan at oracle.com Wed Jun 22 21:21:52 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 23 Jun 2011 04:21:52 +0000 Subject: hg: jdk8/tl/jdk: 7058271: Remove InterruptedIO.java record from ProblemList.txt Message-ID: <20110623042202.2746447258@hg.openjdk.java.net> Changeset: 57265bf4b36b Author: xuelei Date: 2011-06-22 21:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57265bf4b36b 7058271: Remove InterruptedIO.java record from ProblemList.txt Reviewed-by: weijun ! test/ProblemList.txt From chris.hegarty at oracle.com Thu Jun 23 04:00:58 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 23 Jun 2011 11:00:58 +0000 Subject: hg: jdk8/tl/jdk: 7057935: com/sun/nio/sctp tests should be moved out of jdk_nio and into their own target, jdk_sctp Message-ID: <20110623110118.EB03047267@hg.openjdk.java.net> Changeset: 6b2c14dfe9b9 Author: chegar Date: 2011-06-23 13:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b2c14dfe9b9 7057935: com/sun/nio/sctp tests should be moved out of jdk_nio and into their own target, jdk_sctp Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt From chris.hegarty at oracle.com Thu Jun 23 04:16:04 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 23 Jun 2011 11:16:04 +0000 Subject: hg: jdk8/tl/jdk: 7021010: java/lang/Thread/ThreadStateTest.java fails intermittently Message-ID: <20110623111614.1B93447268@hg.openjdk.java.net> Changeset: ae7211979179 Author: chegar Date: 2011-06-23 13:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae7211979179 7021010: java/lang/Thread/ThreadStateTest.java fails intermittently Reviewed-by: dholmes, alanb, mchung ! test/ProblemList.txt ! test/java/lang/Thread/ThreadStateTest.java From xuelei.fan at oracle.com Thu Jun 23 04:25:02 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 23 Jun 2011 11:25:02 +0000 Subject: hg: jdk8/tl/jdk: 7057022: test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java has invalid jtreg tags Message-ID: <20110623112512.042954726A@hg.openjdk.java.net> Changeset: cd7adb545f71 Author: xuelei Date: 2011-06-23 04:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd7adb545f71 7057022: test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java has invalid jtreg tags Reviewed-by: weijun ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java From jonathan.gibbons at oracle.com Thu Jun 23 11:49:47 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 23 Jun 2011 18:49:47 +0000 Subject: hg: jdk8/tl/langtools: 7058174: Reduce langtools build warnings Message-ID: <20110623184949.E19194727D@hg.openjdk.java.net> Changeset: 18002d039806 Author: jjg Date: 2011-06-23 11:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/18002d039806 7058174: Reduce langtools build warnings Reviewed-by: jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/build.xml ! make/tools/CompileProperties/CompileProperties.java From joe.darcy at oracle.com Thu Jun 23 14:58:17 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 23 Jun 2011 21:58:17 +0000 Subject: hg: jdk8/tl/jdk: 6253144: Long narrowing conversion should describe the algorithm used and implied "risks" Message-ID: <20110623215838.983EE4728C@hg.openjdk.java.net> Changeset: 151756a4037b Author: darcy Date: 2011-06-23 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/151756a4037b 6253144: Long narrowing conversion should describe the algorithm used and implied "risks" Reviewed-by: mduigou, alanb ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Number.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java From lana.steuck at oracle.com Thu Jun 23 17:31:49 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 24 Jun 2011 00:31:49 +0000 Subject: hg: jdk8/tl: 7 new changesets Message-ID: <20110624003150.2276D4729B@hg.openjdk.java.net> Changeset: 4373d87e6f37 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4373d87e6f37 Added tag jdk7-b144 for changeset 7203965666a4 ! .hgtags Changeset: 93d2590fd849 Author: jeff Date: 2011-05-27 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/93d2590fd849 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 55e9ebf03218 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/55e9ebf03218 Merge Changeset: 2d38c2a79c14 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2d38c2a79c14 Added tag jdk7-b145 for changeset 55e9ebf03218 ! .hgtags Changeset: 404bd0b9385f Author: schien Date: 2011-06-08 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/404bd0b9385f Merge Changeset: 3e0b96f8f6a0 Author: schien Date: 2011-06-20 16:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3e0b96f8f6a0 Added tag jdk7-b146 for changeset 2d38c2a79c14 ! .hgtags Changeset: 29e7e1474b5e Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/29e7e1474b5e Merge From lana.steuck at oracle.com Thu Jun 23 17:32:03 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 24 Jun 2011 00:32:03 +0000 Subject: hg: jdk8/tl/jaxws: 18 new changesets Message-ID: <20110624003204.198C44729C@hg.openjdk.java.net> Changeset: 6158298d2b94 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6158298d2b94 Added tag jdk7-b144 for changeset 6bd683f2d527 ! .hgtags Changeset: c902e39c384e Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c902e39c384e 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: bcca8afc019f Author: ohair Date: 2011-06-01 10:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bcca8afc019f 7049699: Problem with xml/jax-ws Reviewed-by: ramap ! jaxws.properties Changeset: 42bfba80beb7 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/42bfba80beb7 Merge Changeset: 6ec12c60ad13 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6ec12c60ad13 Added tag jdk7-b145 for changeset 42bfba80beb7 ! .hgtags Changeset: 1b7851b9e113 Author: schien Date: 2011-06-08 10:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1b7851b9e113 Merge Changeset: 581dab3f0773 Author: asaha Date: 2011-04-21 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/581dab3f0773 Merge Changeset: 26610bb80151 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/26610bb80151 Merge Changeset: c6ff860428c7 Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c6ff860428c7 Merge Changeset: f4e1caef46d0 Author: asaha Date: 2011-05-24 11:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f4e1caef46d0 Merge Changeset: 9896cee00786 Author: asaha Date: 2011-05-26 17:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9896cee00786 Merge Changeset: d1febdcb0351 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d1febdcb0351 Merge Changeset: 239c80c331da Author: asaha Date: 2011-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/239c80c331da Merge Changeset: 09412171ca4b Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/09412171ca4b Merge Changeset: 9d8fd0982fb8 Author: asaha Date: 2011-06-06 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9d8fd0982fb8 Merge Changeset: 05469dd4c366 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/05469dd4c366 Merge Changeset: faa394edbfe3 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/faa394edbfe3 Added tag jdk7-b146 for changeset 05469dd4c366 ! .hgtags Changeset: 9244c440c0df Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9244c440c0df Merge From lana.steuck at oracle.com Thu Jun 23 17:32:07 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 24 Jun 2011 00:32:07 +0000 Subject: hg: jdk8/tl/jaxp: 9 new changesets Message-ID: <20110624003207.83B724729D@hg.openjdk.java.net> Changeset: bee49f47043f Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bee49f47043f Added tag jdk7-b144 for changeset 39bf6dcaab23 ! .hgtags Changeset: bdf77cbd9958 Author: ohair Date: 2011-05-19 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bdf77cbd9958 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop Reviewed-by: joehw ! jaxp.properties Changeset: 775dd77e4730 Author: lana Date: 2011-05-20 21:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/775dd77e4730 Merge Changeset: a70a042c8600 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a70a042c8600 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 10ca7570f47f Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/10ca7570f47f Merge Changeset: bcd31fa1e3c6 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bcd31fa1e3c6 Added tag jdk7-b145 for changeset 10ca7570f47f ! .hgtags Changeset: bae5f389d17b Author: schien Date: 2011-06-08 10:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bae5f389d17b Merge Changeset: 9a4d09f33f01 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9a4d09f33f01 Added tag jdk7-b146 for changeset bcd31fa1e3c6 ! .hgtags Changeset: 03692de33ca8 Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/03692de33ca8 Merge From lana.steuck at oracle.com Thu Jun 23 17:31:55 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 24 Jun 2011 00:31:55 +0000 Subject: hg: jdk8/tl/corba: 10 new changesets Message-ID: <20110624003212.371074729E@hg.openjdk.java.net> Changeset: 7033a5756ad5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7033a5756ad5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java Changeset: 74eb715474f2 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/74eb715474f2 Added tag jdk7-b144 for changeset 7033a5756ad5 ! .hgtags Changeset: 93e77c49b3bb Author: miroslawzn Date: 2011-05-26 13:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/93e77c49b3bb 7046882: Regression : JDK 7b123 : Enum exchanged as parameters using CORBA call results in Exception Reviewed-by: raginip ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 643f267ca234 Author: jeff Date: 2011-05-27 14:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/643f267ca234 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 7839048ec99e Author: jeff Date: 2011-05-27 15:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7839048ec99e Merge Changeset: 77ec0541aa2a Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/77ec0541aa2a Merge Changeset: 770227a4087e Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/770227a4087e Added tag jdk7-b145 for changeset 77ec0541aa2a ! .hgtags Changeset: e85ff90212ad Author: schien Date: 2011-06-08 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e85ff90212ad Merge Changeset: 36f0efbc66ef Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/36f0efbc66ef Added tag jdk7-b146 for changeset 770227a4087e ! .hgtags Changeset: abe4723b9b7f Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/abe4723b9b7f Merge From lana.steuck at oracle.com Thu Jun 23 17:32:24 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 24 Jun 2011 00:32:24 +0000 Subject: hg: jdk8/tl/langtools: 27 new changesets Message-ID: <20110624003321.4549C4729F@hg.openjdk.java.net> Changeset: 8eb952f43b11 Author: katleman Date: 2011-05-25 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8eb952f43b11 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! test/tools/javac/4241573/T4241573.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/TryWithResources/DuplicateResource.java ! test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/T6838467.java ! test/tools/javac/api/T6877206.java ! test/tools/javac/api/TestClientCodeWrapper.java ! test/tools/javac/api/TestJavacTask_Lock.java ! test/tools/javac/api/TestJavacTask_Multiple.java ! test/tools/javac/api/TestJavacTask_ParseAttrGen.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/tree/T6963934.java Changeset: 9f25c6a3ac23 Author: schien Date: 2011-05-26 20:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f25c6a3ac23 Added tag jdk7-b144 for changeset 8eb952f43b11 ! .hgtags Changeset: 6bb526ccf5ff Author: mcimadamore Date: 2011-05-23 11:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6bb526ccf5ff 7046348: Regression: javac complains of missing classfile for a seemingly unrelated interface Summary: Types.implementation forces unnecessary symbol completion on superinterfaces of a given type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: 6211df69f7e0 Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6211df69f7e0 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 6762754eb7c0 Author: jjg Date: 2011-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6762754eb7c0 7042623: Regression: javac silently crash when attributing non-existent annotation Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T7042623.java + test/tools/javac/T7042623.out Changeset: c455e2ae5c93 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c455e2ae5c93 Merge Changeset: 9ff91d0e7154 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9ff91d0e7154 Added tag jdk7-b145 for changeset c455e2ae5c93 ! .hgtags Changeset: f27b6f45a449 Author: schien Date: 2011-06-08 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f27b6f45a449 Merge Changeset: 347349c981f2 Author: jjh Date: 2011-06-09 09:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/347349c981f2 7052782: Two langtools regression tests fail due to fix for 7034977 which removed the invokeGeneric method Summary: Change the tests to call invoke instead of invokeGeneric Reviewed-by: jrose, mcimadamore ! test/tools/javac/meth/InvokeMH.java ! test/tools/javac/meth/XlintWarn.java Changeset: b8a2c9c87018 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b8a2c9c87018 Merge Changeset: 588d366d96df Author: asaha Date: 2011-04-21 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/588d366d96df Merge Changeset: 219b522d09e4 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/219b522d09e4 Merge Changeset: 145d832616d3 Author: asaha Date: 2011-05-05 22:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/145d832616d3 Merge Changeset: 8b6e015ae7d0 Author: asaha Date: 2011-05-24 11:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b6e015ae7d0 Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 35cc19ae29b5 Author: asaha Date: 2011-05-26 17:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/35cc19ae29b5 Merge Changeset: 8b65930602c3 Author: asaha Date: 2011-05-26 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b65930602c3 Merge Changeset: 0adb806caf9d Author: asaha Date: 2011-06-06 10:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0adb806caf9d Merge Changeset: bb1fdcebde01 Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb1fdcebde01 Merge Changeset: 8ed03b0e3c9c Author: asaha Date: 2011-06-06 11:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8ed03b0e3c9c Merge Changeset: f494ca4bca0d Author: lana Date: 2011-06-15 16:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f494ca4bca0d Merge Changeset: 7eba9df190ae Author: bpatel Date: 2011-06-17 20:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7eba9df190ae 7052425: Change the look and feel of the javadoc generate HTML pages using stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: c3a3440fe6e8 Author: bpatel Date: 2011-06-17 20:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c3a3440fe6e8 Merge Changeset: 9425dd4f53d5 Author: schien Date: 2011-06-18 09:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9425dd4f53d5 Merge Changeset: 436fb6aeda5a Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/436fb6aeda5a Added tag jdk7-b146 for changeset 9425dd4f53d5 ! .hgtags Changeset: 06b6bbbe2787 Author: schien Date: 2011-06-20 17:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/06b6bbbe2787 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: d59414955614 Author: lana Date: 2011-06-22 23:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d59414955614 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: 9eb36cac6b64 Author: lana Date: 2011-06-23 17:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9eb36cac6b64 Merge From lana.steuck at oracle.com Thu Jun 23 17:35:52 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 24 Jun 2011 00:35:52 +0000 Subject: hg: jdk8/tl/jdk: 93 new changesets Message-ID: <20110624005043.95DA0472A0@hg.openjdk.java.net> Changeset: 23bdcede4e39 Author: katleman Date: 2011-05-25 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23bdcede4e39 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/keytool.1 ! src/share/classes/java/io/SerialCallbackContext.java ! src/share/classes/sun/io/ByteToCharCp833.java ! src/share/classes/sun/io/CharToByteCp833.java ! src/share/classes/sun/misc/FpUtils.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! test/com/sun/net/httpserver/Test10.java ! test/java/awt/List/ScrollOutside/ScrollOut.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_1.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_4.java ! test/java/awt/image/IncorrectSampleMaskTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/util/EnumMap/DistinctEntrySetElements.java ! test/java/util/EnumMap/EntrySetIteratorRemoveInvalidatesEntry.java ! test/java/util/EnumMap/SimpleSerialization.java ! test/java/util/EnumSet/LargeEnumIteratorRemoveResilience.java ! test/java/util/EnumSet/SmallEnumIteratorRemoveResilience.java ! test/java/util/Hashtable/SerializationDeadlock.java ! test/java/util/Hashtable/SimpleSerialization.java ! test/java/util/IdentityHashMap/DistinctEntrySetElements.java ! test/java/util/IdentityHashMap/EntrySetIteratorRemoveInvalidatesEntry.java ! test/java/util/Vector/SerializationDeadlock.java ! test/java/util/Vector/SimpleSerialization.java ! test/java/util/concurrent/ConcurrentHashMap/DistinctEntrySetElements.java ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java ! test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor ! test/tools/launcher/TestHelper.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/Utils.java Changeset: c344779fab58 Author: schien Date: 2011-05-26 20:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c344779fab58 Added tag jdk7-b144 for changeset 23bdcede4e39 ! .hgtags Changeset: f09930d526ba Author: jrose Date: 2011-05-26 17:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f09930d526ba 7032323: code changes for JSR 292 EG adjustments to API, through Public Review Summary: API code changes and javadoc changes following JSR 292 Public Review comments, through PFD Reviewed-by: never ! src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/6998541/Test6998541.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/indify/Indify.java Changeset: 81f957f86ba5 Author: jcoomes Date: 2011-05-27 19:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81f957f86ba5 Merge Changeset: bc97b962330e Author: mfang Date: 2011-05-26 20:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc97b962330e 7045184: GTK L&F doesn't have hotkeys in jdk7 b141, while b139 has. Reviewed-by: yhuang, ogino ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties Changeset: 6943c4d9caa3 Author: mfang Date: 2011-05-31 13:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6943c4d9caa3 Merge Changeset: 7c5bc5a807ee Author: dholmes Date: 2011-05-27 19:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c5bc5a807ee 7024120: Verify reduced JRE contents for java 7 Summary: stripped all symbols from libs and executables to reduce JRE size. Restored missing classes needed to pass JCK in headless mode Reviewed-by: bobv, ohair ! make/common/Defs-embedded.gmk ! make/common/Release-embedded.gmk Changeset: f4895b3fe1be Author: dholmes Date: 2011-05-31 17:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4895b3fe1be Merge Changeset: eab27338b3d9 Author: schien Date: 2011-06-01 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eab27338b3d9 Merge Changeset: 8d91855a1f4e Author: prr Date: 2011-05-27 13:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d91855a1f4e 7046587: Outlines in OTF/CFF fonts are misclassified as quadratic curves Reviewed-by: igor ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0b0b92707cf5 Author: bae Date: 2011-05-30 12:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b0b92707cf5 7032904: XRender: Java2Demo : Infinite loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64 Reviewed-by: prr ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 290daca0a693 Author: prr Date: 2011-05-30 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/290daca0a693 7049874: OpenJDK Build breakage fix: freetypescaler.c needs to match updated signature Reviewed-by: lana, igor ! src/share/native/sun/font/freetypeScaler.c Changeset: b351af09bfa3 Author: lana Date: 2011-06-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b351af09bfa3 Merge Changeset: d2081a1f417f Author: bagiras Date: 2011-05-27 11:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d2081a1f417f 7045174: Most of the tests in awt area fails with jdk 7b142 on windows with -Xcheck:jni Reviewed-by: art, denis ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 000a845b1e38 Author: denis Date: 2011-05-28 12:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/000a845b1e38 7046325: Broken links in java.awt.Toolkit's javadoc Reviewed-by: dav, yan ! src/share/classes/java/awt/Toolkit.java Changeset: eab94f59b6dc Author: dcherepanov Date: 2011-05-30 13:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eab94f59b6dc 7045354: Korean IME's Hanja candidate window is not displayed on IMFDemo Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp Changeset: f05164caa490 Author: serb Date: 2011-05-30 17:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f05164caa490 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail Reviewed-by: dcherepanov, dav, art, denis ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: b955226868af Author: lana Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b955226868af Merge Changeset: 1fbaf2b688a6 Author: rupashka Date: 2011-05-24 11:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fbaf2b688a6 7045593: Possible Regression : JTextfield cursor placement behavior algorithm has changed. Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java + test/javax/swing/text/Utilities/bug7045593.java Changeset: 442237d3ec2c Author: rupashka Date: 2011-05-28 11:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/442237d3ec2c 7048204: NPE from NimbusLookAndFeel.addDefault Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/Test7048204.java Changeset: 386516fdf40b Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/386516fdf40b Merge Changeset: 0a80650409e1 Author: mullan Date: 2011-05-24 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a80650409e1 7044443: Permissions resolved incorrectly for jar protocol (Patch from bugs.openjdk.java.net) Reviewed-by: alanb, chegar Contributed-by: dbhole at redhat.com ! src/share/classes/sun/security/provider/PolicyFile.java + test/java/security/Policy/GetPermissions/JarURL.java Changeset: ace2dfdecda1 Author: mullan Date: 2011-05-24 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ace2dfdecda1 Merge Changeset: 70942be348af Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70942be348af 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: b49a0af85821 Author: vinnie Date: 2011-05-30 16:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b49a0af85821 7049173: Replace the software license for ECC native code Reviewed-by: alanb ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: 4ed7c877a463 Author: michaelm Date: 2011-05-30 23:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ed7c877a463 7042550: Reintegrate 6569621 Reviewed-by: chegar, alanb ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java + src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/http/HttpClient.java Changeset: c79a089ae13b Author: wetmore Date: 2011-05-31 12:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c79a089ae13b 7042097: JDK 7's Unlimited Cryptographic Policy bundle text files must be updated. Reviewed-by: valeriep ! make/javax/crypto/Makefile Changeset: a00f48c96345 Author: lancea Date: 2011-06-02 12:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a00f48c96345 7049107: Cannot call initCause() on BatchUpdateException Reviewed-by: darcy ! src/share/classes/java/sql/BatchUpdateException.java Changeset: 39de8937c1d8 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39de8937c1d8 Merge Changeset: 8318d03e1766 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8318d03e1766 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. Reviewed-by: never ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 0b8b6eace473 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b8b6eace473 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. Reviewed-by: kvn, never ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: 34481a4012c3 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34481a4012c3 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) Reviewed-by: never ! test/java/lang/invoke/RicochetTest.java Changeset: 802994506203 Author: jrose Date: 2011-06-03 11:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/802994506203 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Reviewed-by: kvn, never, ysr ! src/share/classes/java/lang/invoke/SwitchPoint.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: e8e6cdff5995 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8e6cdff5995 Merge Changeset: 8f19b165347b Author: bae Date: 2011-06-04 23:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f19b165347b 7042594: 3 testis api/java_awt/Color/ICC_ProfileRGB/index.html fail against RI b138 OEL6x64. Reviewed-by: prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java + test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: bbb4cef2208b Author: lana Date: 2011-06-04 17:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbb4cef2208b Merge Changeset: 03a828e368ca Author: rupashka Date: 2011-06-04 01:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03a828e368ca 6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Changeset: 6c9c55ae313b Author: lana Date: 2011-06-03 22:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c9c55ae313b Merge Changeset: e81d259442ed Author: lana Date: 2011-06-04 17:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e81d259442ed Merge Changeset: 53d759eb580c Author: alanb Date: 2011-06-04 11:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53d759eb580c 7050358: (fs spec) Path.toUri doesn't allow custom providers to use opaque URIs Reviewed-by: sherman ! src/share/classes/java/nio/file/Path.java Changeset: 49aef5a5416e Author: mullan Date: 2011-06-04 06:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49aef5a5416e 7050329: test/java/security/Policy/GetPermissions/JarURL.java fails on Windows Reviewed-by: alanb ! test/java/security/Policy/GetPermissions/JarURL.java + test/java/security/Policy/GetPermissions/JarURL.policy Changeset: 1f39ca0b9598 Author: mullan Date: 2011-06-04 06:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f39ca0b9598 Merge Changeset: 1e04b38b3824 Author: lana Date: 2011-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e04b38b3824 Merge Changeset: 7a341c412ea9 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a341c412ea9 Added tag jdk7-b145 for changeset 1e04b38b3824 ! .hgtags Changeset: e7493c32e598 Author: schien Date: 2011-06-08 10:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7493c32e598 Merge Changeset: ae731399e525 Author: dav Date: 2011-06-07 22:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae731399e525 7048568: Crash in Java_sun_awt_Win32GraphicsEnvironment_isVistaOS Reviewed-by: dcherepanov, art, amenkov ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: f08fcae94813 Author: lana Date: 2011-06-10 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f08fcae94813 Merge Changeset: 6e961c328276 Author: michaelm Date: 2011-06-08 10:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e961c328276 7050028: ISE "zip file closed" from JarURLConnection.getInputStream on JDK 7 when !useCaches Reviewed-by: chegar, alanb ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B7050028.java Changeset: b6ced5ad7a62 Author: dwanvik Date: 2011-06-10 17:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b6ced5ad7a62 7046557: Changes to the Java DB README files in JDK7 Summary: Update /README.html with correct mention of Java DB, add JDK specific README files to /db and /demo/db. Reviewed-by: ohair ! make/common/Release.gmk Changeset: 646ab254ff80 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/646ab254ff80 Merge Changeset: aca0dc2b921c Author: weijun Date: 2011-02-09 11:50 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aca0dc2b921c 6618658: Deserialization allows creation of mutable SignedObject Reviewed-by: hawtin, mullan ! src/share/classes/java/security/SignedObject.java + test/java/security/SignedObject/Correctness.java Changeset: df445f522425 Author: bae Date: 2011-02-17 12:21 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df445f522425 7013519: [parfait] Integer overflows in 2D code Reviewed-by: prr, valeriep ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: ccb2fcfb6d6b Author: chegar Date: 2011-02-18 13:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccb2fcfb6d6b 7013969: NetworkInterface.toString can reveal bindings Reviewed-by: alanb, michaelm, hawtin ! src/share/classes/java/net/NetworkInterface.java Changeset: 026adaac71f1 Author: dcherepanov Date: 2011-02-25 15:54 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/026adaac71f1 7012520: Heap overflow vulnerability in FileDialog.show() Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: d489f00d6c65 Author: flar Date: 2011-03-02 05:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d489f00d6c65 7016495: Crash in Java 2D transforming an image with scale close to zero Reviewed-by: prr, bae ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/java2d/loops/TransformHelper.c + test/java/awt/image/BufferedImage/TinyScale.java Changeset: fe27fe44ac51 Author: ksrini Date: 2011-03-03 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe27fe44ac51 7016985: (launcher) implement safe secure dll loading Reviewed-by: mchung ! src/windows/bin/java_md.c Changeset: 0efa64f13302 Author: chegar Date: 2011-04-05 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0efa64f13302 7033865: JDK: Add private API for secure/restrictive loading of system dlls Reviewed-by: alanb ! src/share/native/common/jdk_util.h + src/solaris/native/common/jdk_util_md.h ! src/windows/native/common/jdk_util_md.c + src/windows/native/common/jdk_util_md.h Changeset: 67992a58bfba Author: ksrini Date: 2011-04-05 16:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67992a58bfba 7032593: DLL_LOADING: Upgrade solution to 7016985 to reflect JDK7 solution Reviewed-by: mchung, asaha ! src/windows/bin/java_md.c Changeset: 7181441faf72 Author: dcherepanov Date: 2011-04-08 16:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7181441faf72 7003962: AWT: securely load DLLs and launch executables using fully qualified path Reviewed-by: art, bae, alanb ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/stdhdrs.h Changeset: 05a3923f516f Author: dcherepanov Date: 2011-04-08 17:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05a3923f516f 7035077: Minor addition to the changes for 7003962 Reviewed-by: chegar ! src/windows/native/sun/windows/DllUtil.cpp Changeset: afcc1530e68b Author: asaha Date: 2011-04-08 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/afcc1530e68b Merge - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/MethodType.java - src/share/classes/java/dyn/MethodTypeForm.java - src/share/classes/java/dyn/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/ValueConversions.java - src/share/classes/sun/dyn/util/VerifyAccess.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 557bd9b5d92f Author: asaha Date: 2011-04-08 10:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/557bd9b5d92f Merge Changeset: e142148d8b54 Author: asaha Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e142148d8b54 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 76e0e562b617 Author: dcherepanov Date: 2011-04-15 17:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76e0e562b617 7036952: build warning after the changes for 7003962 Reviewed-by: art, bae ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h Changeset: f8eddc85cc02 Author: zgu Date: 2011-04-15 09:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8eddc85cc02 7003964: SERV: securely load DLLs and launch executables using fully qualified path Summary: Linked in Windows libraries that are available on jdk7 supported platforms, and used GetModuleHandle instead of LoadLibrary for already loaded Dlls. Reviewed-by: dcubed, alanb ! make/com/sun/tools/attach/Makefile ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h Changeset: 0865aa0ad9b2 Author: zgu Date: 2011-04-19 10:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0865aa0ad9b2 Merge Changeset: 6f8a4d334fb2 Author: asaha Date: 2011-04-20 09:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f8a4d334fb2 Merge ! make/com/sun/tools/attach/Makefile ! src/share/classes/java/net/NetworkInterface.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/windows/bin/java_md.c ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: f3645b5d6e62 Author: asaha Date: 2011-04-20 21:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3645b5d6e62 Merge Changeset: b626f78c57e1 Author: asaha Date: 2011-04-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b626f78c57e1 Merge Changeset: cec45f3353be Author: asaha Date: 2011-04-21 08:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cec45f3353be Merge Changeset: 6133c9ee3a01 Author: asaha Date: 2011-04-21 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6133c9ee3a01 Merge Changeset: dd06e8d3da91 Author: asaha Date: 2011-04-21 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd06e8d3da91 Merge Changeset: b2295905901a Author: asaha Date: 2011-04-21 16:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2295905901a Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 3fedf261fb4f Author: valeriep Date: 2011-04-26 15:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fedf261fb4f 7003952: SEC: securely load DLLs and launch executables using fully qualified path Summary: Enforce full path when specifying library locations. Reviewed-by: wetmore, ohair ! make/sun/security/pkcs11/Makefile ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/native/sun/security/pkcs11/j2secmod.c + test/sun/security/pkcs11/Provider/Absolute.cfg + test/sun/security/pkcs11/Provider/Absolute.java Changeset: 94ea3b8288f1 Author: alexp Date: 2011-05-04 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94ea3b8288f1 7020198: ImageIcon creates Component with null acc Reviewed-by: rupashka, hawtin ! src/share/classes/javax/swing/ImageIcon.java Changeset: e6fdfb249e31 Author: asaha Date: 2011-05-04 16:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6fdfb249e31 Merge - src/share/native/sun/font/layout/Features.h ! src/windows/native/sun/windows/awt_FileDialog.cpp - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: 49244980d692 Author: asaha Date: 2011-05-05 22:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49244980d692 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java Changeset: 647b031200f0 Author: asaha Date: 2011-05-06 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/647b031200f0 Merge Changeset: 92b5197e9ff5 Author: asaha Date: 2011-05-26 21:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92b5197e9ff5 Merge ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: cca9ea306c6e Author: asaha Date: 2011-05-26 21:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cca9ea306c6e Merge Changeset: dab3e66ebda7 Author: lana Date: 2011-06-06 19:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dab3e66ebda7 Merge Changeset: 9f17be5136d1 Author: wetmore Date: 2011-06-09 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f17be5136d1 7052537: java/security/Security/NotInstalledProviders.java is causing -samevm tests to fail. Reviewed-by: valeriep, asaha, alanb ! test/java/security/Security/NoInstalledProviders.java Changeset: 4961be00d3b5 Author: lana Date: 2011-06-15 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4961be00d3b5 Merge Changeset: cf0632d2db2c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf0632d2db2c 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/SwitchPoint.java + test/java/lang/invoke/PermuteArgsTest.java Changeset: a65fa0f6717e Author: trims Date: 2011-06-17 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a65fa0f6717e Merge Changeset: c46f97579fe6 Author: alanb Date: 2011-06-17 16:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c46f97579fe6 7055508: (aio) EXCEPTION_ACCESS_VIOLATION in AsynchronousSocketChannel.connect on Windows 7 Reviewed-by: chegar ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c Changeset: c102e1221afa Author: lana Date: 2011-06-17 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c102e1221afa Merge Changeset: 539e576793a8 Author: lana Date: 2011-06-18 10:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/539e576793a8 Merge Changeset: 7b4f4230fecf Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b4f4230fecf Added tag jdk7-b146 for changeset 539e576793a8 ! .hgtags Changeset: f2928d86aab0 Author: schien Date: 2011-06-20 17:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2928d86aab0 Merge Changeset: 5838c5bd185d Author: lana Date: 2011-06-22 23:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5838c5bd185d Merge ! src/share/classes/java/awt/Toolkit.java ! test/java/security/Security/NoInstalledProviders.java Changeset: 5dedb265ba3e Author: lana Date: 2011-06-23 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5dedb265ba3e Merge Changeset: b037a8bc1be8 Author: lana Date: 2011-06-23 17:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b037a8bc1be8 Merge From alan.bateman at oracle.com Fri Jun 24 11:32:51 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Jun 2011 18:32:51 +0000 Subject: hg: jdk8/tl/jdk: 6965150: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Basic.java takes too long Message-ID: <20110624183316.F009A472D9@hg.openjdk.java.net> Changeset: 0ad50d4ed1cf Author: alanb Date: 2011-06-24 19:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ad50d4ed1cf 6965150: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Basic.java takes too long Reviewed-by: chegar ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java From jonathan.gibbons at oracle.com Fri Jun 24 12:54:34 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Jun 2011 12:54:34 -0700 Subject: Proposed javac argument processing performance improvement In-Reply-To: References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> <4DF7EFF6.2030300@oracle.com> <4DFAD1F4.8090503@oracle.com> Message-ID: <4E04EB7A.1030804@oracle.com> David, Thank you for your updated patch. I agree with concern that the revised code in JavacTaskImpl.java is somewhat messier than before, so I've attached an alternate way of doing it for your consideration. This keeps the code closer to what it was before, at the expense of a couple of trivial utility methods. If you agree with this alternate impl for JavacTaskImpl.java, we can proceed by using that with the rest of your patch. -- Jon On 06/21/2011 05:40 AM, David Schlosnagle wrote: > On Fri, Jun 17, 2011 at 12:03 AM, Jonathan Gibbons > wrote: >> Dave, >> >> Thanks for the update, and for looking at making your patch work even >> faster. >> >> For a perf-related change like this, no new regression tests will be >> necessary. >> The normal rules in a case like this are to make sure that nothing is >> broken, >> meaning that all the (langtools) tests should still pass and that it should >> still >> be capable to build the OpenJDK forest. Normally, it is sufficient to do a >> regular >> build of OpenJDK; in some circumstances, it would be expected to pass a >> build with SKIP_BOOT_CYCLE=false, meaning that it should be able to build >> OpenJDK -- and the result should itself be capable of building OpenJDK. This >> double build verifies that the bits from the first build are good enough to >> function as a BOOT_JDK. But, I don't think the double build is necessary in >> this case, >> since this is a relatively simple change related to command line processing. >> >> Normally, all the langtools tests should pass all time time, on all >> supported >> platforms (Linux, Windows, Solaris.) I haven't checked out the Mac port >> recently >> to see how the tests perform on that platform. >> >> -- Jon > Here's the updated patch using Iterable throughout, and the > results are similar to the previous patch. Let me know if there is > anything else I can do to get this through the process. > > On an aside, I tried to keep the IllegalArgumentException thrown in > JavacTaskImpl consistent with the previous message; however, the code > is much messier now (this just begs for something like Guava's > Joiner) and I'd prefer using something simpler along the lines of > throw new IllegalArgumentException("Malformed arguments " + > filenames);. That would have the realistic effect of moving from a > space delimited list of filename arguments to a comma and space > delimited and surrounded by square brackets per > AbstractCollection#toString(). > > I've included timings for several different size real world modules > compiled with javac on Windows XP SP2 (where I had seen the worst > performance to start). All times are in milliseconds. With the > changes, processArgs is consistently sub-second, and linear in time > relative to the number of input files. > > | Before | After | Delta | > # files | processArgs | javac | processArgs | javac | processArgs | javac | > --------+-------------+-------+-------------+-------+-------------+---------+ > 5522 | 16170.863 | 48163 | 280.484 | 37087 | -15890.379 | -11075 | > 4436 | 9498.519 | 61043 | 200.735 | 49452 | -9297.784 | -11591 | > 268 | 57.270 | 5775 | 16.923 | 5641 | -40.347 | -134 | > 154 | 28.571 | 3147 | 11.322 | 2985 | -17.249 | -161 | > 101 | 14.486 | 40621 | 7.814 | 40214 | -6.672 | -407 | > 73 | 12.277 | 12180 | 6.677 | 12125 | -5.600 | -55 | > 8 | 1.695 | 1718 | 1.309 | 1643 | -0.386 | -74 | > 4 | 1.500 | 2098 | 1.399 | 2000 | -0.101 | -98 | > 1 | 1.035 | 1442 | 0.911 | 1294 | -0.124 | -148 | > > > Thanks, > - Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: new.patch Type: text/x-patch Size: 1677 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110624/007e9b95/new.patch From schlosna at gmail.com Fri Jun 24 13:04:34 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 24 Jun 2011 16:04:34 -0400 Subject: Proposed javac argument processing performance improvement In-Reply-To: <4E04EB7A.1030804@oracle.com> References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> <4DF7EFF6.2030300@oracle.com> <4DFAD1F4.8090503@oracle.com> <4E04EB7A.1030804@oracle.com> Message-ID: On Fri, Jun 24, 2011 at 3:54 PM, Jonathan Gibbons wrote: > David, > > Thank you for your updated patch. ?I agree with concern that the revised > code > in JavacTaskImpl.java is somewhat messier than before, so I've attached an > alternate way of doing it for your consideration. ?This keeps the code > closer > to what it was before, at the expense of a couple of trivial utility > methods. > > If you agree with this alternate impl for JavacTaskImpl.java, we can proceed > by using that with the rest of your patch. Jon, That looks good to me. - Dave From joe.darcy at oracle.com Fri Jun 24 13:52:35 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 24 Jun 2011 20:52:35 +0000 Subject: hg: jdk8/tl/langtools: 6575445: Update annotation processor to only use java.util.ServiceLoader Message-ID: <20110624205237.9EB87472E2@hg.openjdk.java.net> Changeset: f74e4269a50a Author: darcy Date: 2011-06-24 13:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f74e4269a50a 6575445: Update annotation processor to only use java.util.ServiceLoader Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt From jonathan.gibbons at oracle.com Fri Jun 24 14:09:06 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Jun 2011 14:09:06 -0700 Subject: Proposed javac argument processing performance improvement In-Reply-To: References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> <4DF7EFF6.2030300@oracle.com> <4DFAD1F4.8090503@oracle.com> <4E04EB7A.1030804@oracle.com> Message-ID: <4E04FCF2.9000303@oracle.com> On 06/24/2011 01:04 PM, David Schlosnagle wrote: > On Fri, Jun 24, 2011 at 3:54 PM, Jonathan Gibbons > wrote: >> David, >> >> Thank you for your updated patch. I agree with concern that the revised >> code >> in JavacTaskImpl.java is somewhat messier than before, so I've attached an >> alternate way of doing it for your consideration. This keeps the code >> closer >> to what it was before, at the expense of a couple of trivial utility >> methods. >> >> If you agree with this alternate impl for JavacTaskImpl.java, we can proceed >> by using that with the rest of your patch. > Jon, > > That looks good to me. > > - Dave Dave, Thanks for the speedy response. We'll work on getting this overall patch integrated. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110624/11a0b33c/attachment.html From michael.x.mcmahon at oracle.com Mon Jun 27 04:16:56 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 27 Jun 2011 11:16:56 +0000 Subject: hg: jdk8/tl/jdk: 7059777: Remove lang tests from Problemlist.txt Message-ID: <20110627111719.E2DF647365@hg.openjdk.java.net> Changeset: 113c75db6c8b Author: michaelm Date: 2011-06-27 12:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/113c75db6c8b 7059777: Remove lang tests from Problemlist.txt Reviewed-by: alanb ! test/ProblemList.txt From kumar.x.srinivasan at oracle.com Mon Jun 27 12:22:43 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 27 Jun 2011 19:22:43 +0000 Subject: hg: jdk8/tl/jdk: 7046007: (launcher) Improve usage information for -verbose option Message-ID: <20110627192308.E9DB347377@hg.openjdk.java.net> Changeset: a053c28304e8 Author: ksrini Date: 2011-06-27 12:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a053c28304e8 7046007: (launcher) Improve usage information for -verbose option Reviewed-by: darcy, alanb ! src/share/classes/sun/launcher/resources/launcher.properties From david.holmes at oracle.com Tue Jun 28 00:48:59 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 28 Jun 2011 07:48:59 +0000 Subject: hg: jdk8/tl/jdk: 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Message-ID: <20110628074919.BA2E5473A9@hg.openjdk.java.net> Changeset: 3abc52f0a4dc Author: dholmes Date: 2011-06-27 20:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3abc52f0a4dc 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Summary: Allow platform specific files to be located at build time instead of generating them Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk ! make/java/nio/Makefile From michael.x.mcmahon at oracle.com Tue Jun 28 02:10:45 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 28 Jun 2011 09:10:45 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110628091105.E2810473AD@hg.openjdk.java.net> Changeset: 7b5a0a141b8b Author: michaelm Date: 2011-06-28 10:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b5a0a141b8b 7058832: com/sun/net/httpserver/bugs/B6373555.java failing intermittently Reviewed-by: alanb ! test/com/sun/net/httpserver/bugs/B6373555.java Changeset: 585cc4a4528d Author: michaelm Date: 2011-06-28 10:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/585cc4a4528d Merge From jonathan.gibbons at oracle.com Thu Jun 30 12:01:15 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 30 Jun 2011 19:01:15 +0000 Subject: hg: jdk8/tl/langtools: 7060926: Attr.PostAttrAnalyzer misses a case Message-ID: <20110630190117.B9B09470AD@hg.openjdk.java.net> Changeset: 858ae8fec72f Author: jjg Date: 2011-06-30 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/858ae8fec72f 7060926: Attr.PostAttrAnalyzer misses a case Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/failover/FailOver15.java + test/tools/javac/failover/FailOver15.out From jonathan.gibbons at oracle.com Thu Jun 30 12:51:52 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 Jun 2011 12:51:52 -0700 Subject: Proposed javac argument processing performance improvement In-Reply-To: <4E04FCF2.9000303@oracle.com> References: <84BF5FA0-C56C-4028-84DF-A7111B99C062@oracle.com> <4DF7EFF6.2030300@oracle.com> <4DFAD1F4.8090503@oracle.com> <4E04EB7A.1030804@oracle.com> <4E04FCF2.9000303@oracle.com> Message-ID: <4E0CD3D8.5090203@oracle.com> On 06/24/2011 02:09 PM, Jonathan Gibbons wrote: > On 06/24/2011 01:04 PM, David Schlosnagle wrote: >> On Fri, Jun 24, 2011 at 3:54 PM, Jonathan Gibbons >> wrote: >>> David, >>> >>> Thank you for your updated patch. I agree with concern that the revised >>> code >>> in JavacTaskImpl.java is somewhat messier than before, so I've attached an >>> alternate way of doing it for your consideration. This keeps the code >>> closer >>> to what it was before, at the expense of a couple of trivial utility >>> methods. >>> >>> If you agree with this alternate impl for JavacTaskImpl.java, we can proceed >>> by using that with the rest of your patch. >> Jon, >> >> That looks good to me. >> >> - Dave > > > Dave, > > Thanks for the speedy response. We'll work on getting this overall > patch integrated. > > -- Jon The webrev for the change is available at http://cr.openjdk.java.net/~jjg/7061125-cmdlineperf/ -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110630/b57606a9/attachment.html From kumar.x.srinivasan at oracle.com Thu Jun 30 14:34:19 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 30 Jun 2011 21:34:19 +0000 Subject: hg: jdk8/tl/langtools: 7059905: (javadoc) promote method visibility for netbeans usage Message-ID: <20110630213421.29A3E470B9@hg.openjdk.java.net> Changeset: b0909f992710 Author: ksrini Date: 2011-06-30 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0909f992710 7059905: (javadoc) promote method visibility for netbeans usage Reviewed-by: jjg, bpatel ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java