From vincent.ryan at sun.com Mon Mar 1 10:00:23 2010 From: vincent.ryan at sun.com (vincent.ryan at sun.com) Date: Mon, 01 Mar 2010 18:00:23 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100301180103.D0ACF41DBD@hg.openjdk.java.net> Changeset: 78d91c4223cb Author: vinnie Date: 2010-03-01 17:54 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78d91c4223cb 6921001: api/java_security/IdentityScope/IdentityScopeTests.html#getSystemScope fails starting from b78 JDK7 Reviewed-by: mullan ! src/share/classes/java/security/IdentityScope.java ! src/share/lib/security/java.security + test/java/security/IdentityScope/NoDefaultSystemScope.java Changeset: 893034df4ec2 Author: vinnie Date: 2010-03-01 18:00 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/893034df4ec2 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java From joe.darcy at sun.com Tue Mar 2 13:57:06 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Tue, 02 Mar 2010 21:57:06 +0000 Subject: hg: jdk7/tl/langtools: 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Message-ID: <20100302215709.B65C341F86@hg.openjdk.java.net> Changeset: 7c23bbbe0dbd Author: darcy Date: 2010-03-02 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c23bbbe0dbd 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java From jonathan.gibbons at sun.com Tue Mar 2 16:41:43 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 03 Mar 2010 00:41:43 +0000 Subject: hg: jdk7/tl/langtools: 6931482: minor findbugs fixes Message-ID: <20100303004146.B692D41FB5@hg.openjdk.java.net> Changeset: 6e1e2738c530 Author: jjg Date: 2010-03-02 16:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6e1e2738c530 6931482: minor findbugs fixes Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java From jonathan.gibbons at sun.com Tue Mar 2 16:44:42 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 03 Mar 2010 00:44:42 +0000 Subject: hg: jdk7/tl/langtools: 6931127: strange test class files Message-ID: <20100303004445.7B6E041FB6@hg.openjdk.java.net> Changeset: 235135d61974 Author: jjg Date: 2010-03-02 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/235135d61974 6931127: strange test class files Reviewed-by: darcy ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveVariant.java From alan.bateman at sun.com Wed Mar 3 08:10:11 2010 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Wed, 03 Mar 2010 16:10:11 +0000 Subject: hg: jdk7/tl/jdk: 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Message-ID: <20100303161050.CC14143C39@hg.openjdk.java.net> Changeset: cddb43b12d28 Author: alanb Date: 2010-03-03 16:09 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cddb43b12d28 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Reviewed-by: chegar ! test/java/nio/file/WatchService/LotsOfEvents.java From kelly.ohair at sun.com Wed Mar 3 11:30:18 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 03 Mar 2010 19:30:18 +0000 Subject: hg: jdk7/tl/jdk: 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Message-ID: <20100303193038.0881343C6C@hg.openjdk.java.net> Changeset: 507159d8d143 Author: ohair Date: 2010-03-03 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/507159d8d143 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Reviewed-by: jjg ! make/common/shared/Sanity.gmk From joe.darcy at sun.com Wed Mar 3 16:05:47 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 04 Mar 2010 00:05:47 +0000 Subject: hg: jdk7/tl/langtools: 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Message-ID: <20100304000550.9A71443CAE@hg.openjdk.java.net> Changeset: fc7132746501 Author: darcy Date: 2010-03-03 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc7132746501 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/processing/model/element/TestAnonClassNames.java + test/tools/javac/processing/model/element/TestAnonSourceNames.java From jonathan.gibbons at sun.com Wed Mar 3 17:23:54 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 04 Mar 2010 01:23:54 +0000 Subject: hg: jdk7/tl/langtools: 6931927: position issues with synthesized anonymous class Message-ID: <20100304012357.898BF43CC4@hg.openjdk.java.net> Changeset: 7f5db2e8b423 Author: jjg Date: 2010-03-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7f5db2e8b423 6931927: position issues with synthesized anonymous class Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/TestAnnotatedAnonClass.java + test/tools/javac/tree/TreePosTest.java - test/tools/javac/treepostests/TreePosTest.java From weijun.wang at sun.com Wed Mar 3 18:40:26 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 04 Mar 2010 02:40:26 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100304024122.AFDFC43CD7@hg.openjdk.java.net> Changeset: 61c298558549 Author: weijun Date: 2010-03-04 10:37 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61c298558549 6844909: support allow_weak_crypto in krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java + test/sun/security/krb5/etype/WeakCrypto.java + test/sun/security/krb5/etype/weakcrypto.conf Changeset: 0f383673ce31 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f383673ce31 6923681: Jarsigner crashes during timestamping Reviewed-by: vinnie ! src/share/classes/sun/security/tools/TimestampedSigner.java Changeset: 5e15b70e6d27 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e15b70e6d27 6880321: sun.security.provider.JavaKeyStore abuse of OOM Exception handling Reviewed-by: xuelei ! src/share/classes/sun/security/provider/JavaKeyStore.java From jonathan.gibbons at sun.com Wed Mar 3 19:35:50 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 04 Mar 2010 03:35:50 +0000 Subject: hg: jdk7/tl/langtools: 6931126: jtreg tests not Windows friendly Message-ID: <20100304033552.E838743CE5@hg.openjdk.java.net> Changeset: 117c95448ab9 Author: jjg Date: 2010-03-03 19:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/117c95448ab9 6931126: jtreg tests not Windows friendly Reviewed-by: darcy ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/generics/NameOrder.java From lana.steuck at sun.com Thu Mar 4 22:46:13 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:46:13 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b84 for changeset 2f3ea057d1ad Message-ID: <20100305064613.4D93E43E6F@hg.openjdk.java.net> Changeset: cf26288a114b Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/cf26288a114b Added tag jdk7-b84 for changeset 2f3ea057d1ad ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:46:19 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:46:19 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b84 for changeset 68c8961a82e4 Message-ID: <20100305064620.B3DA043E70@hg.openjdk.java.net> Changeset: c67a9df7bc0c Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/c67a9df7bc0c Added tag jdk7-b84 for changeset 68c8961a82e4 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:48:40 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:48:40 +0000 Subject: hg: jdk7/tl/hotspot: 27 new changesets Message-ID: <20100305065004.1989143E71@hg.openjdk.java.net> Changeset: 125eb6a9fccf Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/125eb6a9fccf Added tag jdk7-b84 for changeset ffc8d176b84b ! .hgtags Changeset: 745c853ee57f Author: johnc Date: 2010-01-29 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/745c853ee57f 6885297: java -XX:RefDiscoveryPolicy=2 or -XX:TLABWasteTargetPercent=0 cause VM crash Summary: Interval checking is now being performed on the values passed in for these two flags. The current acceptable range for RefDiscoveryPolicy is [0..1], and for TLABWasteTargetPercent it is [1..100]. Reviewed-by: apetrusenko, ysr ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 6484c4ee11cb Author: ysr Date: 2010-02-01 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6484c4ee11cb 6904516: More object array barrier fixes, following up on 6906727 Summary: Fixed missing pre-barrier calls for G1, modified C1 to call pre- and correct post-barrier interfaces, deleted obsolete interface, (temporarily) disabled redundant deferred barrier in BacktraceBuilder. Reviewed-by: coleenp, jmasa, kvn, never ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/runtime/stubRoutines.cpp Changeset: deada8912c54 Author: johnc Date: 2010-02-02 18:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/deada8912c54 6914402: G1: assert(!is_young_card(cached_ptr),"shouldn't get a card in young region") Summary: Invalid assert. Filter cards evicted from the card count cache instead. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 230fac611b50 Author: johnc Date: 2010-02-08 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/230fac611b50 Merge ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/includeDB_core Changeset: 455df1b81409 Author: kamg Date: 2010-02-08 13:49 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/455df1b81409 6587322: dtrace probe object__alloc doesn't fire in some situations on amd64 Summary: Fix misplaced probe point Reviewed-by: rasbold, phh Contributed-by: neojia at gmail.com ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 95d21201c29a Author: apangin Date: 2010-02-11 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/95d21201c29a Merge Changeset: 3f5b7efb9642 Author: never Date: 2010-02-05 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f5b7efb9642 6920293: OptimizeStringConcat causing core dumps Reviewed-by: kvn, twisti ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 576e77447e3c Author: kvn Date: 2010-02-07 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/576e77447e3c 6923002: assert(false,"this call site should not be polymorphic") Summary: Clear the total count when a receiver information is cleared. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp Changeset: f516d5d7a019 Author: kvn Date: 2010-02-08 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f516d5d7a019 6910605: C2: NullPointerException/ClassCaseException is thrown when C2 with DeoptimizeALot is used Summary: Set the reexecute bit for runtime calls _new_array_Java when they used for _multianewarray bytecode. Reviewed-by: never ! src/share/vm/code/pcDesc.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/6910605/Test.java Changeset: f70b0d9ab095 Author: kvn Date: 2010-02-09 01:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f70b0d9ab095 6910618: C2: Error: assert(d->is_oop(),"JVM_ArrayCopy: dst not an oop") Summary: Mark in PcDesc call sites which return oop and save the result oop across objects reallocation during deoptimization. Reviewed-by: never ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/includeDB_core ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/deoptimization.cpp + test/compiler/6910618/Test.java Changeset: 4ee1c645110e Author: kvn Date: 2010-02-09 10:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4ee1c645110e 6924097: assert((_type == Type::MEMORY) == (_adr_type != 0),"adr_type for memory phis only") Summary: Use PhiNode::make_blank(r, n) method to construct the phi. Reviewed-by: never ! src/share/vm/opto/loopopts.cpp Changeset: e3a4305c6bc3 Author: kvn Date: 2010-02-12 08:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e3a4305c6bc3 6925249: assert(last_sp < (intptr_t*) interpreter_frame_monitor_begin(),"bad tos") Summary: Fix assert since top deoptimized frame has last_sp == interpreter_frame_monitor_begin if there are no expressions. Reviewed-by: twisti ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: c09ee209b65c Author: kvn Date: 2010-02-12 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c09ee209b65c 6926048: Improve Zero performance Summary: Make Zero figure out result types in a similar way to C++ interpreter implementation. Reviewed-by: kvn Contributed-by: gbenson at redhat.com ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp Changeset: 7b4415a18c8a Author: kvn Date: 2010-02-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7b4415a18c8a Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 38836cf1d8d2 Author: tonyp Date: 2010-02-05 11:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/38836cf1d8d2 6920977: G1: guarantee(k == probe->klass(),"klass should be in dictionary") fails Summary: the guarantee is too strict and the test will fail (incorrectly) if the class is not in the system dictionary but in the placeholders. Reviewed-by: acorn, phh ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/includeDB_core Changeset: 9eee977dd1a9 Author: tonyp Date: 2010-02-08 14:23 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9eee977dd1a9 6802453: G1: hr()->is_in_reserved(from),"Precondition." Summary: The operations of re-using a RSet component and expanding the same RSet component were not mutually exlusive, and this could lead to RSets getting corrupted and entries being dropped. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 8859772195c6 Author: johnc Date: 2010-02-09 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8859772195c6 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate. Summary: Update and display the timers associated with these flags for all safepoints. Reviewed-by: ysr, jcoomes ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/runtimeService.cpp Changeset: 0414c1049f15 Author: iveresov Date: 2010-02-11 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0414c1049f15 6923991: G1: improve scalability of RSet scanning Summary: Implemented block-based work stealing. Moved copying during the rset scanning phase to the main copying phase. Made the size of rset table depend on the region size. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 58add740c4ee Author: johnc Date: 2010-02-16 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/58add740c4ee Merge ! src/share/vm/includeDB_core Changeset: e7b1cc79bd25 Author: kvn Date: 2010-02-16 16:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7b1cc79bd25 6926697: "optimized" VM build failed: The type "AdapterHandlerTableIterator" is incomplete Summary: Define AdapterHandlerTableIterator class as non product instead of debug. Reviewed-by: never ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 106f41e88c85 Author: never Date: 2010-02-16 20:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/106f41e88c85 6877221: Endless deoptimizations in OSR nmethod Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp Changeset: b4b440360f1e Author: twisti Date: 2010-02-18 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b4b440360f1e 6926782: CodeBuffer size too small after 6921352 Summary: After 6921352 the CodeBuffer size was too small. Reviewed-by: kvn, never ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: 3b687c53c266 Author: twisti Date: 2010-02-18 06:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3b687c53c266 6927165: Zero S/390 fixes Summary: Fixes two failures on 31-bit S/390. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.hpp Changeset: 72f1840531a4 Author: twisti Date: 2010-02-18 10:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/72f1840531a4 Merge Changeset: 1f341bb67b5b Author: trims Date: 2010-02-18 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1f341bb67b5b Merge Changeset: 6c9796468b91 Author: trims Date: 2010-02-18 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c9796468b91 6927886: Bump the HS17 build number to 10 Summary: Update the HS17 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version From lana.steuck at sun.com Thu Mar 4 22:53:59 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:53:59 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b84 for changeset 32c0cf01d555 Message-ID: <20100305065359.9313F43E73@hg.openjdk.java.net> Changeset: 6c0ccabb430d Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/6c0ccabb430d Added tag jdk7-b84 for changeset 32c0cf01d555 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:54:06 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:54:06 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b84 for changeset 8bc02839eee4 Message-ID: <20100305065406.7BDCD43E74@hg.openjdk.java.net> Changeset: 8424512588ff Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/8424512588ff Added tag jdk7-b84 for changeset 8bc02839eee4 ! .hgtags From lana.steuck at sun.com Thu Mar 4 22:54:39 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 06:54:39 +0000 Subject: hg: jdk7/tl/jdk: 5 new changesets Message-ID: <20100305065612.5781943E77@hg.openjdk.java.net> Changeset: a9b4fde406d4 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a9b4fde406d4 Added tag jdk7-b84 for changeset 7cb9388bb1a1 ! .hgtags Changeset: 2ba381560071 Author: dcherepanov Date: 2010-02-12 19:58 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ba381560071 6705345: Enable multiple file selection in AWT FileDialog Reviewed-by: art, anthony, alexp ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h + test/java/awt/FileDialog/MultipleMode/MultipleMode.html + test/java/awt/FileDialog/MultipleMode/MultipleMode.java Changeset: d6d2de6ee2d1 Author: lana Date: 2010-02-19 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6d2de6ee2d1 Merge Changeset: b396584a3e64 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b396584a3e64 Merge - make/java/text/FILES_java.gmk Changeset: c2d29e5695c2 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2d29e5695c2 Merge From lana.steuck at sun.com Thu Mar 4 23:03:30 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 05 Mar 2010 07:03:30 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100305070338.B02E543E79@hg.openjdk.java.net> Changeset: 75d5bd12eb86 Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/75d5bd12eb86 Added tag jdk7-b84 for changeset d9cd5b8286e4 ! .hgtags Changeset: 136bfc679462 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/136bfc679462 Merge Changeset: c55733ceed61 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c55733ceed61 Merge From Ulf.Zibis at gmx.de Fri Mar 5 13:47:49 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 05 Mar 2010 22:47:49 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B756945.1090600@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> Message-ID: <4B917C05.3020309@gmx.de> No response ?? :-( I've filed a bug: internal review ID of 1730072 -Ulf Am 12.02.2010 15:44, schrieb Ulf Zibis: > Am 12.02.2010 15:06, schrieb Ulf Zibis: >> Hi, >> >> in the following example, I have an assert statement in a static >> block of my class. >> >> If accessing the static final constants from another class, the >> static block is not executed. >> This causes the assertions to remain un-proofed, even if -ea -esa is >> set. >> >> Is that correct ? > > If yes, javac should claim the code as never reached. > >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> > > -Ulf > > > From - Fri Feb 12 16:25:03 2010 > X-Account-Key: account2 > X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 > X-Mozilla-Status: 0000 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: > X-Symantec-TimeoutProtection: 0 > X-Symantec-TimeoutProtection: 1 > X-Symantec-TimeoutProtection: 2 > Return-Path: > X-Flags: 1001 > Delivered-To: GMX delivery to ulf.zibis at gmx.de > Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 > Received: from brmea-mail-2.Sun.COM (EHLO brmea-mail-2.sun.com) > [192.18.98.43] > by mx0.gmx.net (mx002) with SMTP; 12 Feb 2010 16:12:59 +0100 > Received: from fe-amer-09.sun.com ([192.18.109.79]) > by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id > o1CFCw62027512 > for ; Fri, 12 Feb 2010 15:12:58 GMT > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > Content-type: text/plain; CHARSET=US-ASCII; format=flowed > Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com > (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) > id <0KXQ00800HZH3I00 at mail-amer.sun.com> for Ulf.Zibis at gmx.de; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Received: from [129.150.65.45] ([unknown] [129.150.65.45]) > by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit > (built Jul 2 2009)) with ESMTPSA id > <0KXQ00GTLI9L1V60 at mail-amer.sun.com>; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Date: Fri, 12 Feb 2010 10:12:58 -0500 > From: Keith McGuigan > Subject: Re: Assertions in static blocks ? > In-reply-to: <4B756071.4000104 at gmx.de> > Sender: Keith.McGuigan at Sun.COM > To: Ulf Zibis > Cc: compiler-dev at openjdk.java.net, hotspot > Message-id: <4B756FFA.9000806 at sun.com> > References: <4B756071.4000104 at gmx.de> > User-Agent: Thunderbird 2.0.0.23 (X11/20090817) > X-GMX-Antivirus: 0 (no virus found) > X-GMX-Antispam: 0 (Mail was not recognized as spam); > Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar > > zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H > > PZZzg==V1; > X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 > > > Hi Ulf - > > Accessing a constant static field in a class does not trigger class > initialization, so your initializer is probably just not being run. > > See > http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 > > > -- > - Keith > > Ulf Zibis wrote: >> Hi, >> >> in the following example, I have an assert statement in a static >> block of my class. >> >> If accessing the static final constants from another class, the >> static block is not executed. >> This causes the assertions to remain un-proofed, even if -ea -esa is >> set. >> >> Is that correct ? >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> >> >> >> package sun.nio.cs.ext; >> >> import static sun.nio.cs.CharsetMapping.*; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> class EUC_TWMapping3 extends EUC_TWMapping { >> static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range >> static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 >> b2c range >> >> // TODO: file bug: static block should run, if assertions are enabled. >> static { >> // assert plane offsets and content >> for (int p=0, range, offset=0; p> range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >> for (int i=range; i> assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >> // static block should run, if assertions are enabled. For test >> uncomment following line >> // System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> assert (offset += range) <= Character.MAX_VALUE + 1; >> } >> } >> >> // WORKAROUND: >> // static int offset = 0; // assert from calling context to force >> static block to process >> // static { >> // // assert plane offsets and content >> // for (int p=0, range; p> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >> // for (int i=range; i> // assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >> //// static block should run, if assertions are enabled. For test >> uncomment following line >> //// System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> // assert (offset += range) <= Character.MAX_VALUE + 1; >> // } >> //// static block should run, if assertions are enabled. For test >> uncomment following line >> //// assert false; >> // } >> } >> >> >> package sun.nio.cs.ext; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> public class AssertTest { >> >> public static void main(String... args) { >> // static block in EUC_TWMapping3 should run, if assertions are enabled. >> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >> // WORKAROUND: For test uncomment following line >> // assert EUC_TWMapping3.offset > 0; // force assertion, TODO: >> JDK bug ? >> } >> } >> >> > > From neal at gafter.com Fri Mar 5 13:59:34 2010 From: neal at gafter.com (Neal Gafter) Date: Fri, 5 Mar 2010 13:59:34 -0800 Subject: Assertions in static blocks ? In-Reply-To: <4B917C05.3020309@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> Message-ID: <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis wrote: > No response ?? :-( > Keith's response is correct. An assertion in a method only occurs when the method is executed. An assertion in a constructor only occurs when the constructor is called. An assertion in a static initializer only occurs when the class is statically initialized. Accessing a constant of the class does not initialize the class. So there is no bug. Cheers, Neal > I've filed a bug: > > internal review ID of 1730072 > > > -Ulf > > > > Am 12.02.2010 15:44, schrieb Ulf Zibis: > >> Am 12.02.2010 15:06, schrieb Ulf Zibis: >> >>> Hi, >>> >>> in the following example, I have an assert statement in a static block of >>> my class. >>> >>> If accessing the static final constants from another class, the static >>> block is not executed. >>> This causes the assertions to remain un-proofed, even if -ea -esa is set. >>> >>> Is that correct ? >>> >> >> If yes, javac should claim the code as never reached. >> >> >>> IMO, assertions should always run, if -ea -esa is set. >>> >>> -Ulf >>> >>> >> -Ulf >> >> >> From - Fri Feb 12 16:25:03 2010 >> X-Account-Key: account2 >> X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 >> X-Mozilla-Status: 0000 >> X-Mozilla-Status2: 00000000 >> X-Mozilla-Keys: >> X-Symantec-TimeoutProtection: 0 >> X-Symantec-TimeoutProtection: 1 >> X-Symantec-TimeoutProtection: 2 >> Return-Path: >> X-Flags: 1001 >> Delivered-To: GMX delivery to ulf.zibis at gmx.de >> Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 >> Received: from brmea-mail-2.Sun.COM (EHLO brmea-mail-2.sun.com) >> [192.18.98.43] >> by mx0.gmx.net (mx002) with SMTP; 12 Feb 2010 16:12:59 +0100 >> Received: from fe-amer-09.sun.com ([192.18.109.79]) >> by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id >> o1CFCw62027512 >> for ; Fri, 12 Feb 2010 15:12:58 GMT >> MIME-version: 1.0 >> Content-transfer-encoding: 7BIT >> Content-type: text/plain; CHARSET=US-ASCII; format=flowed >> Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com >> (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) >> id <0KXQ00800HZH3I00 at mail-amer.sun.com> for Ulf.Zibis at gmx.de; Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Received: from [129.150.65.45] ([unknown] [129.150.65.45]) >> by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit >> (built Jul 2 2009)) with ESMTPSA id <0KXQ00GTLI9L1V60 at mail-amer.sun.com>; >> Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Date: Fri, 12 Feb 2010 10:12:58 -0500 >> From: Keith McGuigan >> Subject: Re: Assertions in static blocks ? >> In-reply-to: <4B756071.4000104 at gmx.de> >> Sender: Keith.McGuigan at Sun.COM >> To: Ulf Zibis >> Cc: compiler-dev at openjdk.java.net, hotspot >> Message-id: <4B756FFA.9000806 at sun.com> >> References: <4B756071.4000104 at gmx.de> >> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) >> X-GMX-Antivirus: 0 (no virus found) >> X-GMX-Antispam: 0 (Mail was not recognized as spam); >> Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar >> >> zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H >> >> PZZzg==V1; >> X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 >> >> >> >> Hi Ulf - >> >> Accessing a constant static field in a class does not trigger class >> initialization, so your initializer is probably just not being run. >> >> See >> http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 >> >> -- >> - Keith >> >> Ulf Zibis wrote: >> >>> Hi, >>> >>> in the following example, I have an assert statement in a static block of >>> my class. >>> >>> If accessing the static final constants from another class, the static >>> block is not executed. >>> This causes the assertions to remain un-proofed, even if -ea -esa is set. >>> >>> Is that correct ? >>> >>> IMO, assertions should always run, if -ea -esa is set. >>> >>> -Ulf >>> >>> >>> >>> package sun.nio.cs.ext; >>> >>> import static sun.nio.cs.CharsetMapping.*; >>> >>> /** >>> * >>> * @author Ulf Zibis, Cologne CoSoCo.de >>> */ >>> class EUC_TWMapping3 extends EUC_TWMapping { >>> static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range >>> static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 b2c >>> range >>> >>> // TODO: file bug: static block should run, if assertions are enabled. >>> static { >>> // assert plane offsets and content >>> for (int p=0, range, offset=0; p>> range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>> for (int i=range; i>> assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>> // static block should run, if assertions are enabled. For test uncomment >>> following line >>> // System.out.printf("offset: %d, range: %d, b2c[p].length(): >>> %d%n", offset, range, b2c[p].length()); >>> assert (offset += range) <= Character.MAX_VALUE + 1; >>> } >>> } >>> >>> // WORKAROUND: >>> // static int offset = 0; // assert from calling context to force >>> static block to process >>> // static { >>> // // assert plane offsets and content >>> // for (int p=0, range; p>> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>> // for (int i=range; i>> // assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>> //// static block should run, if assertions are enabled. For test >>> uncomment following line >>> //// System.out.printf("offset: %d, range: %d, >>> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >>> // assert (offset += range) <= Character.MAX_VALUE + 1; >>> // } >>> //// static block should run, if assertions are enabled. For test >>> uncomment following line >>> //// assert false; >>> // } >>> } >>> >>> >>> package sun.nio.cs.ext; >>> >>> /** >>> * >>> * @author Ulf Zibis, Cologne CoSoCo.de >>> */ >>> public class AssertTest { >>> >>> public static void main(String... args) { >>> // static block in EUC_TWMapping3 should run, if assertions are enabled. >>> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >>> // WORKAROUND: For test uncomment following line >>> // assert EUC_TWMapping3.offset > 0; // force assertion, TODO: JDK >>> bug ? >>> } >>> } >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100305/efe20f24/attachment.html From Ulf.Zibis at gmx.de Fri Mar 5 15:08:16 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 06 Mar 2010 00:08:16 +0100 Subject: Assertions in static blocks ? In-Reply-To: <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> Message-ID: <4B918EE0.7010709@gmx.de> Neal, Keith, thanks for your answer. ... but shouldn't javac claim, that there the code in the static block will be *never reached*, if there is no trigger to run it? -Ulf Am 05.03.2010 22:59, schrieb Neal Gafter: > On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis > wrote: > > No response ?? :-( > > > Keith's response is correct. An assertion in a method only occurs > when the method is executed. An assertion in a constructor only > occurs when the constructor is called. An assertion in a static > initializer only occurs when the class is statically initialized. > Accessing a constant of the class does not initialize the class. So > there is no bug. > > Cheers, > Neal > > > I've filed a bug: > > internal review ID of 1730072 > > > -Ulf > > > > Am 12.02.2010 15:44, schrieb Ulf Zibis: > > Am 12.02.2010 15:06, schrieb Ulf Zibis: > > Hi, > > in the following example, I have an assert statement in a > static block of my class. > > If accessing the static final constants from another > class, the static block is not executed. > This causes the assertions to remain un-proofed, even if > -ea -esa is set. > > Is that correct ? > > > If yes, javac should claim the code as never reached. > > > IMO, assertions should always run, if -ea -esa is set. > > -Ulf > > > -Ulf > > > >From - Fri Feb 12 16:25:03 2010 > X-Account-Key: account2 > X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 > X-Mozilla-Status: 0000 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: > X-Symantec-TimeoutProtection: 0 > X-Symantec-TimeoutProtection: 1 > X-Symantec-TimeoutProtection: 2 > Return-Path: > X-Flags: 1001 > Delivered-To: GMX delivery to ulf.zibis at gmx.de > > Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 > Received: from brmea-mail-2.Sun.COM > (EHLO brmea-mail-2.sun.com > ) [192.18.98.43] > by mx0.gmx.net (mx002) with SMTP; 12 Feb > 2010 16:12:59 +0100 > Received: from fe-amer-09.sun.com > ([192.18.109.79]) > by brmea-mail-2.sun.com > (8.13.6+Sun/8.12.9) with ESMTP id o1CFCw62027512 > for >; Fri, 12 > Feb 2010 15:12:58 GMT > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > Content-type: text/plain; CHARSET=US-ASCII; format=flowed > Received: from conversion-daemon.mail-amer.sun.com > by > mail-amer.sun.com > (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built > Jul 2 2009)) > id <0KXQ00800HZH3I00 at mail-amer.sun.com > > for > Ulf.Zibis at gmx.de ; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Received: from [129.150.65.45] ([unknown] [129.150.65.45]) > by mail-amer.sun.com (Sun Java(tm) > System Messaging Server 7u2-7.04 64bit > (built Jul 2 2009)) with ESMTPSA id > <0KXQ00GTLI9L1V60 at mail-amer.sun.com > >; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Date: Fri, 12 Feb 2010 10:12:58 -0500 > From: Keith McGuigan > Subject: Re: Assertions in static blocks ? > In-reply-to: <4B756071.4000104 at gmx.de > > > Sender: Keith.McGuigan at Sun.COM > To: Ulf Zibis > > Cc: compiler-dev at openjdk.java.net > , hotspot > > > Message-id: <4B756FFA.9000806 at sun.com > > > References: <4B756071.4000104 at gmx.de > > > User-Agent: Thunderbird 2.0.0.23 (X11/20090817) > X-GMX-Antivirus: 0 (no virus found) > X-GMX-Antispam: 0 (Mail was not recognized as spam); > Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar > > zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H > > PZZzg==V1; > X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 > > > > Hi Ulf - > > Accessing a constant static field in a class does not trigger > class initialization, so your initializer is probably just not > being run. > > See > http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 > > > -- > - Keith > > Ulf Zibis wrote: > > Hi, > > in the following example, I have an assert statement in a > static block of my class. > > If accessing the static final constants from another > class, the static block is not executed. > This causes the assertions to remain un-proofed, even if > -ea -esa is set. > > Is that correct ? > > IMO, assertions should always run, if -ea -esa is set. > > -Ulf > > > > package sun.nio.cs.ext; > > import static sun.nio.cs.CharsetMapping.*; > > /** > * > * @author Ulf Zibis, Cologne CoSoCo.de > */ > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE = 0x2300; // plane > 0, 5 b2c range > static final short PLANE_B2C_RANGE = 0x1f00; // plane > 2..4, 6..15 b2c range > > // TODO: file bug: static block should run, if assertions > are enabled. > static { > // assert plane offsets and content > for (int p=0, range, offset=0; p range = p % 4 == 0 ? PL0_5_B2C_RANGE : > PLANE_B2C_RANGE; > for (int i=range; i assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; > // static block should run, if assertions are enabled. For > test uncomment following line > // System.out.printf("offset: %d, range: %d, > b2c[p].length(): %d%n", offset, range, b2c[p].length()); > assert (offset += range) <= Character.MAX_VALUE > + 1; > } > } > > // WORKAROUND: > // static int offset = 0; // assert from calling > context to force static block to process > // static { > // // assert plane offsets and content > // for (int p=0, range; p // range = p % 4 == 0 ? PL0_5_B2C_RANGE : > PLANE_B2C_RANGE; > // for (int i=range; i // assert b2c[p].charAt(i) == > UNMAPPABLE_DECODING; > //// static block should run, if assertions are enabled. > For test uncomment following line > //// System.out.printf("offset: %d, range: %d, > b2c[p].length(): %d%n", offset, range, b2c[p].length()); > // assert (offset += range) <= > Character.MAX_VALUE + 1; > // } > //// static block should run, if assertions are enabled. > For test uncomment following line > //// assert false; > // } > } > > > package sun.nio.cs.ext; > > /** > * > * @author Ulf Zibis, Cologne CoSoCo.de > */ > public class AssertTest { > > public static void main(String... args) { > // static block in EUC_TWMapping3 should run, if > assertions are enabled. > System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); > // WORKAROUND: For test uncomment following line > // assert EUC_TWMapping3.offset > 0; // force > assertion, TODO: JDK bug ? > } > } > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100306/cd135c4b/attachment.html From Jonathan.Gibbons at Sun.COM Fri Mar 5 15:31:23 2010 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 05 Mar 2010 15:31:23 -0800 Subject: Assertions in static blocks ? In-Reply-To: <4B918EE0.7010709@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> Message-ID: <4B91944B.6010609@sun.com> There is a trigger -- you're just not using it. "An assertion in a static initializer only occurs when the class is statically initialized. " -- Jon Ulf Zibis wrote: > Neal, Keith, thanks for your answer. > > ... but shouldn't javac claim, that there the code in the static block > will be *never reached*, if there is no trigger to run it? > > -Ulf > > > Am 05.03.2010 22:59, schrieb Neal Gafter: >> On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis > > wrote: >> >> No response ?? :-( >> >> >> Keith's response is correct. An assertion in a method only occurs >> when the method is executed. An assertion in a constructor only >> occurs when the constructor is called. An assertion in a static >> initializer only occurs when the class is statically initialized. >> Accessing a constant of the class does not initialize the class. So >> there is no bug. >> >> Cheers, >> Neal >> >> >> I've filed a bug: >> >> internal review ID of 1730072 >> >> >> -Ulf >> >> >> >> Am 12.02.2010 15:44, schrieb Ulf Zibis: >> >> Am 12.02.2010 15:06, schrieb Ulf Zibis: >> >> Hi, >> >> in the following example, I have an assert statement in a >> static block of my class. >> >> If accessing the static final constants from another >> class, the static block is not executed. >> This causes the assertions to remain un-proofed, even if >> -ea -esa is set. >> >> Is that correct ? >> >> >> If yes, javac should claim the code as never reached. >> >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> >> >> -Ulf >> >> >> >From - Fri Feb 12 16:25:03 2010 >> X-Account-Key: account2 >> X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 >> X-Mozilla-Status: 0000 >> X-Mozilla-Status2: 00000000 >> X-Mozilla-Keys: >> X-Symantec-TimeoutProtection: 0 >> X-Symantec-TimeoutProtection: 1 >> X-Symantec-TimeoutProtection: 2 >> Return-Path: >> X-Flags: 1001 >> Delivered-To: GMX delivery to ulf.zibis at gmx.de >> >> Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 >> Received: from brmea-mail-2.Sun.COM >> (EHLO brmea-mail-2.sun.com >> ) [192.18.98.43] >> by mx0.gmx.net (mx002) with SMTP; 12 >> Feb 2010 16:12:59 +0100 >> Received: from fe-amer-09.sun.com >> ([192.18.109.79]) >> by brmea-mail-2.sun.com >> (8.13.6+Sun/8.12.9) with ESMTP id o1CFCw62027512 >> for >; Fri, 12 >> Feb 2010 15:12:58 GMT >> MIME-version: 1.0 >> Content-transfer-encoding: 7BIT >> Content-type: text/plain; CHARSET=US-ASCII; format=flowed >> Received: from conversion-daemon.mail-amer.sun.com >> by >> mail-amer.sun.com >> (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built >> Jul 2 2009)) >> id <0KXQ00800HZH3I00 at mail-amer.sun.com >> > for >> Ulf.Zibis at gmx.de ; Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Received: from [129.150.65.45] ([unknown] [129.150.65.45]) >> by mail-amer.sun.com (Sun Java(tm) >> System Messaging Server 7u2-7.04 64bit >> (built Jul 2 2009)) with ESMTPSA id >> <0KXQ00GTLI9L1V60 at mail-amer.sun.com >> >; Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Date: Fri, 12 Feb 2010 10:12:58 -0500 >> From: Keith McGuigan >> Subject: Re: Assertions in static blocks ? >> In-reply-to: <4B756071.4000104 at gmx.de >> > >> Sender: Keith.McGuigan at Sun.COM >> To: Ulf Zibis > >> Cc: compiler-dev at openjdk.java.net >> , hotspot >> > > >> Message-id: <4B756FFA.9000806 at sun.com >> > >> References: <4B756071.4000104 at gmx.de >> > >> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) >> X-GMX-Antivirus: 0 (no virus found) >> X-GMX-Antispam: 0 (Mail was not recognized as spam); >> Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar >> >> zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H >> >> PZZzg==V1; >> X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 >> >> >> >> Hi Ulf - >> >> Accessing a constant static field in a class does not trigger >> class initialization, so your initializer is probably just >> not being run. >> >> See >> http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 >> >> >> -- >> - Keith >> >> Ulf Zibis wrote: >> >> Hi, >> >> in the following example, I have an assert statement in a >> static block of my class. >> >> If accessing the static final constants from another >> class, the static block is not executed. >> This causes the assertions to remain un-proofed, even if >> -ea -esa is set. >> >> Is that correct ? >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> >> >> >> package sun.nio.cs.ext; >> >> import static sun.nio.cs.CharsetMapping.*; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> class EUC_TWMapping3 extends EUC_TWMapping { >> static final short PL0_5_B2C_RANGE = 0x2300; // plane >> 0, 5 b2c range >> static final short PLANE_B2C_RANGE = 0x1f00; // plane >> 2..4, 6..15 b2c range >> >> // TODO: file bug: static block should run, if assertions >> are enabled. >> static { >> // assert plane offsets and content >> for (int p=0, range, offset=0; p> range = p % 4 == 0 ? PL0_5_B2C_RANGE : >> PLANE_B2C_RANGE; >> for (int i=range; i> assert b2c[p].charAt(i) == >> UNMAPPABLE_DECODING; >> // static block should run, if assertions are enabled. >> For test uncomment following line >> // System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> assert (offset += range) <= >> Character.MAX_VALUE + 1; >> } >> } >> >> // WORKAROUND: >> // static int offset = 0; // assert from calling >> context to force static block to process >> // static { >> // // assert plane offsets and content >> // for (int p=0, range; p> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : >> PLANE_B2C_RANGE; >> // for (int i=range; i> // assert b2c[p].charAt(i) == >> UNMAPPABLE_DECODING; >> //// static block should run, if assertions are enabled. >> For test uncomment following line >> //// System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> // assert (offset += range) <= >> Character.MAX_VALUE + 1; >> // } >> //// static block should run, if assertions are enabled. >> For test uncomment following line >> //// assert false; >> // } >> } >> >> >> package sun.nio.cs.ext; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> public class AssertTest { >> >> public static void main(String... args) { >> // static block in EUC_TWMapping3 should run, if >> assertions are enabled. >> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >> // WORKAROUND: For test uncomment following line >> // assert EUC_TWMapping3.offset > 0; // force >> assertion, TODO: JDK bug ? >> } >> } >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100305/7489f8e6/attachment.html From lists at laerad.com Fri Mar 5 15:34:19 2010 From: lists at laerad.com (Benedict Elliott Smith) Date: Fri, 5 Mar 2010 23:34:19 +0000 Subject: Assertions in static blocks ? In-Reply-To: <4B918EE0.7010709@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> Message-ID: <51a29d951003051534m7799de34je538a9cf2736785e@mail.gmail.com> It's not generally possible to determine if a class initializer will ever be run. It would be possible to determine that, if a class were declared with default (package) level protection and was never referenced by another class in the package, that the class was not used (so long as the program did not violate the protection via reflection); but this is the best that could be achieved (there is an argument to be made for javac to complain in this case, as it will in the case of unused private classes, however I am not certain it is necessary), however I do not think this is what you are suggesting. It would be possible, if the class were declared with default protection, and no class in the package referenced anything within it other than constant fields, to determine that the initialiser was never executed, I suppose. I'm not a developer of javac but I'm not convinced that it is a sufficiently useful boundary case to warrant the burden of every execution of javac in the world calculating it. Probably the increased global power usage as a result of this would raise the sea level another micrometer or two for very little benefit in my mind! On 5 March 2010 23:08, Ulf Zibis wrote: > Neal, Keith, thanks for your answer. > > ... but shouldn't javac claim, that there the code in the static block will > be *never reached*, if there is no trigger to run it? > > -Ulf > > > Am 05.03.2010 22:59, schrieb Neal Gafter: > > On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis wrote: > >> No response ?? :-( >> > > Keith's response is correct. An assertion in a method only occurs when the > method is executed. An assertion in a constructor only occurs when the > constructor is called. An assertion in a static initializer only occurs > when the class is statically initialized. Accessing a constant of the class > does not initialize the class. So there is no bug. > > Cheers, > Neal > > >> I've filed a bug: >> >> internal review ID of 1730072 >> >> >> -Ulf >> >> >> >> Am 12.02.2010 15:44, schrieb Ulf Zibis: >> >>> Am 12.02.2010 15:06, schrieb Ulf Zibis: >>> >>>> Hi, >>>> >>>> in the following example, I have an assert statement in a static block >>>> of my class. >>>> >>>> If accessing the static final constants from another class, the static >>>> block is not executed. >>>> This causes the assertions to remain un-proofed, even if -ea -esa is >>>> set. >>>> >>>> Is that correct ? >>>> >>> >>> If yes, javac should claim the code as never reached. >>> >>> >>>> IMO, assertions should always run, if -ea -esa is set. >>>> >>>> -Ulf >>>> >>>> >>> -Ulf >>> >>> >>> >From - Fri Feb 12 16:25:03 2010 >>> X-Account-Key: account2 >>> X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 >>> X-Mozilla-Status: 0000 >>> X-Mozilla-Status2: 00000000 >>> X-Mozilla-Keys: >>> X-Symantec-TimeoutProtection: 0 >>> X-Symantec-TimeoutProtection: 1 >>> X-Symantec-TimeoutProtection: 2 >>> Return-Path: >>> X-Flags: 1001 >>> Delivered-To: GMX delivery to ulf.zibis at gmx.de >>> Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 >>> Received: from brmea-mail-2.Sun.COM (EHLO brmea-mail-2.sun.com) >>> [192.18.98.43] >>> by mx0.gmx.net (mx002) with SMTP; 12 Feb 2010 16:12:59 +0100 >>> Received: from fe-amer-09.sun.com ([192.18.109.79]) >>> by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id >>> o1CFCw62027512 >>> for ; Fri, 12 Feb 2010 15:12:58 GMT >>> MIME-version: 1.0 >>> Content-transfer-encoding: 7BIT >>> Content-type: text/plain; CHARSET=US-ASCII; format=flowed >>> Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com >>> (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) >>> id <0KXQ00800HZH3I00 at mail-amer.sun.com> for Ulf.Zibis at gmx.de; Fri, >>> 12 Feb 2010 08:12:58 -0700 (MST) >>> Received: from [129.150.65.45] ([unknown] [129.150.65.45]) >>> by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 >>> 64bit >>> (built Jul 2 2009)) with ESMTPSA id <0KXQ00GTLI9L1V60 at mail-amer.sun.com>; >>> Fri, >>> 12 Feb 2010 08:12:58 -0700 (MST) >>> Date: Fri, 12 Feb 2010 10:12:58 -0500 >>> From: Keith McGuigan >>> Subject: Re: Assertions in static blocks ? >>> In-reply-to: <4B756071.4000104 at gmx.de> >>> Sender: Keith.McGuigan at Sun.COM >>> To: Ulf Zibis >>> Cc: compiler-dev at openjdk.java.net, hotspot >> > >>> Message-id: <4B756FFA.9000806 at sun.com> >>> References: <4B756071.4000104 at gmx.de> >>> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) >>> X-GMX-Antivirus: 0 (no virus found) >>> X-GMX-Antispam: 0 (Mail was not recognized as spam); >>> Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar >>> >>> zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H >>> >>> PZZzg==V1; >>> X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 >>> >>> >>> >>> Hi Ulf - >>> >>> Accessing a constant static field in a class does not trigger class >>> initialization, so your initializer is probably just not being run. >>> >>> See >>> http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 >>> >>> -- >>> - Keith >>> >>> Ulf Zibis wrote: >>> >>>> Hi, >>>> >>>> in the following example, I have an assert statement in a static block >>>> of my class. >>>> >>>> If accessing the static final constants from another class, the static >>>> block is not executed. >>>> This causes the assertions to remain un-proofed, even if -ea -esa is >>>> set. >>>> >>>> Is that correct ? >>>> >>>> IMO, assertions should always run, if -ea -esa is set. >>>> >>>> -Ulf >>>> >>>> >>>> >>>> package sun.nio.cs.ext; >>>> >>>> import static sun.nio.cs.CharsetMapping.*; >>>> >>>> /** >>>> * >>>> * @author Ulf Zibis, Cologne CoSoCo.de >>>> */ >>>> class EUC_TWMapping3 extends EUC_TWMapping { >>>> static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range >>>> static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 b2c >>>> range >>>> >>>> // TODO: file bug: static block should run, if assertions are enabled. >>>> static { >>>> // assert plane offsets and content >>>> for (int p=0, range, offset=0; p>>> range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>>> for (int i=range; i>>> assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>>> // static block should run, if assertions are enabled. For test >>>> uncomment following line >>>> // System.out.printf("offset: %d, range: %d, b2c[p].length(): >>>> %d%n", offset, range, b2c[p].length()); >>>> assert (offset += range) <= Character.MAX_VALUE + 1; >>>> } >>>> } >>>> >>>> // WORKAROUND: >>>> // static int offset = 0; // assert from calling context to force >>>> static block to process >>>> // static { >>>> // // assert plane offsets and content >>>> // for (int p=0, range; p>>> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>>> // for (int i=range; i>>> // assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>>> //// static block should run, if assertions are enabled. For test >>>> uncomment following line >>>> //// System.out.printf("offset: %d, range: %d, >>>> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >>>> // assert (offset += range) <= Character.MAX_VALUE + 1; >>>> // } >>>> //// static block should run, if assertions are enabled. For test >>>> uncomment following line >>>> //// assert false; >>>> // } >>>> } >>>> >>>> >>>> package sun.nio.cs.ext; >>>> >>>> /** >>>> * >>>> * @author Ulf Zibis, Cologne CoSoCo.de >>>> */ >>>> public class AssertTest { >>>> >>>> public static void main(String... args) { >>>> // static block in EUC_TWMapping3 should run, if assertions are enabled. >>>> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >>>> // WORKAROUND: For test uncomment following line >>>> // assert EUC_TWMapping3.offset > 0; // force assertion, TODO: >>>> JDK bug ? >>>> } >>>> } >>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100305/93d13a4d/attachment.html From jonathan.gibbons at sun.com Fri Mar 5 16:14:47 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Sat, 06 Mar 2010 00:14:47 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100306001501.DFE7143F6E@hg.openjdk.java.net> Changeset: a23282f17d0b Author: jjg Date: 2010-03-05 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a23282f17d0b 6930108: IllegalArgumentException in AbstractDiagnosticFormatter for tools/javac/api/TestJavacTaskScanner.jav Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/api/TestResolveError.java Changeset: a4f3b97c8028 Author: jjg Date: 2010-03-05 16:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a4f3b97c8028 Merge From Jonathan.Gibbons at Sun.COM Fri Mar 5 16:26:28 2010 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 05 Mar 2010 16:26:28 -0800 Subject: Probable enum-related compiler bug In-Reply-To: <7d7138c11002170737n20efd3d7j34feeb972183cd67@mail.gmail.com> References: <7d7138c11002170737n20efd3d7j34feeb972183cd67@mail.gmail.com> Message-ID: <4B91A134.1010803@sun.com> FWIW, it also fails in jdk 1.6.0_17-b02, but works with jdk 1.7.0-ea-b83. -- Jon Dimitris Andreou wrote: > Hi all, > > I have this: > > public enum MyEnum implements Runnable { > X() { public void run() { } }, > } > > and in another file: > > public class Test { > public static void main(String[] args) { > MyEnum.X.run(); > } > } > > Starting from a clean state, compiling it (using jdk 1.6.0_14) > produces this error: > > Test.java:3: cannot find symbol > symbol : method run() > location: class MyEnum > MyEnum.X.run(); > 1 error > > If I first compile MyEnum.java, and in a second step Test.java, no > error is produced. > > The workaround I did to have a stable compilation is this: > > public enum MyEnum implements Runnable { > X() { public void run() { } }, > > public abstract void run(); > } > > > Is this a known bug? > > Regards, > Dimitris From Jonathan.Gibbons at Sun.COM Fri Mar 5 16:34:20 2010 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 05 Mar 2010 16:34:20 -0800 Subject: Probable enum-related compiler bug In-Reply-To: <4B91A134.1010803@sun.com> References: <7d7138c11002170737n20efd3d7j34feeb972183cd67@mail.gmail.com> <4B91A134.1010803@sun.com> Message-ID: <4B91A30C.8060600@sun.com> Known issue, see http://bugs.sun.com/view_bug.do?bug_id=6724345 Fixed in JDK 7 b39. -- Jon Jonathan Gibbons wrote: > FWIW, it also fails in jdk 1.6.0_17-b02, but works with jdk > 1.7.0-ea-b83. > > -- Jon > > > Dimitris Andreou wrote: >> Hi all, >> >> I have this: >> >> public enum MyEnum implements Runnable { >> X() { public void run() { } }, >> } >> >> and in another file: >> >> public class Test { >> public static void main(String[] args) { >> MyEnum.X.run(); >> } >> } >> >> Starting from a clean state, compiling it (using jdk 1.6.0_14) >> produces this error: >> >> Test.java:3: cannot find symbol >> symbol : method run() >> location: class MyEnum >> MyEnum.X.run(); >> 1 error >> >> If I first compile MyEnum.java, and in a second step Test.java, no >> error is produced. >> >> The workaround I did to have a stable compilation is this: >> >> public enum MyEnum implements Runnable { >> X() { public void run() { } }, >> >> public abstract void run(); >> } >> >> >> Is this a known bug? >> >> Regards, >> Dimitris > From Ulf.Zibis at gmx.de Sat Mar 6 03:35:03 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 06 Mar 2010 12:35:03 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B91AFD2.8040503@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> Message-ID: <4B923DE7.403@gmx.de> Am 06.03.2010 02:28, schrieb Keith McGuigan: > Ulf Zibis wrote: >> Neal, Keith, thanks for your answer. >> >> ... but shouldn't javac claim, that there the code in the static >> block will be *never reached*, if there is no trigger to run it? > > Not really. That would be like claiming that the code in a method > will never be reached if no one calls the method. javac can't know > that you're not going to take that class and deploy it somewhere else > with other code that will end up calling the method (or initializing > the class, etc.). But javac can know about the risk, because running Class.forName() is "not very common", especially if there is nothing but constants in that class. The minimum, javac could do is to throw a warning. On the other hand, javac throws errors, even if the stated problem never occurs: char c1 = 12345; char c2 = c1 % 100; would result in ERROR: "possible loss of precision", but c1 *= 12345; compiles without problem. Do you know, if following static initializer will be guaranteed to run, when accessing the static value? : class EUC_TWMapping3 extends EUC_TWMapping { static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range static { PL0_5_B2C_RANGE = 0x2300; // initialized here to force the assertions! PLANE_B2C_RANGE = 0x1f00; // " " " // assert by values from EUC_TWMapping assert PL0_5_B2C_RANGE >= b2c.length; assert PLANE_B2C_RANGE <= b2c.length; } } -Ulf From Ulf.Zibis at gmx.de Sat Mar 6 03:44:43 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 06 Mar 2010 12:44:43 +0100 Subject: Assertions in static blocks ? In-Reply-To: <51a29d951003051533v2750b564pbd99e7c590af95d7@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <51a29d951003051533v2750b564pbd99e7c590af95d7@mail.gmail.com> Message-ID: <4B92402B.8080403@gmx.de> Am 06.03.2010 00:33, schrieb Benedict Elliott Smith: > It's not /generally/ possible to determine if a class initializer will > ever be run. > > It would be possible to determine that, if a class were declared with > default (package) level protection and was never referenced by another > class in the package, that the class was not used (/so long as the > program did not violate the protection via reflection)/; but this is > the best that could be achieved (there is an argument to be made for > javac to complain in this case, as it will in the case of unused > private classes, however I am not certain it is necessary), however I > do not think this is what you are suggesting. > > It would be possible, if the class were declared with default > protection, and no class in the package referenced anything within it > other than constant fields, to determine that the initialiser was > never executed, I suppose. My class *is* package private, but I can't see how it should help. ... and currently it doesn't help to make the static initializer running. > I'm not a developer of javac but I'm not convinced that it is a > sufficiently useful boundary case to warrant the burden of every > execution of javac in the world calculating it. Probably > the increased global power usage as a result of this would raise the > sea level another micrometer or two for very little benefit in my mind! I like to think about power usage. That's the reason I'm working on EUC_TW charset making it faster and consuming less memory. Checking practically never reached static blocks seems to be nothing than working on a system using EUC_TW charset. -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100306/5c782d39/attachment.html From schlosna at gmail.com Sat Mar 6 11:55:33 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 6 Mar 2010 14:55:33 -0500 Subject: Assertions in static blocks ? In-Reply-To: <4B923DE7.403@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> Message-ID: <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> Ulf, The behavior you're encountering is consistent with JLS ?4.12.4 [1] which states: We call a variable, of primitive type or type String, that is final and initialized with a compile-time constant expression (?15.28) a constant variable. Whether a variable is a constant variable or not may have implications with respect to class initialization (?12.4.1), binary compatibility (?13.1, ?13.4.9) and definite assignment (?16). Later in JLS ?13.1 [2] it states: References to fields that are constant variables (?4.12.4) are resolved at compile time to the constant value that is denoted. No reference to such a constant field should be present in the code in a binary file (except in the class or interface containing the constant field, which will have code to initialize it), and such constant fields must always appear to have been initialized; the default initial value for the type of such a field must never be observed. See ?13.4.8 for a discussion. Check out Java Puzzler 93: Class Warfare [3] which gives an example of this and how it impacts binary compatibility. Josh and Neal also covered this in the 2009 JavaOne Puzzler talk, see #7 "When Words Collide" [4]. Based on that, anywhere that PL0_5_B2C_RANGE or PLANE_B2C_RANGE are used the actual values will be inlined into the referencing class file at compile time as "sipush 8960" or "sipush 7936" respectively, and therefore do not reference the class EUC_TWMapping3 or cause it to be initialized. If you do want to ensure the assertions are run when at class initialization, I'd recommend something like the following which will ensure that the value is not inlined at compile time: class EUC_TWMapping3 extends EUC_TWMapping { static final short PL0_5_B2C_RANGE = planeZeroFiveB2CRange(); // plane 0, 5 b2c range static final short PLANE_B2C_RANGE = planeB2CRange(); // plane 2..4, 6..15 b2c range private static final short planeZeroFiveB2CRange() { short range = 0x2300; // plane 0, 5 b2c range assert range >= b2c.length; // assert by values from EUC_TWMapping return range; } private static final short planeB2CRange() { short range = 0x1f00; // plane 2..4, 6..15 b2c range assert range <= b2c.length; // assert by values from EUC_TWMapping return range; } } [1]: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4 [2]: http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.1 [3]: http://www.javapuzzlers.com [4]: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5186&yr=2009&track=javase - Dave On Sat, Mar 6, 2010 at 6:35 AM, Ulf Zibis wrote: > Am 06.03.2010 02:28, schrieb Keith McGuigan: >> >> Ulf Zibis wrote: >>> >>> Neal, Keith, thanks for your answer. >>> >>> ... but shouldn't javac claim, that there the code in the static block >>> will be *never reached*, if there is no trigger to run it? >> >> Not really. That would be like claiming that the code in a method will >> never be reached if no one calls the method. javac can't know that you're >> not going to take that class and deploy it somewhere else with other code >> that will end up calling the method (or initializing the class, etc.). > > But javac can know about the risk, because running Class.forName() is "not > very common", especially if there is nothing but constants in that class. > The minimum, javac could do is to throw a warning. > > On the other hand, javac throws errors, even if the stated problem never > occurs: > char c1 = 12345; > char c2 = c1 % 100; > would result in ERROR: "possible loss of precision", but > c1 *= 12345; > compiles without problem. > > Do you know, if following static initializer will be guaranteed to run, when > accessing the static value? : > > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range > static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range > static { > PL0_5_B2C_RANGE = 0x2300; // initialized here to force the > assertions! > PLANE_B2C_RANGE = 0x1f00; // " " " > // assert by values from EUC_TWMapping > assert PL0_5_B2C_RANGE >= b2c.length; > assert PLANE_B2C_RANGE <= b2c.length; > } > } > > -Ulf > > > > From Ulf.Zibis at gmx.de Sat Mar 6 12:24:04 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 06 Mar 2010 21:24:04 +0100 Subject: Assertions in static blocks ? In-Reply-To: <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> Message-ID: <4B92B9E4.2010001@gmx.de> David, very much thanks for your detailed explanation and your effort checking the spec. :-) I've found a much simpler workaround which seems to work as expected: class EUC_TWMapping3 extends EUC_TWMapping2 { static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range static { PL0_5_B2C_RANGE = 0x2300; // Initialize here to force the static block PLANE_B2C_RANGE = 0x1f00; // and the assertions, if enabled, to run. // assert plane offsets and content for (int p=0, range, offset=0; p Ulf, > > The behavior you're encountering is consistent with JLS ?4.12.4 [1] which > states: > We call a variable, of primitive type or type String, that is final and > initialized with a compile-time constant expression (?15.28) a constant > variable. Whether a variable is a constant variable or not may have > implications with respect to class initialization (?12.4.1), binary > compatibility (?13.1, ?13.4.9) and definite assignment (?16). > > Later in JLS ?13.1 [2] it states: > References to fields that are constant variables (?4.12.4) are resolved at > compile time to the constant value that is denoted. No reference to such a > constant field should be present in the code in a binary file (except in > the class or interface containing the constant field, which will have code > to initialize it), and such constant fields must always appear to have been > initialized; the default initial value for the type of such a field must > never be observed. See ?13.4.8 for a discussion. > > Check out Java Puzzler 93: Class Warfare [3] which gives an example of this and > how it impacts binary compatibility. Josh and Neal also covered this in the > 2009 JavaOne Puzzler talk, see #7 "When Words Collide" [4]. > > Based on that, anywhere that PL0_5_B2C_RANGE or PLANE_B2C_RANGE are used the > actual values will be inlined into the referencing class file at compile time > as "sipush 8960" or "sipush 7936" respectively, and therefore do not reference > the class EUC_TWMapping3 or cause it to be initialized. > > If you do want to ensure the assertions are run when at class initialization, > I'd recommend something like the following which will ensure that the value is > not inlined at compile time: > > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE = planeZeroFiveB2CRange(); // > plane 0, 5 b2c range > static final short PLANE_B2C_RANGE = planeB2CRange(); // plane > 2..4, 6..15 b2c range > > private static final short planeZeroFiveB2CRange() { > short range = 0x2300; // plane 0, 5 b2c range > assert range>= b2c.length; // assert by values from EUC_TWMapping > return range; > } > > private static final short planeB2CRange() { > short range = 0x1f00; // plane 2..4, 6..15 b2c range > assert range<= b2c.length; // assert by values from EUC_TWMapping > return range; > } > } > > [1]: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4 > [2]: http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.1 > [3]: http://www.javapuzzlers.com > [4]: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5186&yr=2009&track=javase > > - Dave > > > > On Sat, Mar 6, 2010 at 6:35 AM, Ulf Zibis wrote: > >> Am 06.03.2010 02:28, schrieb Keith McGuigan: >> >>> Ulf Zibis wrote: >>> >>>> Neal, Keith, thanks for your answer. >>>> >>>> ... but shouldn't javac claim, that there the code in the static block >>>> will be *never reached*, if there is no trigger to run it? >>>> >>> Not really. That would be like claiming that the code in a method will >>> never be reached if no one calls the method. javac can't know that you're >>> not going to take that class and deploy it somewhere else with other code >>> that will end up calling the method (or initializing the class, etc.). >>> >> But javac can know about the risk, because running Class.forName() is "not >> very common", especially if there is nothing but constants in that class. >> The minimum, javac could do is to throw a warning. >> >> On the other hand, javac throws errors, even if the stated problem never >> occurs: >> char c1 = 12345; >> char c2 = c1 % 100; >> would result in ERROR: "possible loss of precision", but >> c1 *= 12345; >> compiles without problem. >> >> Do you know, if following static initializer will be guaranteed to run, when >> accessing the static value? : >> >> class EUC_TWMapping3 extends EUC_TWMapping { >> static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range >> static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range >> static { >> PL0_5_B2C_RANGE = 0x2300; // initialized here to force the >> assertions! >> PLANE_B2C_RANGE = 0x1f00; // " " " >> // assert by values from EUC_TWMapping >> assert PL0_5_B2C_RANGE>= b2c.length; >> assert PLANE_B2C_RANGE<= b2c.length; >> } >> } >> >> -Ulf >> >> >> >> >> > > From kelly.ohair at sun.com Sat Mar 6 15:00:11 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 06 Mar 2010 23:00:11 +0000 Subject: hg: jdk7/tl/jdk: 6915983: testing problems, adjusting list of tests, needs some investigation Message-ID: <20100306230106.5B8CA440AE@hg.openjdk.java.net> Changeset: 58b44ac0b10d Author: ohair Date: 2010-03-06 14:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58b44ac0b10d 6915983: testing problems, adjusting list of tests, needs some investigation Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt From kelly.ohair at sun.com Sat Mar 6 15:01:34 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 06 Mar 2010 23:01:34 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20100306230134.7DB32440AF@hg.openjdk.java.net> Changeset: 4d7419e4b759 Author: ohair Date: 2010-03-06 15:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4d7419e4b759 6928700: Configure top repo for JPRT testing Reviewed-by: alanb, jjg ! make/jprt.properties + test/Makefile Changeset: f3664d6879ab Author: ohair Date: 2010-03-06 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f3664d6879ab Merge From schlosna at gmail.com Sat Mar 6 17:39:28 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 6 Mar 2010 20:39:28 -0500 Subject: Assertions in static blocks ? In-Reply-To: <4B92F492.6000305@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> Message-ID: <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> David, You're correct, Ulf's example code from earlier today where the actual value is initialized in a static initializer block does use getstatic and would trigger the EUC_TWMapping3 class's initialization and provides the desired functionality. Sorry, I meant to clarify the answer to Ulf's original email from February 12 "If accessing the static final constants from another class, the static block is not executed." showing this isn't a bug. In that email's code they were compile time constants, and the JLS justifies why the static block wasn't executed. This can lead to surprising behavior if you're not aware of it which is one reason I prefer extracting any complex initialization behavior into a separate method when possible to make it more explicit. - Dave On Fri, Feb 12, 2010 at 9:06 AM, Ulf Zibis wrote: > If accessing the static final constants from another class, the static block > is not executed. > This causes the assertions to remain un-proofed, even if -ea -esa is set. > > Is that correct ? ...snip... > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range > static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 b2c > range On Sat, Mar 6, 2010 at 7:34 PM, David Holmes - Sun Microsystems wrote: > David, Ulf, > > Note that in Ulf's example: > > class EUC_TWMapping3 extends EUC_TWMapping { > ? ?static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range > ? ?static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range > ? ?static { > ? ? ? ?PL0_5_B2C_RANGE = 0x2300; // initialized here to force the > assertions! > ? ? ? ?PLANE_B2C_RANGE = 0x1f00; // ? ? ?" ? ? ? ? ? ? " ? ? ? ? ? ?" > ? ? ? ?// assert by values from EUC_TWMapping > ? ? ? ?assert PL0_5_B2C_RANGE >= b2c.length; > ? ? ? ?assert PLANE_B2C_RANGE <= b2c.length; > ? ?} > } > > the fields are _NOT_ initialized with compile-time constant expressions and > so access to them will be via a getstatic bytecode which will result in > class initialization. > > David Holmes > ------------ > > David Schlosnagle said the following on 03/07/10 05:55: >> >> Ulf, >> >> The behavior you're encountering is consistent with JLS ?4.12.4 [1] which >> states: >> ? ?We call a variable, of primitive type or type String, that is final and >> ? ?initialized with a compile-time constant expression (?15.28) a constant >> ? ?variable. Whether a variable is a constant variable or not may have >> ? ?implications with respect to class initialization (?12.4.1), binary >> ? ?compatibility (?13.1, ?13.4.9) and definite assignment (?16). >> >> Later in JLS ?13.1 [2] it states: >> ? ?References to fields that are constant variables (?4.12.4) ?are >> resolved at >> ? ?compile time to the constant value that is denoted. No reference to >> such a >> ? ?constant field should be present in the code in a binary file (except >> in >> ? ?the class or interface containing the constant field, which will have >> code >> ? ?to initialize it), and such constant fields must always appear to have >> been >> ? ?initialized; the default initial value for the type of such a field >> must >> ? ?never be observed. See ?13.4.8 for a discussion. >> >> Check out Java Puzzler 93: Class Warfare [3] which gives an example of >> this and >> how it impacts binary compatibility. Josh and Neal also covered this in >> the >> 2009 JavaOne Puzzler talk, see #7 "When Words Collide" [4]. >> >> Based on that, anywhere that PL0_5_B2C_RANGE or PLANE_B2C_RANGE are used >> the >> actual values will be inlined into the referencing class file at compile >> time >> as "sipush ?8960" or "sipush 7936" respectively, and therefore do not >> reference >> the class EUC_TWMapping3 or cause it to be initialized. >> >> If you do want to ensure the assertions are run when at class >> initialization, >> I'd recommend something like the following which will ensure that the >> value is >> not inlined at compile time: >> >> class EUC_TWMapping3 extends EUC_TWMapping { >> ? ?static final short PL0_5_B2C_RANGE = planeZeroFiveB2CRange(); // >> plane 0, 5 b2c range >> ? ?static final short PLANE_B2C_RANGE = planeB2CRange(); // plane >> 2..4, 6..15 b2c range >> >> ? ?private static final short planeZeroFiveB2CRange() { >> ? ? ? ?short range = 0x2300; // plane 0, 5 b2c range >> ? ? ? ?assert range >= b2c.length; // assert by values from EUC_TWMapping >> ? ? ? ?return range; >> ? ?} >> >> ? ?private static final short planeB2CRange() { >> ? ? ? ?short range = 0x1f00; // plane 2..4, 6..15 b2c range >> ? ? ? ?assert range <= b2c.length; // assert by values from EUC_TWMapping >> ? ? ? ?return range; >> ? ?} >> } >> >> [1]: >> http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4 >> [2]: >> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.1 >> [3]: http://www.javapuzzlers.com >> [4]: >> http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5186&yr=2009&track=javase >> >> - Dave >> >> >> >> On Sat, Mar 6, 2010 at 6:35 AM, Ulf Zibis wrote: >>> >>> Am 06.03.2010 02:28, schrieb Keith McGuigan: >>>> >>>> Ulf Zibis wrote: >>>>> >>>>> Neal, Keith, thanks for your answer. >>>>> >>>>> ... but shouldn't javac claim, that there the code in the static block >>>>> will be *never reached*, if there is no trigger to run it? >>>> >>>> Not really. ?That would be like claiming that the code in a method will >>>> never be reached if no one calls the method. ?javac can't know that >>>> you're >>>> not going to take that class and deploy it somewhere else with other >>>> code >>>> that will end up calling the method (or initializing the class, etc.). >>> >>> But javac can know about the risk, because running Class.forName() is >>> "not >>> very common", especially if there is nothing but constants in that class. >>> The minimum, javac could do is to throw a warning. >>> >>> On the other hand, javac throws errors, even if the stated problem never >>> occurs: >>> ? ? ? ? ? char c1 = 12345; >>> ? ? ? ? ? char c2 = c1 % 100; >>> would result in ERROR: "possible loss of precision", but >>> ? ? ? ? ? c1 *= 12345; >>> compiles without problem. >>> >>> Do you know, if following static initializer will be guaranteed to run, >>> when >>> accessing the static value? : >>> >>> class EUC_TWMapping3 extends EUC_TWMapping { >>> ? static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range >>> ? static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range >>> ? static { >>> ? ? ? PL0_5_B2C_RANGE = 0x2300; // initialized here to force the >>> assertions! >>> ? ? ? PLANE_B2C_RANGE = 0x1f00; // ? ? ?" ? ? ? ? ? ? " ? ? ? ? ? ?" >>> ? ? ? // assert by values from EUC_TWMapping >>> ? ? ? assert PL0_5_B2C_RANGE >= b2c.length; >>> ? ? ? assert PLANE_B2C_RANGE <= b2c.length; >>> ? } >>> } >>> >>> -Ulf >>> >>> >>> >>> > From Ulf.Zibis at gmx.de Sun Mar 7 07:40:43 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 07 Mar 2010 16:40:43 +0100 Subject: Assertions in static blocks ? In-Reply-To: <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> Message-ID: <4B93C8FB.4090709@gmx.de> Am 07.03.2010 02:39, schrieb David Schlosnagle: > David, > > You're correct, Ulf's example code from earlier today where the actual > value is initialized in a static initializer block does use getstatic > and would trigger the EUC_TWMapping3 class's initialization and > provides the desired functionality. > > Sorry, I meant to clarify the answer to Ulf's original email from > February 12 "If accessing the static final constants from another > class, the static block is not executed." showing this isn't a bug. In > that email's code they were compile time constants, and the JLS > justifies why the static block wasn't executed. This can lead to > surprising behavior if you're not aware of it which is one reason I > prefer extracting any complex initialization behavior into a separate > method when possible to make it more explicit. > Aside: I prefer short and fast code, and would put the "make it more explicit" in a comment. ;-) In contrast to Keith and Neal, I think, we agree, that this "behaviour is surprising", so I would vote at least for a *warning* from javac side. -Ulf From Ulf.Zibis at gmx.de Mon Mar 8 04:40:09 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 08 Mar 2010 13:40:09 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B9426B0.1070308@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> <4B9426B0.1070308@sun.com> Message-ID: <4B94F029.6030006@gmx.de> Am 07.03.2010 23:20, schrieb David Holmes - Sun Microsystems: > Ulf Zibis said the following on 03/08/10 01:40: >> In contrast to Keith and Neal, I think, we agree, that this >> "behaviour is surprising", so I would vote at least for a *warning* >> from javac side. > > I'm with Keith and Neal, this is all "working as designed". How can > javac in general know whether or not a class will be initialized. This is not the question here. The question is if it *can* be initialized, (1) via standard java instruction or (2) via any other special magic like reflective call from Class.forName(). javac surely has knowledge about that. If (1) could never be reached, there should be a warning, in particular for less experienced programmers, E.g.: "static initializer will never be triggered by any member or method of this class. Could only be invoked by loading the class explicitly or inherently(not sure)" > A static initializer is no different to a method or constructor in > that regard: none of them are ever flagged as unreachable because that > can't be determined a-priori by javac. IMHO there is a _big_ difference on normal constructors and methods: 1. They _can_ always be executed by normal java instruction. 2. They will _never_ be executed, if not explicitly called from code. On static initializers it's quite different: 1. They _cannot_ be executed by normal java instruction. 2. They will _mostly_ be _automatically_ executed but not ever, if a member/method from it's class is called > > At the absolute most I can concede that javac might issue a warning if > a class consisted only of constant field declarations and had a static > initializer, as no use of the fields would lead to initialization. But > even then I don't think this is worth the effort. From my point of view, warnings about "unchecked conversion" are often not worth the effort. I can't imagine any case, what could become broken, if ignored here: List list = new ArrayList(); -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100308/318ebbaa/attachment.html From David.Holmes at Sun.COM Sat Mar 6 16:34:26 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sun, 07 Mar 2010 10:34:26 +1000 Subject: Assertions in static blocks ? In-Reply-To: <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> Message-ID: <4B92F492.6000305@sun.com> David, Ulf, Note that in Ulf's example: class EUC_TWMapping3 extends EUC_TWMapping { static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range static { PL0_5_B2C_RANGE = 0x2300; // initialized here to force the assertions! PLANE_B2C_RANGE = 0x1f00; // " " " // assert by values from EUC_TWMapping assert PL0_5_B2C_RANGE >= b2c.length; assert PLANE_B2C_RANGE <= b2c.length; } } the fields are _NOT_ initialized with compile-time constant expressions and so access to them will be via a getstatic bytecode which will result in class initialization. David Holmes ------------ David Schlosnagle said the following on 03/07/10 05:55: > Ulf, > > The behavior you're encountering is consistent with JLS ?4.12.4 [1] which > states: > We call a variable, of primitive type or type String, that is final and > initialized with a compile-time constant expression (?15.28) a constant > variable. Whether a variable is a constant variable or not may have > implications with respect to class initialization (?12.4.1), binary > compatibility (?13.1, ?13.4.9) and definite assignment (?16). > > Later in JLS ?13.1 [2] it states: > References to fields that are constant variables (?4.12.4) are resolved at > compile time to the constant value that is denoted. No reference to such a > constant field should be present in the code in a binary file (except in > the class or interface containing the constant field, which will have code > to initialize it), and such constant fields must always appear to have been > initialized; the default initial value for the type of such a field must > never be observed. See ?13.4.8 for a discussion. > > Check out Java Puzzler 93: Class Warfare [3] which gives an example of this and > how it impacts binary compatibility. Josh and Neal also covered this in the > 2009 JavaOne Puzzler talk, see #7 "When Words Collide" [4]. > > Based on that, anywhere that PL0_5_B2C_RANGE or PLANE_B2C_RANGE are used the > actual values will be inlined into the referencing class file at compile time > as "sipush 8960" or "sipush 7936" respectively, and therefore do not reference > the class EUC_TWMapping3 or cause it to be initialized. > > If you do want to ensure the assertions are run when at class initialization, > I'd recommend something like the following which will ensure that the value is > not inlined at compile time: > > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE = planeZeroFiveB2CRange(); // > plane 0, 5 b2c range > static final short PLANE_B2C_RANGE = planeB2CRange(); // plane > 2..4, 6..15 b2c range > > private static final short planeZeroFiveB2CRange() { > short range = 0x2300; // plane 0, 5 b2c range > assert range >= b2c.length; // assert by values from EUC_TWMapping > return range; > } > > private static final short planeB2CRange() { > short range = 0x1f00; // plane 2..4, 6..15 b2c range > assert range <= b2c.length; // assert by values from EUC_TWMapping > return range; > } > } > > [1]: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4 > [2]: http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.1 > [3]: http://www.javapuzzlers.com > [4]: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5186&yr=2009&track=javase > > - Dave > > > > On Sat, Mar 6, 2010 at 6:35 AM, Ulf Zibis wrote: >> Am 06.03.2010 02:28, schrieb Keith McGuigan: >>> Ulf Zibis wrote: >>>> Neal, Keith, thanks for your answer. >>>> >>>> ... but shouldn't javac claim, that there the code in the static block >>>> will be *never reached*, if there is no trigger to run it? >>> Not really. That would be like claiming that the code in a method will >>> never be reached if no one calls the method. javac can't know that you're >>> not going to take that class and deploy it somewhere else with other code >>> that will end up calling the method (or initializing the class, etc.). >> But javac can know about the risk, because running Class.forName() is "not >> very common", especially if there is nothing but constants in that class. >> The minimum, javac could do is to throw a warning. >> >> On the other hand, javac throws errors, even if the stated problem never >> occurs: >> char c1 = 12345; >> char c2 = c1 % 100; >> would result in ERROR: "possible loss of precision", but >> c1 *= 12345; >> compiles without problem. >> >> Do you know, if following static initializer will be guaranteed to run, when >> accessing the static value? : >> >> class EUC_TWMapping3 extends EUC_TWMapping { >> static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range >> static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range >> static { >> PL0_5_B2C_RANGE = 0x2300; // initialized here to force the >> assertions! >> PLANE_B2C_RANGE = 0x1f00; // " " " >> // assert by values from EUC_TWMapping >> assert PL0_5_B2C_RANGE >= b2c.length; >> assert PLANE_B2C_RANGE <= b2c.length; >> } >> } >> >> -Ulf >> >> >> >> From David.Holmes at Sun.COM Sun Mar 7 14:20:32 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 08 Mar 2010 08:20:32 +1000 Subject: Assertions in static blocks ? In-Reply-To: <4B93C8FB.4090709@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> Message-ID: <4B9426B0.1070308@sun.com> Ulf Zibis said the following on 03/08/10 01:40: > In contrast to Keith and Neal, I think, we agree, that this "behaviour > is surprising", so I would vote at least for a *warning* from javac side. I'm with Keith and Neal, this is all "working as designed". How can javac in general know whether or not a class will be initialized. A static initializer is no different to a method or constructor in that regard: none of them are ever flagged as unreachable because that can't be determined a-priori by javac. At the absolute most I can concede that javac might issue a warning if a class consisted only of constant field declarations and had a static initializer, as no use of the fields would lead to initialization. But even then I don't think this is worth the effort. Regards, David Holmes From David.Holmes at Sun.COM Mon Mar 8 14:48:30 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 09 Mar 2010 08:48:30 +1000 Subject: Assertions in static blocks ? In-Reply-To: <4B94F029.6030006@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> <4B9426B0.1070308@sun.com> <4B94F029.6030006@gmx.de> Message-ID: <4B957EBE.5010905@sun.com> Ulf Zibis said the following on 03/08/10 22:40: > Am 07.03.2010 23:20, schrieb David Holmes - Sun Microsystems: >> Ulf Zibis said the following on 03/08/10 01:40: >>> In contrast to Keith and Neal, I think, we agree, that this >>> "behaviour is surprising", so I would vote at least for a *warning* >>> from javac side. >> >> I'm with Keith and Neal, this is all "working as designed". How can >> javac in general know whether or not a class will be initialized. > > This is not the question here. The question is if it *can* be > initialized, (1) via standard java instruction or (2) via any other > special magic like reflective call from Class.forName(). javac surely > has knowledge about that. Both (1) and (2) depend on your whole program not the class being compiled. So javac can not know the answer to this at compile time. > If (1) could never be reached, there should be a warning, in particular > for less experienced programmers, E.g.: > "static initializer will never be triggered by any member or method of > this class. Could only be invoked by loading the class explicitly or > inherently(not sure)" No that doesn't make sense. A classes own methods/members are not the trigger for classloading and/or initialization. It is the use of those methods/members by other classes that triggers the loading/initialization of the class containing the method/member. >> A static initializer is no different to a method or constructor in >> that regard: none of them are ever flagged as unreachable because that >> can't be determined a-priori by javac. > > IMHO there is a _big_ difference on normal constructors and methods: > 1. They _can_ always be executed by normal java instruction. > 2. They will _never_ be executed, if not explicitly called from code. > On static initializers it's quite different: > 1. They _cannot_ be executed by normal java instruction. > 2. They will _mostly_ be _automatically_ executed but not ever, if a > member/method from it's class is called The implicit vs explicit nature of the execution doesn't change the fact that to determine if either is executed you need to look at the whole program - not just the class(es) being compiled. David Holmes > >> >> At the absolute most I can concede that javac might issue a warning if >> a class consisted only of constant field declarations and had a static >> initializer, as no use of the fields would lead to initialization. But >> even then I don't think this is worth the effort. > > From my point of view, warnings about "unchecked conversion" are often > not worth the effort. I can't imagine any case, what could become > broken, if ignored here: > List list = new ArrayList(); > > > -Ulf > From Joe.Darcy at Sun.COM Mon Mar 8 17:30:10 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 08 Mar 2010 17:30:10 -0800 Subject: Probable enum-related compiler bug In-Reply-To: <4B91A30C.8060600@sun.com> References: <7d7138c11002170737n20efd3d7j34feeb972183cd67@mail.gmail.com> <4B91A134.1010803@sun.com> <4B91A30C.8060600@sun.com> Message-ID: <4B95A4A2.7050606@sun.com> Jonathan Gibbons wrote: > Known issue, see http://bugs.sun.com/view_bug.do?bug_id=6724345 > Fixed in JDK 7 b39. And if you're on Linux, this fix will be included in OpenJDK 6 b19. -Joe > > -- Jon > > > Jonathan Gibbons wrote: >> FWIW, it also fails in jdk 1.6.0_17-b02, but works with jdk >> 1.7.0-ea-b83. >> >> -- Jon >> >> >> Dimitris Andreou wrote: >>> Hi all, >>> >>> I have this: >>> >>> public enum MyEnum implements Runnable { >>> X() { public void run() { } }, >>> } >>> >>> and in another file: >>> >>> public class Test { >>> public static void main(String[] args) { >>> MyEnum.X.run(); >>> } >>> } >>> >>> Starting from a clean state, compiling it (using jdk 1.6.0_14) >>> produces this error: >>> >>> Test.java:3: cannot find symbol >>> symbol : method run() >>> location: class MyEnum >>> MyEnum.X.run(); >>> 1 error >>> >>> If I first compile MyEnum.java, and in a second step Test.java, no >>> error is produced. >>> >>> The workaround I did to have a stable compilation is this: >>> >>> public enum MyEnum implements Runnable { >>> X() { public void run() { } }, >>> >>> public abstract void run(); >>> } >>> >>> >>> Is this a known bug? >>> >>> Regards, >>> Dimitris >> > From Ulf.Zibis at gmx.de Tue Mar 9 09:39:36 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 09 Mar 2010 18:39:36 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B957EBE.5010905@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> <4B9426B0.1070308@sun.com> <4B94F029.6030006@gmx.de> <4B957EBE.5010905@sun.com> Message-ID: <4B9687D8.906@gmx.de> Am 08.03.2010 23:48, schrieb David Holmes - Sun Microsystems: > Ulf Zibis said the following on 03/08/10 22:40: >> Am 07.03.2010 23:20, schrieb David Holmes - Sun Microsystems: >>> I'm with Keith and Neal, this is all "working as designed". How can >>> javac in general know whether or not a class will be initialized. >> >> This is not the question here. The question is if it *can* be >> initialized, (1) via standard java instruction or (2) via any other >> special magic like reflective call from Class.forName(). javac surely >> has knowledge about that. > > Both (1) and (2) depend on your whole program not the class being > compiled. So javac can not know the answer to this at compile time. Sorry, maybe I'm missing something. Can you give me an example how static initializer could be triggered by (1), if there are only static final primitive type constants in that class? > >> If (1) could never be reached, there should be a warning, in >> particular for less experienced programmers, E.g.: >> "static initializer will never be triggered by any member or method >> of this class. Could only be invoked by loading the class explicitly >> or inherently(not sure)" > > No that doesn't make sense. A classes own methods/members are not the > trigger for classloading and/or initialization. It is the use of those > methods/members by other classes that triggers the > loading/initialization of the class containing the method/member. Sorry for the bad wording, I meant "... triggered by access to any member or method of this class. ..." or "There are no members or methods which could trigger the static initializer to run, so it may be never reached. ..." > >>> A static initializer is no different to a method or constructor in >>> that regard: none of them are ever flagged as unreachable because >>> that can't be determined a-priori by javac. >> >> IMHO there is a _big_ difference on normal constructors and methods: >> 1. They _can_ always be executed by normal java instruction. >> 2. They will _never_ be executed, if not explicitly called from code. >> On static initializers it's quite different: >> 1. They _cannot_ be executed by normal java instruction. >> 2. They will _mostly_ be _automatically_ executed but not ever, if a >> member/method from it's class is called > > The implicit vs explicit nature of the execution doesn't change the > fact that to determine if either is executed you need to look at the > whole program - not just the class(es) being compiled. Yes, but I can't imagine any other trigger than meant under (2). Hope, that I'm bothering too much, -Ulf From Jonathan.Gibbons at Sun.COM Tue Mar 9 10:53:40 2010 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 09 Mar 2010 10:53:40 -0800 Subject: Assertions in static blocks ? In-Reply-To: <4B9687D8.906@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> <4B9426B0.1070308@sun.com> <4B94F029.6030006@gmx.de> <4B957EBE.5010905@sun.com> <4B9687D8.906@gmx.de> Message-ID: <4B969934.4020300@sun.com> Ulf Zibis wrote: > Am 08.03.2010 23:48, schrieb David Holmes - Sun Microsystems: >> Ulf Zibis said the following on 03/08/10 22:40: >>> Am 07.03.2010 23:20, schrieb David Holmes - Sun Microsystems: >>>> I'm with Keith and Neal, this is all "working as designed". How can >>>> javac in general know whether or not a class will be initialized. >>> >>> This is not the question here. The question is if it *can* be >>> initialized, (1) via standard java instruction or (2) via any other >>> special magic like reflective call from Class.forName(). javac >>> surely has knowledge about that. >> >> Both (1) and (2) depend on your whole program not the class being >> compiled. So javac can not know the answer to this at compile time. > > Sorry, maybe I'm missing something. Can you give me an example how > static initializer could be triggered by (1), if there are only static > final primitive type constants in that class? > >> >>> If (1) could never be reached, there should be a warning, in >>> particular for less experienced programmers, E.g.: >>> "static initializer will never be triggered by any member or method >>> of this class. Could only be invoked by loading the class explicitly >>> or inherently(not sure)" >> >> No that doesn't make sense. A classes own methods/members are not the >> trigger for classloading and/or initialization. It is the use of >> those methods/members by other classes that triggers the >> loading/initialization of the class containing the method/member. > > Sorry for the bad wording, I meant "... triggered by access to any > member or method of this class. ..." > or "There are no members or methods which could trigger the static > initializer to run, so it may be never reached. ..." > >> >>>> A static initializer is no different to a method or constructor in >>>> that regard: none of them are ever flagged as unreachable because >>>> that can't be determined a-priori by javac. >>> >>> IMHO there is a _big_ difference on normal constructors and methods: >>> 1. They _can_ always be executed by normal java instruction. >>> 2. They will _never_ be executed, if not explicitly called from code. >>> On static initializers it's quite different: >>> 1. They _cannot_ be executed by normal java instruction. >>> 2. They will _mostly_ be _automatically_ executed but not ever, if a >>> member/method from it's class is called >> >> The implicit vs explicit nature of the execution doesn't change the >> fact that to determine if either is executed you need to look at the >> whole program - not just the class(es) being compiled. > > Yes, but I can't imagine any other trigger than meant under (2). > > Hope, that I'm bothering too much, > > -Ulf > > There's a default constructor on the class, allowing you to write "new EUC_TWMapping3()". -- Jon From Ulf.Zibis at gmx.de Tue Mar 9 13:03:17 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 09 Mar 2010 22:03:17 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B969934.4020300@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> <4B9426B0.1070308@sun.com> <4B94F029.6030006@gmx.de> <4B957EBE.5010905@sun.com> <4B9687D8.906@gmx.de> <4B969934.4020300@sun.com> Message-ID: <4B96B795.2090402@gmx.de> Am 09.03.2010 19:53, schrieb Jonathan Gibbons: > Ulf Zibis wrote: >> Am 08.03.2010 23:48, schrieb David Holmes - Sun Microsystems: >>> Ulf Zibis said the following on 03/08/10 22:40: >>>> Am 07.03.2010 23:20, schrieb David Holmes - Sun Microsystems: >>>>> I'm with Keith and Neal, this is all "working as designed". How >>>>> can javac in general know whether or not a class will be initialized. >>>> >>>> This is not the question here. The question is if it *can* be >>>> initialized, (1) via standard java instruction or (2) via any other >>>> special magic like reflective call from Class.forName(). javac >>>> surely has knowledge about that. >>> >>> Both (1) and (2) depend on your whole program not the class being >>> compiled. So javac can not know the answer to this at compile time. >> >> Sorry, maybe I'm missing something. Can you give me an example how >> static initializer could be triggered by (1), if there are only >> static final primitive type constants in that class? >> >>> >>>> If (1) could never be reached, there should be a warning, in >>>> particular for less experienced programmers, E.g.: >>>> "static initializer will never be triggered by any member or method >>>> of this class. Could only be invoked by loading the class >>>> explicitly or inherently(not sure)" >>> >>> No that doesn't make sense. A classes own methods/members are not >>> the trigger for classloading and/or initialization. It is the use of >>> those methods/members by other classes that triggers the >>> loading/initialization of the class containing the method/member. >> >> Sorry for the bad wording, I meant "... triggered by access to any >> member or method of this class. ..." >> or "There are no members or methods which could trigger the static >> initializer to run, so it may be never reached. ..." >> >>> >>>>> A static initializer is no different to a method or constructor in >>>>> that regard: none of them are ever flagged as unreachable because >>>>> that can't be determined a-priori by javac. >>>> >>>> IMHO there is a _big_ difference on normal constructors and methods: >>>> 1. They _can_ always be executed by normal java instruction. >>>> 2. They will _never_ be executed, if not explicitly called from code. >>>> On static initializers it's quite different: >>>> 1. They _cannot_ be executed by normal java instruction. >>>> 2. They will _mostly_ be _automatically_ executed but not ever, if >>>> a member/method from it's class is called >>> >>> The implicit vs explicit nature of the execution doesn't change the >>> fact that to determine if either is executed you need to look at the >>> whole program - not just the class(es) being compiled. >> >> Yes, but I can't imagine any other trigger than meant under (2). >> >> Hope, that I'm bothering too much, >> >> -Ulf >> >> > > There's a default constructor on the class, allowing you to write "new > EUC_TWMapping3()". Much thanks for that example. Thinking about, that there is no value for such an object, I too would prefer to assign that example to group (2). -Ulf From David.Holmes at Sun.COM Tue Mar 9 14:18:20 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 10 Mar 2010 08:18:20 +1000 Subject: Assertions in static blocks ? In-Reply-To: <4B9687D8.906@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> <4B9426B0.1070308@sun.com> <4B94F029.6030006@gmx.de> <4B957EBE.5010905@sun.com> <4B9687D8.906@gmx.de> Message-ID: <4B96C92C.9070407@sun.com> Ulf Zibis said the following on 03/10/10 03:39: > Am 08.03.2010 23:48, schrieb David Holmes - Sun Microsystems: >> Ulf Zibis said the following on 03/08/10 22:40: >>> Am 07.03.2010 23:20, schrieb David Holmes - Sun Microsystems: >>>> I'm with Keith and Neal, this is all "working as designed". How can >>>> javac in general know whether or not a class will be initialized. >>> >>> This is not the question here. The question is if it *can* be >>> initialized, (1) via standard java instruction or (2) via any other >>> special magic like reflective call from Class.forName(). javac surely >>> has knowledge about that. >> >> Both (1) and (2) depend on your whole program not the class being >> compiled. So javac can not know the answer to this at compile time. > > Sorry, maybe I'm missing something. Can you give me an example how > static initializer could be triggered by (1), if there are only static > final primitive type constants in that class? In that case it can't. And as I said previously the special case where a class consists only of these constant fields (initialized by compile-time constant expressions) but still has a static initializer, could be a case where javac issued a warning. If you feel this strongly about it just file an RFE or prepare a fix. Cheers, David Holmes >> >>> If (1) could never be reached, there should be a warning, in >>> particular for less experienced programmers, E.g.: >>> "static initializer will never be triggered by any member or method >>> of this class. Could only be invoked by loading the class explicitly >>> or inherently(not sure)" >> >> No that doesn't make sense. A classes own methods/members are not the >> trigger for classloading and/or initialization. It is the use of those >> methods/members by other classes that triggers the >> loading/initialization of the class containing the method/member. > > Sorry for the bad wording, I meant "... triggered by access to any > member or method of this class. ..." > or "There are no members or methods which could trigger the static > initializer to run, so it may be never reached. ..." > >> >>>> A static initializer is no different to a method or constructor in >>>> that regard: none of them are ever flagged as unreachable because >>>> that can't be determined a-priori by javac. >>> >>> IMHO there is a _big_ difference on normal constructors and methods: >>> 1. They _can_ always be executed by normal java instruction. >>> 2. They will _never_ be executed, if not explicitly called from code. >>> On static initializers it's quite different: >>> 1. They _cannot_ be executed by normal java instruction. >>> 2. They will _mostly_ be _automatically_ executed but not ever, if a >>> member/method from it's class is called >> >> The implicit vs explicit nature of the execution doesn't change the >> fact that to determine if either is executed you need to look at the >> whole program - not just the class(es) being compiled. > > Yes, but I can't imagine any other trigger than meant under (2). > > Hope, that I'm bothering too much, > > -Ulf > > From Ulf.Zibis at gmx.de Tue Mar 9 15:04:57 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 10 Mar 2010 00:04:57 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B96C92C.9070407@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> <4B9426B0.1070308@sun.com> <4B94F029.6030006@gmx.de> <4B957EBE.5010905@sun.com> <4B9687D8.906@gmx.de> <4B96C92C.9070407@sun.com> Message-ID: <4B96D419.5090607@gmx.de> Am 09.03.2010 23:18, schrieb David Holmes - Sun Microsystems: > In that case it can't. And as I said previously the special case where > a class consists only of these constant fields (initialized by > compile-time constant expressions) but still has a static initializer, > could be a case where javac issued a warning. Again much thanks. I guess, we are now synchronized. > > If you feel this strongly about it just file an RFE or prepare a fix. Bug Id: 6932842 Prepare fix: This is atroublesome story. I have posted some fixes on https://bugs.openjdk.java.net since months, without "progress" from Sun side. Regards, Ulf > > Cheers, > David Holmes > >>> >>>> If (1) could never be reached, there should be a warning, in >>>> particular for less experienced programmers, E.g.: >>>> "static initializer will never be triggered by any member or method >>>> of this class. Could only be invoked by loading the class >>>> explicitly or inherently(not sure)" >>> >>> No that doesn't make sense. A classes own methods/members are not >>> the trigger for classloading and/or initialization. It is the use of >>> those methods/members by other classes that triggers the >>> loading/initialization of the class containing the method/member. >> >> Sorry for the bad wording, I meant "... triggered by access to any >> member or method of this class. ..." >> or "There are no members or methods which could trigger the static >> initializer to run, so it may be never reached. ..." >> >>> >>>>> A static initializer is no different to a method or constructor in >>>>> that regard: none of them are ever flagged as unreachable because >>>>> that can't be determined a-priori by javac. >>>> >>>> IMHO there is a _big_ difference on normal constructors and methods: >>>> 1. They _can_ always be executed by normal java instruction. >>>> 2. They will _never_ be executed, if not explicitly called from code. >>>> On static initializers it's quite different: >>>> 1. They _cannot_ be executed by normal java instruction. >>>> 2. They will _mostly_ be _automatically_ executed but not ever, if >>>> a member/method from it's class is called >>> >>> The implicit vs explicit nature of the execution doesn't change the >>> fact that to determine if either is executed you need to look at the >>> whole program - not just the class(es) being compiled. >> >> Yes, but I can't imagine any other trigger than meant under (2). >> >> Hope, that I'm bothering too much, >> >> -Ulf >> >> > > From christopher.hegarty at sun.com Wed Mar 10 06:47:32 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 10 Mar 2010 14:47:32 +0000 Subject: hg: jdk7/tl/jdk: 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Message-ID: <20100310144817.62C2D445BC@hg.openjdk.java.net> Changeset: 47958f76babc Author: chegar Date: 2010-03-10 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47958f76babc 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Reviewed-by: alanb ! test/java/net/MulticastSocket/NoLoopbackPackets.java From martinrb at google.com Wed Mar 10 15:14:43 2010 From: martinrb at google.com (martinrb at google.com) Date: Wed, 10 Mar 2010 23:14:43 +0000 Subject: hg: jdk7/tl/jdk: 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Message-ID: <20100310231507.8C5B944633@hg.openjdk.java.net> Changeset: 467484e025d6 Author: martin Date: 2010-03-10 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/467484e025d6 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Summary: uc >> 16 == 0 is superior to (int) (char) uc == uc Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/sun/nio/cs/Surrogate.java From jonathan.gibbons at sun.com Wed Mar 10 16:24:36 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 11 Mar 2010 00:24:36 +0000 Subject: hg: jdk7/tl/langtools: 6933914: fix missing newlines Message-ID: <20100311002440.1FD1244644@hg.openjdk.java.net> Changeset: 9871ce4fd56f Author: jjg Date: 2010-03-10 16:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9871ce4fd56f 6933914: fix missing newlines Reviewed-by: ohair ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/api/6731573/Erroneous.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/varargs/T6746184.java - test/tools/javap/T6305779.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java From christopher.hegarty at sun.com Thu Mar 11 08:20:14 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 16:20:14 +0000 Subject: hg: jdk7/tl/jdk: 6934054: java/net/Socket/FDClose.java return error in samevm Message-ID: <20100311162054.0273244735@hg.openjdk.java.net> Changeset: 07e1c5a90c6a Author: chegar Date: 2010-03-11 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07e1c5a90c6a 6934054: java/net/Socket/FDClose.java return error in samevm Summary: test is no longer useful Reviewed-by: alanb ! test/ProblemList.txt - test/java/net/Socket/FDClose.java From christopher.hegarty at sun.com Thu Mar 11 09:39:36 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 17:39:36 +0000 Subject: hg: jdk7/tl/jdk: 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Message-ID: <20100311173955.C60B444747@hg.openjdk.java.net> Changeset: c342735a3e58 Author: chegar Date: 2010-03-11 17:37 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c342735a3e58 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieHandlerTest.java From christopher.hegarty at sun.com Thu Mar 11 09:51:09 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 11 Mar 2010 17:51:09 +0000 Subject: hg: jdk7/tl/jdk: 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Message-ID: <20100311175127.DA7B84474C@hg.openjdk.java.net> Changeset: c6f8c58ed51a Author: chegar Date: 2010-03-11 17:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6f8c58ed51a 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Reviewed-by: michaelm, chegar Contributed-by: damjan.jov at gmail.com ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java + test/java/net/Socket/SocksConnectTimeout.java From xueming.shen at sun.com Thu Mar 11 14:13:54 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Thu, 11 Mar 2010 22:13:54 +0000 Subject: hg: jdk7/tl/jdk: 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Message-ID: <20100311221413.1ACC14478B@hg.openjdk.java.net> Changeset: ee385b4e2ffb Author: sherman Date: 2010-03-11 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee385b4e2ffb 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Summary: system property sun.zip.disableMemoryMapping to disable mmap use Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h From jonathan.gibbons at sun.com Fri Mar 12 12:01:35 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 12 Mar 2010 20:01:35 +0000 Subject: hg: jdk7/tl/langtools: 6934224: update langtools/test/Makefile Message-ID: <20100312200137.D4E54448C3@hg.openjdk.java.net> Changeset: f856c0942c06 Author: jjg Date: 2010-03-12 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f856c0942c06 6934224: update langtools/test/Makefile Reviewed-by: ohair ! make/jprt.properties ! test/Makefile From kelly.ohair at sun.com Fri Mar 12 12:15:43 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 12 Mar 2010 20:15:43 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100312201621.2443B448C8@hg.openjdk.java.net> Changeset: bf6eb240e718 Author: ohair Date: 2010-03-12 09:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf6eb240e718 6933294: Fix some test/Makefile issues around Linux ARCH settings, better defaults Reviewed-by: jjg ! test/Makefile ! test/ProblemList.txt Changeset: cda90ceb7176 Author: ohair Date: 2010-03-12 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cda90ceb7176 Merge ! test/ProblemList.txt From jonathan.gibbons at sun.com Fri Mar 12 15:25:00 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 12 Mar 2010 23:25:00 +0000 Subject: hg: jdk7/tl: 6934712: run langtools jtreg tests from top level test/Makefile Message-ID: <20100312232500.DB883448F5@hg.openjdk.java.net> Changeset: bbd817429100 Author: jjg Date: 2010-03-12 15:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/bbd817429100 6934712: run langtools jtreg tests from top level test/Makefile Reviewed-by: ohair ! test/Makefile From kelly.ohair at sun.com Fri Mar 12 17:47:22 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 13 Mar 2010 01:47:22 +0000 Subject: hg: jdk7/tl: 6934759: Add langtools testing to jprt control builds Message-ID: <20100313014722.B3FF544918@hg.openjdk.java.net> Changeset: c60ed0f6d91a Author: ohair Date: 2010-03-12 17:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/c60ed0f6d91a 6934759: Add langtools testing to jprt control builds Reviewed-by: jjg ! make/jprt.properties From christopher.hegarty at sun.com Tue Mar 16 03:06:44 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 16 Mar 2010 10:06:44 +0000 Subject: hg: jdk7/tl/jdk: 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Message-ID: <20100316100704.71B7644D83@hg.openjdk.java.net> Changeset: f88f6f8ddd21 Author: chegar Date: 2010-03-16 10:05 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f88f6f8ddd21 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Reviewed-by: alanb ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java From christopher.hegarty at sun.com Tue Mar 16 07:34:19 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 16 Mar 2010 14:34:19 +0000 Subject: hg: jdk7/tl/jdk: 6935199: java/net regression tests failing with Assertions Message-ID: <20100316143439.1BD6244DC5@hg.openjdk.java.net> Changeset: 895a1211b2e1 Author: chegar Date: 2010-03-16 14:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/895a1211b2e1 6935199: java/net regression tests failing with Assertions Reviewed-by: michaelm ! test/ProblemList.txt ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/URLClassLoader/closetest/CloseTest.java From Ulf.Zibis at gmx.de Tue Mar 16 18:14:36 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 17 Mar 2010 02:14:36 +0100 Subject: request for paired constants in j.l.Character Message-ID: <4BA02CFC.8010907@gmx.de> In java.lang.Character we have: public static final char MIN_VALUE = '\u0000'; public static final char MAX_VALUE = '\uFFFF'; public static final int MIN_CODE_POINT = 0x000000; public static final int MAX_CODE_POINT = 0X10FFFF; public static final int MIN_SUPPLEMENTARY_CODE_POINT = MAX_VALUE + 1; As we have MIN_CODE_POINT, which is duplicate of MIN_VALUE, IMO we additionally could have public static final int MAX_SUPPLEMENTARY_CODE_POINT = MAX_CODE_POINT; It would look better and serve plenty users expectations to find those MIN/MAX constants as pair. Is there anybody who agrees with me ? -Ulf From weijun.wang at sun.com Tue Mar 16 18:55:37 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Wed, 17 Mar 2010 01:55:37 +0000 Subject: hg: jdk7/tl/jdk: 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Message-ID: <20100317015556.BC14844E6E@hg.openjdk.java.net> Changeset: 0500f7306cbe Author: weijun Date: 2010-03-17 09:55 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0500f7306cbe 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Reviewed-by: wetmore ! test/sun/security/tools/jarsigner/oldsig.sh From weijun.wang at sun.com Thu Mar 18 03:27:35 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 18 Mar 2010 10:27:35 +0000 Subject: hg: jdk7/tl/jdk: 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Message-ID: <20100318102854.BFEB644088@hg.openjdk.java.net> Changeset: 2796f839e337 Author: weijun Date: 2010-03-18 18:26 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2796f839e337 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java From yu-ching.peng at sun.com Thu Mar 18 18:08:20 2010 From: yu-ching.peng at sun.com (yu-ching.peng at sun.com) Date: Fri, 19 Mar 2010 01:08:20 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100319010953.BA4894417C@hg.openjdk.java.net> Changeset: c52f292a8f86 Author: valeriep Date: 2010-03-18 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c52f292a8f86 6695485: SignedObject constructor throws ProviderException if it's called using provider "SunPKCS11-Solaris" Summary: Added checking for RSA key lengths in initSign and initVerify Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Signature.java + test/sun/security/pkcs11/Signature/TestRSAKeyLength.java Changeset: df5714cbe76d Author: valeriep Date: 2010-03-18 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df5714cbe76d 6591117: Poor preformance of PKCS#11 security provider compared to Sun default provider Summary: Added internal buffering to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java Changeset: dc42c9d9ca16 Author: valeriep Date: 2010-03-18 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc42c9d9ca16 6837847: PKCS#11 A SecureRandom and a serialization error following installation of 1.5.0_18 Summary: Added a custom readObject method to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java + test/sun/security/pkcs11/SecureRandom/TestDeserialization.java From lana.steuck at sun.com Thu Mar 18 22:17:04 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:17:04 +0000 Subject: hg: jdk7/tl: 3 new changesets Message-ID: <20100319051704.78292441C6@hg.openjdk.java.net> Changeset: 3ddf90b39176 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/3ddf90b39176 Added tag jdk7-b85 for changeset cf26288a114b ! .hgtags Changeset: 433a60a9c0bf Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/433a60a9c0bf Merge Changeset: 98505d97a822 Author: lana Date: 2010-03-18 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/98505d97a822 Merge From lana.steuck at sun.com Thu Mar 18 22:17:11 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:17:11 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b85 for changeset c67a9df7bc0c Message-ID: <20100319051713.B7AF2441C7@hg.openjdk.java.net> Changeset: 6253e28826d1 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6253e28826d1 Added tag jdk7-b85 for changeset c67a9df7bc0c ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:19:23 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:19:23 +0000 Subject: hg: jdk7/tl/hotspot: 2 new changesets Message-ID: <20100319051931.87330441C8@hg.openjdk.java.net> Changeset: 418bc80ce139 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/418bc80ce139 Added tag jdk7-b85 for changeset 6c9796468b91 ! .hgtags Changeset: bf823ef06b4f Author: trims Date: 2010-03-08 15:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bf823ef06b4f Added tag hs17-b10 for changeset 418bc80ce139 ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:23:25 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:23:25 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b85 for changeset 6c0ccabb430d Message-ID: <20100319052325.DADBE441CA@hg.openjdk.java.net> Changeset: 81c0f115bbe5 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/81c0f115bbe5 Added tag jdk7-b85 for changeset 6c0ccabb430d ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:23:32 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:23:32 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b85 for changeset 8424512588ff Message-ID: <20100319052332.21C08441CB@hg.openjdk.java.net> Changeset: 512b0e924a5a Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/512b0e924a5a Added tag jdk7-b85 for changeset 8424512588ff ! .hgtags From lana.steuck at sun.com Thu Mar 18 22:24:32 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:24:32 +0000 Subject: hg: jdk7/tl/jdk: 22 new changesets Message-ID: <20100319053136.DA606441CE@hg.openjdk.java.net> Changeset: 03cd9e62961f Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03cd9e62961f Added tag jdk7-b85 for changeset b396584a3e64 ! .hgtags Changeset: 840601ac5ab7 Author: rkennke Date: 2010-03-03 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/840601ac5ab7 6892485: Deadlock in SunGraphicsEnvironment / FontManager Summary: Synchronize on correct monitor in SunFontManager. Reviewed-by: igor, prr ! src/share/classes/sun/font/SunFontManager.java Changeset: 1d7db2d5c4c5 Author: minqi Date: 2010-03-08 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1d7db2d5c4c5 6918065: Crash in Java2D blit loop (IntArgbToIntArgbPreSrcOverMaskBlit) in 64bit mode Reviewed-by: igor, bae ! src/share/classes/java/awt/AlphaComposite.java + test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java Changeset: 494f5e4f24da Author: lana Date: 2010-03-09 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/494f5e4f24da Merge Changeset: e64331144648 Author: rupashka Date: 2010-02-10 15:15 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e64331144648 6848475: JSlider does not display the correct value of its BoundedRangeModel Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6848475/bug6848475.java Changeset: f81c8041ccf4 Author: peytoia Date: 2010-02-11 15:58 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f81c8041ccf4 6909002: Remove indicim.jar and thaiim.jar from JRE and move to samples if needed Reviewed-by: okutsu ! make/com/sun/Makefile Changeset: e2b58a45a426 Author: peytoia Date: 2010-02-12 14:38 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e2b58a45a426 6921289: (tz) Support tzdata2010b Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e8340332745e Author: malenkov Date: 2010-02-18 17:46 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8340332745e 4498236: RFE: Provide a toString method for PropertyChangeEvent and other classes Reviewed-by: peterz ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyChangeEvent.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test4498236.java Changeset: 5c03237838e1 Author: rupashka Date: 2010-02-27 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c03237838e1 6913758: Specification for SynthViewportUI.paintBorder(...) should mention that this method is never called Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 96205ed1b196 Author: rupashka Date: 2010-02-27 14:47 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/96205ed1b196 6918447: SynthToolBarUI.setBorderToXXXX() methods don't correspond inherited spec. They do nothing. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java Changeset: 621e921a14cd Author: rupashka Date: 2010-02-27 15:09 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/621e921a14cd 6918861: SynthSliderUI.uninstallDefaults() is not called when UI is uninstalled Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6918861/bug6918861.java Changeset: 28741de0bb4a Author: rupashka Date: 2010-02-27 16:03 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/28741de0bb4a 6923305: SynthSliderUI paints the slider track when the slider's "paintTrack" property is set to false Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6923305/bug6923305.java Changeset: 2bf137beb9bd Author: rupashka Date: 2010-02-27 16:14 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2bf137beb9bd 6929298: The SynthSliderUI#calculateTickRect method should be removed Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java Changeset: d6b3a07c8752 Author: rupashka Date: 2010-03-03 17:57 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6b3a07c8752 6924059: SynthScrollBarUI.configureScrollBarColors() should have spec different from the overridden method Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/6924059/bug6924059.java Changeset: 30c520bd148f Author: rupashka Date: 2010-03-03 20:08 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/30c520bd148f 6913768: With default SynthLookAndFeel instance installed new JTable creation leads to throwing NPE Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java + test/javax/swing/JTable/6913768/bug6913768.java Changeset: f13fc955be62 Author: rupashka Date: 2010-03-03 20:53 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f13fc955be62 6917744: JScrollPane Page Up/Down keys do not handle correctly html tables with different cells contents Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/text/DefaultEditorKit.java + test/javax/swing/JEditorPane/6917744/bug6917744.java + test/javax/swing/JEditorPane/6917744/test.html Changeset: 0622086d82ac Author: malenkov Date: 2010-03-04 21:17 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0622086d82ac 6921644: XMLEncoder generates invalid XML Reviewed-by: peterz ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test5023550.java + test/java/beans/XMLEncoder/Test5023557.java + test/java/beans/XMLEncoder/Test6921644.java Changeset: 79a509ac8f35 Author: lana Date: 2010-03-01 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/79a509ac8f35 Merge ! make/com/sun/Makefile - make/java/text/FILES_java.gmk Changeset: 90248595ec35 Author: lana Date: 2010-03-04 13:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90248595ec35 Merge Changeset: 2fe4e72288ce Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2fe4e72288ce Merge Changeset: eae6e9ab2606 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eae6e9ab2606 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: dff4f51b73d4 Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dff4f51b73d4 Merge From lana.steuck at sun.com Thu Mar 18 22:37:45 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Fri, 19 Mar 2010 05:37:45 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100319053756.31267441D1@hg.openjdk.java.net> Changeset: b816baf594e3 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b816baf594e3 Added tag jdk7-b85 for changeset 136bfc679462 ! .hgtags Changeset: ef07347428f2 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ef07347428f2 Merge - test/tools/javac/treepostests/TreePosTest.java Changeset: 6fad35d25b1e Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6fad35d25b1e Merge From christopher.hegarty at sun.com Fri Mar 19 06:27:27 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Fri, 19 Mar 2010 13:27:27 +0000 Subject: hg: jdk7/tl/jdk: 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Message-ID: <20100319132803.016AC44258@hg.openjdk.java.net> Changeset: 3bb93c410f41 Author: chegar Date: 2010-03-19 13:07 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3bb93c410f41 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java + test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh From kelly.ohair at sun.com Fri Mar 19 18:18:24 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 20 Mar 2010 01:18:24 +0000 Subject: hg: jdk7/tl: 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Message-ID: <20100320011825.0F4AE44311@hg.openjdk.java.net> Changeset: 35d272ef7598 Author: ohair Date: 2010-03-19 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/35d272ef7598 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Reviewed-by: jjg ! test/Makefile From christopher.hegarty at sun.com Mon Mar 22 05:00:30 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 22 Mar 2010 12:00:30 +0000 Subject: hg: jdk7/tl/jdk: 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Message-ID: <20100322120310.8BCBE4465E@hg.openjdk.java.net> Changeset: c40572afb29e Author: chegar Date: 2010-03-22 11:55 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c40572afb29e 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java From weijun.wang at sun.com Mon Mar 22 19:42:26 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 23 Mar 2010 02:42:26 +0000 Subject: hg: jdk7/tl/jdk: 6586707: NTLM authentication with proxy fails Message-ID: <20100323024302.3CD6A4472E@hg.openjdk.java.net> Changeset: 31dcf23042f9 Author: weijun Date: 2010-03-23 10:41 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31dcf23042f9 6586707: NTLM authentication with proxy fails Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java From christopher.hegarty at sun.com Tue Mar 23 06:57:59 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Tue, 23 Mar 2010 13:57:59 +0000 Subject: hg: jdk7/tl/jdk: 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets; ... Message-ID: <20100323135911.52071447CD@hg.openjdk.java.net> Changeset: 8a9ebdc27045 Author: chegar Date: 2010-03-23 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8a9ebdc27045 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented" 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 Summary: All three bugs are interdependent Reviewed-by: xuelei ! src/share/classes/javax/net/SocketFactory.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java From jonathan.gibbons at sun.com Tue Mar 23 18:07:03 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 24 Mar 2010 01:07:03 +0000 Subject: hg: jdk7/tl/langtools: 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Message-ID: <20100324010711.722334408A@hg.openjdk.java.net> Changeset: dd30de080cb9 Author: jjg Date: 2010-03-23 18:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dd30de080cb9 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/6937244/T6937244.java + test/tools/javap/6937244/T6937244A.java From daniel.daugherty at sun.com Tue Mar 23 20:20:33 2010 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 24 Mar 2010 03:20:33 +0000 Subject: hg: jdk7/tl/jdk: 6915365: 3/4 assert(false, "Unsupported VMGlobal Type") at management.cpp:1540 Message-ID: <20100324032046.21DBD440B1@hg.openjdk.java.net> Changeset: f8c9a5e3f5db Author: dcubed Date: 2010-03-23 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8c9a5e3f5db 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove exception throw to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/native/sun/management/Flag.c From jonathan.gibbons at sun.com Wed Mar 24 12:19:58 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 24 Mar 2010 19:19:58 +0000 Subject: hg: jdk7/tl/langtools: 6937318: jdk7 b86: javah and javah -help is no output for these commands Message-ID: <20100324192003.81CA4441A5@hg.openjdk.java.net> Changeset: 3058880c0b8d Author: jjg Date: 2010-03-24 12:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3058880c0b8d 6937318: jdk7 b86: javah and javah -help is no output for these commands Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java ! test/tools/javah/T6893943.java From joe.darcy at sun.com Wed Mar 24 17:03:57 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 25 Mar 2010 00:03:57 +0000 Subject: hg: jdk7/tl/langtools: 6937417: javac -Xprint returns IndexOutOfBoundsException Message-ID: <20100325000401.C8A36441EB@hg.openjdk.java.net> Changeset: 65e422bbb984 Author: darcy Date: 2010-03-24 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/65e422bbb984 6937417: javac -Xprint returns IndexOutOfBoundsException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + test/tools/javac/processing/model/util/elements/VacuousEnum.java From weijun.wang at sun.com Wed Mar 24 21:09:04 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 25 Mar 2010 04:09:04 +0000 Subject: hg: jdk7/tl/jdk: 6813340: X509Factory should not depend on is.available()==0 Message-ID: <20100325040917.7E9654422E@hg.openjdk.java.net> Changeset: 26477628f2d5 Author: weijun Date: 2010-03-25 12:07 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/26477628f2d5 6813340: X509Factory should not depend on is.available()==0 Reviewed-by: xuelei ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/KeyTool.java + test/java/security/cert/CertificateFactory/ReturnStream.java + test/java/security/cert/CertificateFactory/SlowStream.java + test/java/security/cert/CertificateFactory/slowstream.sh From christopher.hegarty at sun.com Thu Mar 25 02:40:31 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Thu, 25 Mar 2010 09:40:31 +0000 Subject: hg: jdk7/tl/jdk: 6937703: java/net regression test issues with samevm Message-ID: <20100325094056.833F744286@hg.openjdk.java.net> Changeset: 6109b166bf68 Author: chegar Date: 2010-03-25 09:38 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6109b166bf68 6937703: java/net regression test issues with samevm Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ProxySelector/B6737819.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java ! test/java/net/URL/TestIPv6Addresses.java ! test/java/net/URLClassLoader/HttpTest.java ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/contentHandler/UserContentHandler.java From kelly.ohair at sun.com Fri Mar 26 22:44:16 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Sat, 27 Mar 2010 05:44:16 +0000 Subject: hg: jdk7/tl/langtools: 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Message-ID: <20100327054418.366324454D@hg.openjdk.java.net> Changeset: de6375751eb7 Author: ohair Date: 2010-03-26 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/de6375751eb7 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Reviewed-by: jjg ! make/Makefile From xuelei.fan at sun.com Sun Mar 28 22:51:14 2010 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Mon, 29 Mar 2010 05:51:14 +0000 Subject: hg: jdk7/tl/jdk: 6693917: regression tests need to update for supporting ECC on solaris 11 Message-ID: <20100329055200.65A9D44814@hg.openjdk.java.net> Changeset: 31517a0345d1 Author: xuelei Date: 2010-03-29 13:27 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31517a0345d1 6693917: regression tests need to update for supporting ECC on solaris 11 Reviewed-by: weijun ! test/sun/security/ssl/etc/keystore ! test/sun/security/ssl/etc/truststore ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java From xueming.shen at sun.com Tue Mar 30 19:15:11 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Wed, 31 Mar 2010 02:15:11 +0000 Subject: hg: jdk7/tl/jdk: 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7; ... Message-ID: <20100331021524.C3C5044ABB@hg.openjdk.java.net> Changeset: 3771ac2a8b3b Author: sherman Date: 2010-03-30 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3771ac2a8b3b 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7 6911753: NSN wants to add Big5 HKSCS-2004 support Summary: support HKSCS2008 in Big5_HKSCS and MS950_HKSCS Reviewed-by: okutsu ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile + make/tools/CharsetMapping/Big5.c2b + make/tools/CharsetMapping/Big5.map + make/tools/CharsetMapping/Big5.nr + make/tools/CharsetMapping/HKSCS2001.c2b + make/tools/CharsetMapping/HKSCS2001.map + make/tools/CharsetMapping/HKSCS2008.c2b + make/tools/CharsetMapping/HKSCS2008.map + make/tools/CharsetMapping/HKSCS_XP.c2b + make/tools/CharsetMapping/HKSCS_XP.map ! make/tools/CharsetMapping/dbcs - make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/DBCS.java + make/tools/src/build/tools/charsetmapping/EUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java + make/tools/src/build/tools/charsetmapping/HKSCS.java + make/tools/src/build/tools/charsetmapping/JIS0213.java ! make/tools/src/build/tools/charsetmapping/Main.java + make/tools/src/build/tools/charsetmapping/SBCS.java + make/tools/src/build/tools/charsetmapping/Utils.java ! src/share/classes/sun/awt/HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5.java ! src/share/classes/sun/io/ByteToCharBig5_HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5.java ! src/share/classes/sun/io/CharToByteBig5_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/nio/cs/ext/Big5.java ! src/share/classes/sun/nio/cs/ext/Big5_HKSCS.java + src/share/classes/sun/nio/cs/ext/Big5_HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/Big5_Solaris.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS.java + src/share/classes/sun/nio/cs/ext/MS950_HKSCS_XP.java ! src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.properties ! src/solaris/native/java/lang/java_props_md.c ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/native/java/lang/java_props_md.c ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/Charset/RegisteredCharsets.java From john.r.rose at oracle.com Wed Mar 31 16:02:48 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Mar 2010 16:02:48 -0700 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation Message-ID: http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.00 This review request is specifically for JVM changes. They will be coordinated with the following JDK and javac changes: http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ Details: 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric Mark the special signature-polymorpic methods and classes with @PolymorphicSignature. Reviewed-by: ? The JSR 292 EG has decided to split MethodHandle.invoke into two methods, invokeExact and invokeGeneric. Adjust javac so that it uses a marker annotation (@PolymorphicSignature) to recognize which methods are signature-polymorphic. Remove hard-coded recognition of MethodHandle.invoke and InvokeDynamic. From neal at gafter.com Wed Mar 31 16:12:41 2010 From: neal at gafter.com (Neal Gafter) Date: Wed, 31 Mar 2010 16:12:41 -0700 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: Message-ID: I continue to object to language extensions of this kind (i.e. nontrivial additions to the Java programming language that do not benefit Java programmers). In any case, you did not provide a link for jdk changes. Cheers, Neal On Wed, Mar 31, 2010 at 4:02 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.00 > > This review request is specifically for JVM changes. They will be > coordinated with the following JDK and javac changes: > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > > Details: > > 6939134: JSR 292 adjustments to method handle invocation > Summary: split MethodHandle.invoke into invokeExact and invokeGeneric > Mark the special signature-polymorpic methods and classes with > @PolymorphicSignature. > Reviewed-by: ? > > The JSR 292 EG has decided to split MethodHandle.invoke into two > methods, invokeExact and invokeGeneric. Adjust javac so that it uses > a marker annotation (@PolymorphicSignature) to recognize which methods > are signature-polymorphic. Remove hard-coded recognition of > MethodHandle.invoke and InvokeDynamic. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100331/7e3aa3b1/attachment.html From forax at univ-mlv.fr Wed Mar 31 16:24:10 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 01 Apr 2010 01:24:10 +0200 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: Message-ID: <4BB3D99A.1010400@univ-mlv.fr> Le 01/04/2010 01:12, Neal Gafter a ?crit : > I continue to object to language extensions of this kind (i.e. > nontrivial additions to the Java programming language that do not > benefit Java programmers). These extensions benefit to Java programmers. You can, by example, implement the visitor pattern on top of this without the well known limitations of the interface based approach. > > In any case, you did not provide a link for jdk changes. > > Cheers, > Neal R?mi > > On Wed, Mar 31, 2010 at 4:02 PM, John Rose > wrote: > > http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.00 > > > This review request is specifically for JVM changes. They will be > coordinated with the following JDK and javac changes: > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > > > Details: > > 6939134: JSR 292 adjustments to method handle invocation > Summary: split MethodHandle.invoke into invokeExact and invokeGeneric > Mark the special signature-polymorpic methods and classes with > @PolymorphicSignature. > Reviewed-by: ? > > The JSR 292 EG has decided to split MethodHandle.invoke into two > methods, invokeExact and invokeGeneric. Adjust javac so that it uses > a marker annotation (@PolymorphicSignature) to recognize which methods > are signature-polymorphic. Remove hard-coded recognition of > MethodHandle.invoke and InvokeDynamic. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100401/80dbaad9/attachment.html From forax at univ-mlv.fr Wed Mar 31 16:33:30 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 01 Apr 2010 01:33:30 +0200 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: Message-ID: <4BB3DBCA.4090701@univ-mlv.fr> Le 01/04/2010 01:02, John Rose a ?crit : > http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.00 > > This review request is specifically for JVM changes. They will be coordinated with the following JDK and javac changes: > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > > Details: > > 6939134: JSR 292 adjustments to method handle invocation > Summary: split MethodHandle.invoke into invokeExact and invokeGeneric > Mark the special signature-polymorpic methods and classes with @PolymorphicSignature. > Reviewed-by: ? > > The JSR 292 EG has decided to split MethodHandle.invoke into two > methods, invokeExact and invokeGeneric. Adjust javac so that it uses > a marker annotation (@PolymorphicSignature) to recognize which methods > are signature-polymorphic. Remove hard-coded recognition of > MethodHandle.invoke and InvokeDynamic. > > John, I don't like the annotation @PolymorphicSignature. it opens user defined holes in the type system. R?mi From john.r.rose at oracle.com Wed Mar 31 17:33:13 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Mar 2010 17:33:13 -0700 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: Message-ID: On Mar 31, 2010, at 4:12 PM, Neal Gafter wrote: > I continue to object to language extensions of this kind (i.e. nontrivial additions to the Java programming language that do not benefit Java programmers). This particular change supports signature polymorphism for MethodHandle.invokeExact, MethodHandle.invokeGeneric, and any static method in InvokeDynamic. That's not a change except in the naming of the MH methods, and invokeGeneric is partially at your request. To speak to your continued objection: This language extension (signature polymorphism of specific methods) is necessary to any programmer who (like me) implements dynamic languages using JSR 292, and uses the JVM's systems programming language. Since that language is Java, that makes me (in that role) a Java programmer who gets benefit from those language features. > In any case, you did not provide a link for jdk changes. Oops, a typo. Here it is: http://cr.openjdk.java.net/~jrose/6939134/jdk-webrev.00/ -- John From john.r.rose at oracle.com Wed Mar 31 17:34:03 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Mar 2010 17:34:03 -0700 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <4BB3DBCA.4090701@univ-mlv.fr> References: <4BB3DBCA.4090701@univ-mlv.fr> Message-ID: On Mar 31, 2010, at 4:33 PM, R?mi Forax wrote: > I don't like the annotation @PolymorphicSignature. > it opens user defined holes in the type system. It's not public, so the only people who can open such holes are implementors of java.dyn.*. Is that really a problem? -- John From neal at gafter.com Wed Mar 31 18:02:32 2010 From: neal at gafter.com (Neal Gafter) Date: Wed, 31 Mar 2010 18:02:32 -0700 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: Message-ID: On Wed, Mar 31, 2010 at 5:33 PM, John Rose wrote: > To speak to your continued objection: This language extension (signature > polymorphism of specific methods) is necessary to any programmer who (like > me) implements dynamic languages using JSR 292, and uses the JVM's systems > programming language. Since that language is Java, that makes me (in that > role) a Java programmer who gets benefit from those language features. > Those dynamic languages, which support features not available in Java, should be self-bootstrapped or built using the JVM's own instruction set. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100331/b8f72916/attachment.html From john.r.rose at oracle.com Wed Mar 31 18:43:48 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Mar 2010 18:43:48 -0700 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: Message-ID: On Mar 31, 2010, at 6:02 PM, Neal Gafter wrote: > On Wed, Mar 31, 2010 at 5:33 PM, John Rose wrote: >> To speak to your continued objection: This language extension (signature polymorphism of specific methods) is necessary to any programmer who (like me) implements dynamic languages using JSR 292, and uses the JVM's systems programming language. Since that language is Java, that makes me (in that role) a Java programmer who gets benefit from those language features. > Those dynamic languages, which support features not available in Java, should be self-bootstrapped or built using the JVM's own instruction set. That is the high road for implementing a language, but it is not the usual road, and it would not be customer-friendly to impose it on those who build dynamic languages on the JVM. -- John From Weijun.Wang at Sun.COM Wed Mar 31 18:57:40 2010 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Thu, 01 Apr 2010 09:57:40 +0800 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: Message-ID: <3EF1A95D-6327-45AE-A810-9D4F8C0722CE@sun.com> Can this function be made available through embedded JVM instructions inside a Java source? say -- void go() { jvm { invokedynamic a b c } } Thanks Max On Apr 1, 2010, at 9:43 AM, John Rose wrote: > On Mar 31, 2010, at 6:02 PM, Neal Gafter wrote: > >> On Wed, Mar 31, 2010 at 5:33 PM, John Rose wrote: >>> To speak to your continued objection: This language extension (signature polymorphism of specific methods) is necessary to any programmer who (like me) implements dynamic languages using JSR 292, and uses the JVM's systems programming language. Since that language is Java, that makes me (in that role) a Java programmer who gets benefit from those language features. >> Those dynamic languages, which support features not available in Java, should be self-bootstrapped or built using the JVM's own instruction set. > > That is the high road for implementing a language, but it is not the usual road, and it would not be customer-friendly to impose it on those who build dynamic languages on the JVM. > > -- John From john.r.rose at oracle.com Wed Mar 31 19:21:28 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Mar 2010 19:21:28 -0700 Subject: Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <3EF1A95D-6327-45AE-A810-9D4F8C0722CE@sun.com> References: <3EF1A95D-6327-45AE-A810-9D4F8C0722CE@sun.com> Message-ID: On Mar 31, 2010, at 6:57 PM, Weijun Wang wrote: > Can this function be made available through embedded JVM instructions inside a Java source? say -- > void go() { > jvm { > invokedynamic a b c > } > } If we had an asm feature, yes, it could be used to emit invokedynamic instructions and calls to method handles. The details are not nearly as simple as your sketch suggests. A real asm feature would have to manage the import and export of Java values from the part of the stack affected by the assembly code. I think it would also have to translate between Java-level types and JVM-level type signatures. But even a well-designed asm feature would be much harder to use than a special language hook. -- John