From eamonn.mcmanus at sun.com Tue Apr 1 05:46:43 2008 From: eamonn.mcmanus at sun.com (eamonn.mcmanus at sun.com) Date: Tue, 01 Apr 2008 12:46:43 +0000 Subject: hg: jdk7/tl/jdk: 6610917: Define a generic NotificationFilter Message-ID: <20080401124655.CCAC0273F4@hg.openjdk.java.net> Changeset: 2965459a8ee7 Author: emcmanus Date: 2008-04-01 14:45 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2965459a8ee7 6610917: Define a generic NotificationFilter Summary: Adds javax.management.QueryNotificationFilter Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java + src/share/classes/com/sun/jmx/mbeanserver/NotificationMBeanSupport.java ! src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/javax/management/ObjectName.java + src/share/classes/javax/management/QueryNotificationFilter.java + test/javax/management/query/QueryNotifFilterTest.java From maurizio.cimadamore at sun.com Wed Apr 2 03:24:10 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:24:10 +0000 Subject: hg: jdk7/tl/langtools: 6569789: Compiler test lang/TYPE/type153/type15304/type15304.html fails since jdk7 b05 Message-ID: <20080402102412.78BED27447@hg.openjdk.java.net> Changeset: 6e4cefcce80a Author: mcimadamore Date: 2008-04-02 11:20 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6e4cefcce80a 6569789: Compiler test lang/TYPE/type153/type15304/type15304.html fails since jdk7 b05 Summary: improved glb on type-inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6569789/T6569789.java From maurizio.cimadamore at sun.com Wed Apr 2 03:39:05 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:39:05 +0000 Subject: hg: jdk7/tl/langtools: 6509042: javac rejects class literals in enum constructors Message-ID: <20080402103907.1C6302744C@hg.openjdk.java.net> Changeset: aeaa0f482b28 Author: mcimadamore Date: 2008-04-02 11:38 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aeaa0f482b28 6509042: javac rejects class literals in enum constructors Summary: javac now distinguish between enum class literals and static fields Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/enum/T6509042.java From maurizio.cimadamore at sun.com Wed Apr 2 03:44:57 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:44:57 +0000 Subject: hg: jdk7/tl/langtools: 6531090: Cannot access methods/fields of a captured type belonging to an intersection type Message-ID: <20080402104459.333CB27451@hg.openjdk.java.net> Changeset: adaa3fc51b60 Author: mcimadamore Date: 2008-04-02 11:44 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/adaa3fc51b60 6531090: Cannot access methods/fields of a captured type belonging to an intersection type Summary: fixed lookup of field/methods on intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6531090/T6531090a.java + test/tools/javac/generics/6531090/T6531090b.java From kumar.srinivasan at sun.com Thu Apr 3 18:10:20 2008 From: kumar.srinivasan at sun.com (kumar.srinivasan at sun.com) Date: Fri, 04 Apr 2008 01:10:20 +0000 Subject: hg: jdk7/tl/langtools: 6570242: Regression test failures with Javac on win32. Message-ID: <20080404011022.14FE02754E@hg.openjdk.java.net> Changeset: ddd77d1c1b49 Author: ksrini Date: 2008-04-03 18:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ddd77d1c1b49 6570242: Regression test failures with Javac on win32. Summary: takes this test out of service until the reall bug is fixed Reviewed-by: jjg ! test/tools/javac/api/6431257/T6431257.java From lahoda at gmail.com Fri Apr 4 00:55:18 2008 From: lahoda at gmail.com (Jan Lahoda) Date: Fri, 4 Apr 2008 09:55:18 +0200 Subject: 6679509: AssertionError in com.sun.tools.javac.jvm.Gen$1ComplexityScanner Message-ID: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679509 Summary: An AssertionError is thrown while analyzing valid program. The exception occurs when a foreach loop like: for (java.util.List t : l) { } is used in a finally block, and target is 1.5. The problem's root cause is, IMO, that Gen is processing a tree with generics (the generics should be stripped from the trees in TransTypes, if I understand everything correctly). In this case, the code above gets correctly TransType-d to: for (java.util.List t : l) { } Then, during Lower, the foreach loop is expanded into an ordinary Iterator-based loop: for (java.util.Iterator i$ = l.iterator(); i$.hasNext(); ) { List t = (List)i$.next(); { } } which contains the tree with generics. This is side-effect of using TreeMaker.VarDef(VarSymbol v, JCExpression init), which uses v.type (which contains generics) to construct the tree for the variable's type. I have prepared a patch that constructs the tree for the variable using erasure(v.type). The patch is attached. Any opinions on the patch? Thanks, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080404/39d6e8cc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 6679509.diff Type: text/x-patch Size: 2771 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080404/39d6e8cc/6679509.diff From Maurizio.Cimadamore at Sun.COM Fri Apr 4 02:01:59 2008 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Fri, 04 Apr 2008 10:01:59 +0100 Subject: 6679509: AssertionError in com.sun.tools.javac.jvm.Gen$1ComplexityScanner In-Reply-To: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> References: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> Message-ID: <47F5EE87.4070304@sun.com> I'll have a look at it soon, it seems quite promising Maurizio Jan Lahoda wrote: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679509 > > Summary: An AssertionError is thrown while analyzing valid program. > The exception occurs when a foreach loop like: > for (java.util.List t : l) { > } > is used in a finally block, and target is 1.5. > > The problem's root cause is, IMO, that Gen is processing a tree with > generics (the generics should be stripped from the trees in > TransTypes, if I understand everything correctly). > > In this case, the code above gets correctly TransType-d to: > for (java.util.List t : l) { > } > > Then, during Lower, the foreach loop is expanded into an ordinary > Iterator-based loop: > for (java.util.Iterator i$ = l.iterator(); i$.hasNext(); ) { > List t = (List)i$.next(); > { > } > } > > which contains the tree with generics. > > This is side-effect of using TreeMaker.VarDef(VarSymbol v, > JCExpression init), which uses v.type (which contains generics) to > construct the tree for the variable's type. > > I have prepared a patch that constructs the tree for the variable > using erasure(v.type). The patch is attached. > > Any opinions on the patch? > > Thanks, > Jan > From forax at univ-mlv.fr Fri Apr 4 06:41:31 2008 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 04 Apr 2008 15:41:31 +0200 Subject: 6679509: AssertionError in com.sun.tools.javac.jvm.Gen$1ComplexityScanner In-Reply-To: <47F5EE87.4070304@sun.com> References: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> <47F5EE87.4070304@sun.com> Message-ID: <47F6300B.10009@univ-mlv.fr> Maurizio Cimadamore a ?crit : > I'll have a look at it soon, it seems quite promising > > Maurizio by the way bug 6500701 http://bugs.sun.com/view_bug.do?bug_id=6500701 can be fixed in the same time by removing the line: if (iteratorTarget != syms.objectType) vardefinit = make.TypeCast(iteratorTarget, vardefinit); the one just before the patch. R?mi > > Jan Lahoda wrote: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679509 >> >> Summary: An AssertionError is thrown while analyzing valid program. >> The exception occurs when a foreach loop like: >> for (java.util.List t : l) { >> } >> is used in a finally block, and target is 1.5. >> >> The problem's root cause is, IMO, that Gen is processing a tree with >> generics (the generics should be stripped from the trees in >> TransTypes, if I understand everything correctly). >> >> In this case, the code above gets correctly TransType-d to: >> for (java.util.List t : l) { >> } >> >> Then, during Lower, the foreach loop is expanded into an ordinary >> Iterator-based loop: >> for (java.util.Iterator i$ = l.iterator(); i$.hasNext(); ) { >> List t = (List)i$.next(); >> { >> } >> } >> >> which contains the tree with generics. >> >> This is side-effect of using TreeMaker.VarDef(VarSymbol v, >> JCExpression init), which uses v.type (which contains generics) to >> construct the tree for the variable's type. >> >> I have prepared a patch that constructs the tree for the variable >> using erasure(v.type). The patch is attached. >> >> Any opinions on the patch? >> >> Thanks, >> Jan >> From Jonathan.Gibbons at Sun.COM Fri Apr 4 09:44:37 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 04 Apr 2008 09:44:37 -0700 Subject: 6679509: AssertionError in com.sun.tools.javac.jvm.Gen$1ComplexityScanner In-Reply-To: <47F6300B.10009@univ-mlv.fr> References: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> <47F5EE87.4070304@sun.com> <47F6300B.10009@univ-mlv.fr> Message-ID: <7055B165-A5B6-4914-86B3-FD31E7516710@sun.com> On Apr 4, 2008, at 6:41 AM, R?mi Forax wrote: >> > by the way bug 6500701 > http://bugs.sun.com/view_bug.do?bug_id=6500701 > > can be fixed in the same time by removing the line: > > if (iteratorTarget != syms.objectType) > vardefinit = make.TypeCast(iteratorTarget, vardefinit); > > the one just before the patch. > > R?mi R?mi, Thanks for the tip; would you like us to treat it as a formal submission for a bug fix? Do you have any other suggestions for simple fixes like that? -- Jon From ted at tedneward.com Mon Apr 7 07:17:10 2008 From: ted at tedneward.com (Ted Neward) Date: Mon, 7 Apr 2008 07:17:10 -0700 Subject: Problems about compiler build In-Reply-To: <47E174B1.9000001@sun.com> References: <78e21a200803162306h4d6056b9o33e31192a9b10b1d@mail.gmail.com> <47E174B1.9000001@sun.com> Message-ID: <04d001c898ba$14115b80$3c341280$@com> I have been able to build jdk7/langtools on Windows without any of the problems mentioned below, so it's not just Sun-internal builds on Windows that are succeeding. I'd suggest blowing away the source tree and re-fetching, if you can't correct this otherwise. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev- > bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons > Sent: Wednesday, March 19, 2008 1:17 PM > To: Wei CAO > Cc: compiler-dev at openjdk.java.net > Subject: Re: Problems about compiler build > > Given that you are working on Windows, I suggest you check for any > files > that only differ in whether they use upper case or lower case letters. > I do not believe there are any problems being encountered by our > internal builds on Windows. > > -- Jon > > > > Wei CAO wrote: > > Dear all, > > > > Two months ago I successfully built and tested javac > > source codes within OpenJDK source bundles following > > Alexander's wonderful tutorial using Eclipse on Lunix > > Fedora core7. > > > > Now I wanted to rebuild it on my own laptop with Windows > > vista. In Eclipse I created a new java project from existing > > source which was the successfully built OpenJDK directory. > > When I built the project, I got the following error: > > > > The project was not built due to "A resource exists with a different > > case: '/JDK1.7-from-old/langtools/test/tools/javac/T6435291/com'.". > > Fix the problem, then try refreshing this project and building it > > since it may be inconsistent. > > > > Could anyone tell me how this error is caused and how I can fix it? > > > > Thanks a lot! > > > > Wendy > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.21.7/1335 - Release Date: > 3/19/2008 9:54 AM > No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.8/1362 - Release Date: 4/6/2008 11:12 AM From forax at univ-mlv.fr Mon Apr 7 13:28:26 2008 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 07 Apr 2008 22:28:26 +0200 Subject: 6679509: AssertionError in com.sun.tools.javac.jvm.Gen$1ComplexityScanner In-Reply-To: <7055B165-A5B6-4914-86B3-FD31E7516710@sun.com> References: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> <47F5EE87.4070304@sun.com> <47F6300B.10009@univ-mlv.fr> <7055B165-A5B6-4914-86B3-FD31E7516710@sun.com> Message-ID: <47FA83EA.7030704@univ-mlv.fr> Jonathan Gibbons a ?crit : > > On Apr 4, 2008, at 6:41 AM, R?mi Forax wrote: > >>> >> by the way bug 6500701 >> http://bugs.sun.com/view_bug.do?bug_id=6500701 >> >> can be fixed in the same time by removing the line: >> >> if (iteratorTarget != syms.objectType) >> vardefinit = make.TypeCast(iteratorTarget, vardefinit); >> >> the one just before the patch. >> >> R?mi > > R?mi, > > Thanks for the tip; would you like us to treat it as a formal > submission for a bug fix? yes > Do you have any other suggestions for simple fixes like that? > no, i've just seen that bug one year ago... > -- Jon R?mi From bradford.wetmore at sun.com Mon Apr 7 14:38:37 2008 From: bradford.wetmore at sun.com (bradford.wetmore at sun.com) Date: Mon, 07 Apr 2008 21:38:37 +0000 Subject: hg: jdk7/tl/jdk: 14 new changesets Message-ID: <20080407214126.D82112765A@hg.openjdk.java.net> Changeset: a8d6215fa863 Author: weijun Date: 2008-03-20 11:57 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8d6215fa863 6670362: HTTP/SPNEGO should work across realms Reviewed-by: valeriep ! src/share/classes/sun/net/www/protocol/http/NegotiatorImpl.java Changeset: 74bc85c0f2a9 Author: valeriep Date: 2008-03-20 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74bc85c0f2a9 4898461: Support for ECB and CBC/PKCS5Padding Summary: Add support for ECB mode and PKCS5Padding Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + test/sun/security/pkcs11/Cipher/TestSymmCiphers.java Changeset: 66c2b0cfc896 Author: valeriep Date: 2008-03-20 17:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/66c2b0cfc896 6572331: regression: cipher.wrap operation fails with CKR_ATTRIBUTE_VALUE_INVALID Summary: Check supported key size range and use encryption if needed Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11KeyGenerator.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java + test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java Changeset: 84aced25a346 Author: valeriep Date: 2008-03-20 18:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/84aced25a346 6599979: KeyStore.setEntry/setKeyEntry() do not override existing entry for secret key objects Summary: Override existing secret key entry when setEntry/setKeyEntry() is called Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java + test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java + test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Changeset: 05afbed1dc4f Author: valeriep Date: 2008-03-21 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05afbed1dc4f Merge Changeset: b22cbc65a360 Author: wetmore Date: 2008-03-28 12:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b22cbc65a360 Merge Changeset: 8805ae9d160c Author: valeriep Date: 2008-03-31 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8805ae9d160c 6681652: Two new regression test failures in pkcs11 code Summary: Fixed the test to not assume SunJCE provider being the provider for DES Reviewed-by: wetmore ! test/javax/crypto/Cipher/TestGetInstance.java Changeset: e1bf7407c933 Author: wetmore Date: 2008-03-31 13:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1bf7407c933 6469580: 1.5.0_08 JVM crashes in SignatureHandlerLibrary::add on Fujitsu Primepower platform Reviewed-by: andreas, valeriep, wetmore Contributed-by: chris.phillips at sun.com ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c Changeset: 17e93b7fb97d Author: valeriep Date: 2008-03-31 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/17e93b7fb97d 6682411: JCK test failed w/ ArrayIndexOutOfBoundException (-1) when decrypting with no data Summary: Fixed PKCS5Padding class with additional check and throw BadPaddingException if the check failed Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: c063b7fb55f7 Author: valeriep Date: 2008-03-31 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c063b7fb55f7 6682417: JCK test failed w/ ProviderException when decrypted data is not multiple of blocks Summary: Check for CKR_ENCRYPTED_DATA_LEN_RANGE and throw IllegalBlockSizeException Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 99b3301fc27c Author: valeriep Date: 2008-03-31 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99b3301fc27c Merge Changeset: df5d7e6ac15e Author: xuelei Date: 2008-04-02 22:44 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df5d7e6ac15e 6668231: Presence of a critical subjectAltName causes JSSE's SunX509 to fail trusted checks Summary: make the critical extension known to end entity checker. Reviewed-by: wetmore, mullan ! src/share/classes/sun/security/validator/EndEntityChecker.java + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/crisubn.jks + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/trusted.jks Changeset: b70fc43afb8c Author: wetmore Date: 2008-04-06 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b70fc43afb8c 6683078: Update JCE framework and provider builds to work on read-only filesystems 6644659: Error in default target of make/javax/crypto in OpenJDK build Reviewed-by: valeriep, ohair ! make/com/sun/crypto/provider/Makefile ! make/common/shared/Defs.gmk ! make/javax/crypto/Defs-jce.gmk ! make/javax/crypto/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: f4205a7bdfd4 Author: wetmore Date: 2008-04-07 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4205a7bdfd4 Merge From maurizio.cimadamore at sun.com Wed Apr 9 06:06:27 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 09 Apr 2008 13:06:27 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20080409130634.DC303276F6@hg.openjdk.java.net> Changeset: 961ae2608114 Author: mcimadamore Date: 2008-04-09 13:19 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/961ae2608114 6531075: Missing synthetic casts when accessing fields/methods of intersection types including type variables Summary: bug when javac generates code involving intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/6531075/T6531075.java Changeset: d032d5090fd5 Author: mcimadamore Date: 2008-04-09 13:41 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d032d5090fd5 5009937: hiding versus generics versus binary compatibility Summary: missing implementation of JLS 8.4.8.3 (different arguments with same erasure not always triggering a compiler error) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/5009937/T5009937.java + test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java Changeset: 57ba4f70f0d8 Author: mcimadamore Date: 2008-04-09 13:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/57ba4f70f0d8 6365166: javac (generic) unable to resolve methods Summary: Unignore regression test as this bug has been fixed by CR 6278587 Reviewed-by: jjg + test/tools/javac/generics/inference/6356673/T6365166.java Changeset: 25338c55e458 Author: mcimadamore Date: 2008-04-09 14:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/25338c55e458 6481655: Parser confused by combination of parens and explicit type args Summary: Bug in the parser caused by the fact that explicit type arguments are disabled when parsing parenthesized expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/Parser.java + test/tools/javac/generics/T6481655.java From maurizio.cimadamore at sun.com Wed Apr 9 07:33:19 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 09 Apr 2008 14:33:19 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20080409143326.2AB00276FB@hg.openjdk.java.net> Changeset: 447c300a24e7 Author: mcimadamore Date: 2008-04-09 14:45 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/447c300a24e7 6450290: Capture of nested wildcards causes type error Summary: A missing capture conversion makes javac to think that some expressions are well-formed even when they aren't Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/wildcards/T6450290.java Changeset: e7bf2e39b8fe Author: mcimadamore Date: 2008-04-09 14:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e7bf2e39b8fe 6657499: javac 1.6.0 fails to compile class with inner class Summary: Lookup of member inner classes silently fails leading to an unwanted erasure to take place Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/T6657499.java Changeset: 6522ea413d23 Author: mcimadamore Date: 2008-04-09 15:04 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6522ea413d23 6683438: Bad regression test for CR 6611449 Summary: The regression test for CR 6611449 contains some inconstistencies Reviewed-by: jjg ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6611449/T6611449.out Changeset: a1d1f335633f Author: mcimadamore Date: 2008-04-09 15:30 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a1d1f335633f 6559182: Cast from a raw type with non-generic supertype to a raw type fails unexpectedly Summary: Javac doesn't conform to JLS 4.8 - all the supertypes of a raw type must be erased Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/Casting5.java From kumar.srinivasan at sun.com Thu Apr 10 09:06:19 2008 From: kumar.srinivasan at sun.com (kumar.srinivasan at sun.com) Date: Thu, 10 Apr 2008 16:06:19 +0000 Subject: hg: jdk7/tl/jdk: 6684582: Launcher needs improved error reporting Message-ID: <20080410160631.189EB2776C@hg.openjdk.java.net> Changeset: c2019d1360ef Author: ksrini Date: 2008-04-10 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2019d1360ef 6684582: Launcher needs improved error reporting Summary: indicate the missing main class in the error message Reviewed-by: darcy, kbr ! src/share/bin/emessages.h ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/Arrrghs.sh From xueming.shen at sun.com Thu Apr 10 14:52:14 2008 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Thu, 10 Apr 2008 21:52:14 +0000 Subject: hg: jdk7/tl/jdk: 6529796: Support JIS X 0213:2004 in existing JDK versions, especially for Windows Vista Message-ID: <20080410215236.1998C27805@hg.openjdk.java.net> Changeset: cb934dd5e073 Author: sherman Date: 2008-04-10 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb934dd5e073 6529796: Support JIS X 0213:2004 in existing JDK versions, especially for Windows Vista Summary: SJIS0213 support Reviewed-by: naoto ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/Makefile + make/tools/CharsetMapping/sjis0213.map ! make/tools/Makefile + make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/GenerateMapping.java + src/share/classes/sun/nio/cs/CharsetMapping.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java + src/share/classes/sun/nio/cs/ext/MS932_0213.java + src/share/classes/sun/nio/cs/ext/SJIS_0213.java From mandy.chung at sun.com Thu Apr 10 16:16:30 2008 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 10 Apr 2008 23:16:30 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20080410231656.846562780A@hg.openjdk.java.net> Changeset: fd563c5dd750 Author: mchung Date: 2008-04-10 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd563c5dd750 6610094: Add generic support for platform MXBeans of any type (also fixed 6681031) Summary: Add new methods in ManagementFactory class to obtain platform MXBeans Reviewed-by: alanb, dfuchs, emcmanus ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/management/ClassLoadingMXBean.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/GarbageCollectorMXBean.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/MemoryMXBean.java ! src/share/classes/java/lang/management/MemoryManagerMXBean.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/OperatingSystemMXBean.java + src/share/classes/java/lang/management/PlatformComponent.java + src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/sun/management/ClassLoadingImpl.java ! src/share/classes/sun/management/CompilationImpl.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotInternal.java ! src/share/classes/sun/management/LockDataConverter.java ! src/share/classes/sun/management/ManagementFactory.java + src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MemoryImpl.java ! src/share/classes/sun/management/MemoryManagerImpl.java ! src/share/classes/sun/management/MemoryNotifInfoCompositeData.java ! src/share/classes/sun/management/MemoryPoolImpl.java ! src/share/classes/sun/management/MemoryUsageCompositeData.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/OperatingSystemImpl.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/StackTraceElementCompositeData.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/Util.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/classes/sun/management/VMOptionCompositeData.java ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java + test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java + test/java/lang/management/OperatingSystemMXBean/PlatformMXBeanTest.java Changeset: bcf689d26c1c Author: mchung Date: 2008-04-10 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bcf689d26c1c Merge From Jonathan.Gibbons at Sun.COM Fri Apr 11 10:21:20 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 11 Apr 2008 10:21:20 -0700 Subject: CFV: Project sponsorship: Closures For Java Message-ID: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> Question: Should the Compiler Group sponsor the proposed new Closures For Java Project? [1] Please cast your vote by replying, publicly, to this message with either Vote: yes or Vote: no as the first line of the message body. You may, at your option, indicate the reason for your decision on subsequent lines. Votes must be cast in the open; votes sent as private replies will not be counted. The sponsorship decision will be made by a simple majority vote of the Group's Members. Votes are due by midnight UTC next Friday, 18 April. If an absolute majority of the Group's Members votes one way or the other prior to that time then the decision may be rendered earlier. Once a decision has been made the votes will be tallied and reported to this list and to discuss at openjdk.java.net. Only Members of the Compiler' Group are eligible to vote on this decision. The current Members are: Alex Buckley Maurizio Cimadamore Iris Clark Joe Darcy Neal Gafter Jonathan Gibbons Kumar Srinivasan [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080411/44d0e66c/attachment.html From Joe.Darcy at Sun.COM Fri Apr 11 10:30:43 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 11 Apr 2008 10:30:43 -0700 Subject: CFV: Project sponsorship: Closures For Java In-Reply-To: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> References: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> Message-ID: <47FFA043.7010700@sun.com> Vote: yes -Joe Jonathan Gibbons wrote: > Question: Should the Compiler Group sponsor the proposed new > Closures For Java Project? [1] > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC next Friday, > 18 April. If an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be > rendered earlier. Once a decision has been made the votes will be > tallied and reported to this list and to discuss at openjdk.java.net > . > > Only Members of the Compiler' Group are eligible to vote on this > decision. The current Members are: > > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Neal Gafter > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html From mandy.chung at sun.com Fri Apr 11 10:31:43 2008 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Fri, 11 Apr 2008 17:31:43 +0000 Subject: hg: jdk7/tl/jdk: 6687508: Update test/sun/management jtreg tests due to sun.management.ManagementFactory class rename Message-ID: <20080411173155.3FCC9278E0@hg.openjdk.java.net> Changeset: 18eed13fe9f6 Author: mchung Date: 2008-04-11 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/18eed13fe9f6 6687508: Update test/sun/management jtreg tests due to sun.management.ManagementFactory class rename Summary: Modified the jtreg tests to use ManagementFactoryHelper instead Reviewed-by: emcmanus ! test/sun/management/HotspotClassLoadingMBean/GetClassInitializationTime.java ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java From Jonathan.Gibbons at Sun.COM Fri Apr 11 10:35:33 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 11 Apr 2008 10:35:33 -0700 Subject: CFV: Project sponsorship: Closures For Java In-Reply-To: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> References: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> Message-ID: <0A9FE871-B2E8-4877-86FC-9B8E1CE2F704@sun.com> Vote: yes On Apr 11, 2008, at 10:21 AM, Jonathan Gibbons wrote: > Question: Should the Compiler Group sponsor the proposed new > Closures For Java Project? [1] > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC next Friday, > 18 April. If an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be > rendered earlier. Once a decision has been made the votes will be > tallied and reported to this list and to discuss at openjdk.java.net. > > Only Members of the Compiler' Group are eligible to vote on this > decision. The current Members are: > > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Neal Gafter > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080411/06a6ae82/attachment.html From Maurizio.Cimadamore at Sun.COM Fri Apr 11 10:38:32 2008 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Fri, 11 Apr 2008 18:38:32 +0100 Subject: CFV: Project sponsorship: Closures For Java In-Reply-To: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> References: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> Message-ID: <47FFA218.1060501@sun.com> Vote: yes I think that closures are a valuable, yet complex extension to the Java language that should be evaluated with care by all the members of the team! Maurizio Jonathan Gibbons wrote: > Question: Should the Compiler Group sponsor the proposed new > Closures For Java Project? [1] > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC next Friday, > 18 April. If an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be > rendered earlier. Once a decision has been made the votes will be > tallied and reported to this list and to discuss at openjdk.java.net > . > > Only Members of the Compiler' Group are eligible to vote on this > decision. The current Members are: > > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Neal Gafter > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html From Alex.Buckley at Sun.COM Fri Apr 11 14:58:02 2008 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Fri, 11 Apr 2008 14:58:02 -0700 Subject: CFV: Project sponsorship: Closures For Java Message-ID: <47FFDEEA.4010009@sun.com> Vote: yes Alex > Question: Should the Compiler Group sponsor the proposed new > Closures For Java Project? [1] > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC next Friday, > 18 April. If an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be > rendered earlier. Once a decision has been made the votes will be > tallied and reported to this list and to discuss at openjdk.java.net. > > Only Members of the Compiler' Group are eligible to vote on this > decision. The current Members are: > > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Neal Gafter > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html From neal at gafter.com Sat Apr 12 23:25:11 2008 From: neal at gafter.com (Neal Gafter) Date: Sat, 12 Apr 2008 23:25:11 -0700 Subject: CFV: Project sponsorship: Closures For Java In-Reply-To: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> References: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> Message-ID: <15e8b9d20804122325h6a251a85ic8712008638caefe@mail.gmail.com> Vote: yes On Fri, Apr 11, 2008 at 10:21 AM, Jonathan Gibbons wrote: > Question: Should the Compiler Group sponsor the proposed new Closures For > Java Project? [1] > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC next Friday, > 18 April. If an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be > rendered earlier. Once a decision has been made the votes will be > tallied and reported to this list and to discuss at openjdk.java.net. > > Only Members of the Compiler' Group are eligible to vote on this > decision. The current Members are: > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Neal Gafter > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080412/47992e00/attachment.html From Kumar.Srinivasan at Sun.COM Mon Apr 14 07:48:03 2008 From: Kumar.Srinivasan at Sun.COM (Kumar Srinivasan) Date: Mon, 14 Apr 2008 07:48:03 -0700 Subject: CFV: Project sponsorship: Closures For Java In-Reply-To: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> References: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> Message-ID: <48036EA3.5090505@Sun.COM> Vote: yes I am for anything which increases Java adoption, and I feel this is cool enough to do so. Kumar > Question: Should the Compiler Group sponsor the proposed new > Closures For Java Project? [1] > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC next Friday, > 18 April. If an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be > rendered earlier. Once a decision has been made the votes will be > tallied and reported to this list and to discuss at openjdk.java.net > . > > Only Members of the Compiler' Group are eligible to vote on this > decision. The current Members are: > > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Neal Gafter > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html -- Kumar Srinivasan Sun Microsystems, Java Software. 408-276-7586 From iris at sun.com Mon Apr 14 11:16:28 2008 From: iris at sun.com (iris clark) Date: Mon, 14 Apr 2008 11:16:28 -0700 (PDT) Subject: CFV: Project sponsorship: Closures For Java In-Reply-To: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> (message from Jonathan Gibbons on Fri, 11 Apr 2008 10:21:20 -0700) Message-ID: <200804141816.m3EIGS2M017290@ribbit.SFBay.Sun.COM> Vote: yes iris From Jonathan.Gibbons at Sun.COM Mon Apr 14 12:39:11 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 14 Apr 2008 12:39:11 -0700 Subject: CFV: Project sponsorship: Closures For Java In-Reply-To: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> References: <8E77F0B7-4245-4E2F-97F8-E7E54515D633@Sun.COM> Message-ID: <4803B2DF.3040103@sun.com> Having achieved unanimous support from all eligible voting members in favor of sponsoring this project, the vote is hereby concluded. The outcome is that the Compiler Group is in favor of the sponsoring the proposed new project, "Closures For Java." -- Jon Jonathan Gibbons wrote: > Question: Should the Compiler Group sponsor the proposed new > Closures For Java Project? [1] > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > The sponsorship decision will be made by a simple majority vote of > the Group's Members. Votes are due by midnight UTC next Friday, > 18 April. If an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be > rendered earlier. Once a decision has been made the votes will be > tallied and reported to this list and to discuss at openjdk.java.net > . > > Only Members of the Compiler' Group are eligible to vote on this > decision. The current Members are: > > Alex Buckley > Maurizio Cimadamore > Iris Clark > Joe Darcy > Neal Gafter > Jonathan Gibbons > Kumar Srinivasan > > > [1] http://mail.openjdk.java.net/pipermail/discuss/2008-April/001143.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080414/02c8345b/attachment.html From xueming.shen at sun.com Mon Apr 14 21:50:38 2008 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Tue, 15 Apr 2008 04:50:38 +0000 Subject: hg: jdk7/tl/jdk: 6635133: Exception thrown when using a Unicode escape Message-ID: <20080415045057.E6F5F27D44@hg.openjdk.java.net> Changeset: dd212ba9a0c6 Author: sherman Date: 2008-04-14 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd212ba9a0c6 6635133: Exception thrown when using a Unicode escape Summary: Update regex engine to handle unicode escape correctly in character class Reviewed-by: okutsu ! src/share/classes/java/util/regex/Pattern.java From Maurizio.Cimadamore at Sun.COM Tue Apr 15 04:51:01 2008 From: Maurizio.Cimadamore at Sun.COM (Maurizio Cimadamore) Date: Tue, 15 Apr 2008 12:51:01 +0100 Subject: 6679509: AssertionError in com.sun.tools.javac.jvm.Gen$1ComplexityScanner In-Reply-To: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> References: <87d9996a0804040055p7ef44f60k19e7a61247f12360@mail.gmail.com> Message-ID: <480496A5.1090500@sun.com> Thanks Jan, the patch was almost perfect. I had to fix a related issue that has to do with enhanced for loops with array e.g. for (List l : new List[] {}); This code gets translated in a different method of Lower, so it was necessary to fix that too (this has to be taken into account also when writing the regression test). I also found it useful to re-use the info contained into tree.var.vartype such as mods (modifiers) and type (for the erased type). This way the code is slightly more readable. I've updated the CR, so you can have a look at the proposed fix. Thanks for the precious (and effective) suggestion! Maurizio Jan Lahoda wrote: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6679509 > > Summary: An AssertionError is thrown while analyzing valid program. > The exception occurs when a foreach loop like: > for (java.util.List t : l) { > } > is used in a finally block, and target is 1.5. > > The problem's root cause is, IMO, that Gen is processing a tree with > generics (the generics should be stripped from the trees in > TransTypes, if I understand everything correctly). > > In this case, the code above gets correctly TransType-d to: > for (java.util.List t : l) { > } > > Then, during Lower, the foreach loop is expanded into an ordinary > Iterator-based loop: > for (java.util.Iterator i$ = l.iterator(); i$.hasNext(); ) { > List t = (List)i$.next(); > { > } > } > > which contains the tree with generics. > > This is side-effect of using TreeMaker.VarDef(VarSymbol v, > JCExpression init), which uses v.type (which contains generics) to > construct the tree for the variable's type. > > I have prepared a patch that constructs the tree for the variable > using erasure(v.type). The patch is attached. > > Any opinions on the patch? > > Thanks, > Jan > From alex at retroduction.org Wed Apr 16 14:17:19 2008 From: alex at retroduction.org (Alex Rau) Date: Wed, 16 Apr 2008 23:17:19 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future Message-ID: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> Hi all, I've searched the web and asked at forum.sun.com but my answer regarding the javac compiler couldn't be answered yet. so here we go with a rational first: Rational: I'd like to achieve the following: The byte code created with javac should not only contain line number information in debug mode, but additionally I want to track exactly which statement (including column information as there can be multiple statements in one source code line) leads to a certain bytecode instruction or a set of instructions. I strongly need this kind of functionality in javac as the project I'm working on is settled in the testing area (mutation testing in java on bytecode level which you can imagine as some kind of (beta) code coverage software with a different and IMHO superior technique - http://retroduction.org for more details if you are interested). The software must be able to report mutated *statements* which means that line informations are insufficient. My Question is: in older JDK's there was something called JCov which enhanced byte code with additional information regarding which statements finally led to a/multiple bytecode instruction(s). I stumbled upon this while debugging javac when I wanted to learn it's design/code. I think it's mostly what I need - however the JCov switch is a hidden feature. It was "more" public in JDK 1.2 and was pretended to have been ported to the JVMPI interface later. However I did not find where the port should have been integrated - I'm no JVMPI (and JVMTI) guru. Honestly I doubt that something similar is in the JVM(P/T)I toolset... So perhaps someone has more knowledge about JCov and what happened to it. Furthermore I'd like to push a discussion on whether this would be a candidate for the kitchen sink (no JLS changes, just internal) with the goal to implement the above described functionality *including a supported and public interface* (not a hidden feature anymore). The first benefit could then obviously be that javac could be mutation tested ;) Furthermore other Java developers would have solid information and documentation about this API instead of relying on mostly unknown and hidden features. Best Regards, Alex From Jonathan.Gibbons at Sun.COM Wed Apr 16 15:12:06 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 16 Apr 2008 15:12:06 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> Message-ID: <480679B6.50808@sun.com> Alex, The features for jcov support are still in the compiler. The switch is -Xjcov, it causes a CharacterRangeTable attribute to be added to the class file. The format of the attribute is not great -- in particular, it uses the old "packed line/offset" format for coordinates, which may not work for very long lines (over 1024 characters) that sometimes occur in mechanically generated code. Internally, javac now uses a simple character offset from the beginning of the file to define a source position. It would arguably be good to evolve the CharacterRangeTable attribute (in a compatible way) to using character offsets. Jcov is still around, though it has never really got the care and attention it merited. Every now and then, there is interest in making it more available. It generally comes down to lack of demand and internal resources. :-( -- Jon Alex Rau wrote: > Hi all, > > I've searched the web and asked at forum.sun.com but my answer > regarding the javac compiler couldn't be answered yet. so here we go > with a rational first: > > Rational: I'd like to achieve the following: The byte code created > with javac should not only contain line number information in debug > mode, but additionally I want to track exactly which statement > (including column information as there can be multiple statements in > one source code line) leads to a certain bytecode instruction or a set > of instructions. I strongly need this kind of functionality in javac > as the project I'm working on is settled in the testing area (mutation > testing in java on bytecode level which you can imagine as some kind > of (beta) code coverage software with a different and IMHO superior > technique - http://retroduction.org for more details if you are > interested). The software must be able to report mutated *statements* > which means that line informations are insufficient. > > My Question is: in older JDK's there was something called JCov which > enhanced byte code with additional information regarding which > statements finally led to a/multiple bytecode instruction(s). I > stumbled upon this while debugging javac when I wanted to learn it's > design/code. I think it's mostly what I need - however the JCov switch > is a hidden feature. It was "more" public in JDK 1.2 and was pretended > to have been ported to the JVMPI interface later. However I did not > find where the port should have been integrated - I'm no JVMPI (and > JVMTI) guru. Honestly I doubt that something similar is in the > JVM(P/T)I toolset... > > So perhaps someone has more knowledge about JCov and what happened to > it. Furthermore I'd like to push a discussion on whether this would be > a candidate for the kitchen sink (no JLS changes, just internal) with > the goal to implement the above described functionality *including a > supported and public interface* (not a hidden feature anymore). The > first benefit could then obviously be that javac could be mutation > tested ;) Furthermore other Java developers would have solid > information and documentation about this API instead of relying on > mostly unknown and hidden features. > > Best Regards, > > Alex > From alex at retroduction.org Wed Apr 16 16:47:23 2008 From: alex at retroduction.org (Alex Rau) Date: Thu, 17 Apr 2008 01:47:23 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <480679B6.50808@sun.com> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> Message-ID: <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> On 17.04.2008, at 00:12, Jonathan Gibbons wrote: > Jcov is still around, though it has never really got the care and > attention it merited. Every now and then, there is interest in > making it more available. It generally comes down to lack of demand > and internal resources. :-( What exactly is the purpose of jcov in current JDK's ? The coverage feature itself has been superseded by JVMTI while the jcov implementation still exists, is that correct ? Legacy coverage tools (at least I know) rely anyway on line information exclusively and are therefore not interested in column information or offsets. So what use case is left for JCov ? Am I correct, that it just exists more or less as an artificial piece of code from past times without a real purpose ? Well. Actually I think the implementation deserves more attention from the compiler's point of view. JVMTI and JVMPI focus on making the state of the VM (during runtime) more visible. JCov in it's current implementation makes the compiler operation (in a different way via byte code attributes) visible and that's perfectly fine in my opinion and useful for tools which focus on static information on class files (independently what happens during runtime). It's however open whether the compiler operation information is really required to be stored in the byte code. Another option would be to create a single file or one file for each class which exclusively contains the information. These files could be enhanced with other information from the compiler execution as well (what ever that could be) - some kind of standard compiler tracing output. Due to my personal interest I'd love to work on that feature. If it all goes well and it's getting along in a way which is useful for general purpose - perfect. > The features for jcov support are still in the compiler. The > switch is -Xjcov, it causes a CharacterRangeTable attribute to be > added to the class file. The format of the attribute is not great > -- in particular, it uses the old "packed line/offset" format for > coordinates, which may not work for very long lines (over 1024 > characters) that sometimes occur in mechanically generated code. > Internally, javac now uses a simple character offset from the > beginning of the file to define a source position. It would > arguably be good to evolve the CharacterRangeTable attribute (in a > compatible way) to using character offsets. > > I agree. I think - given that javac itself uses (as you mentioned) a single offset value it would make sense to stick with it and use this value for generating appropriate byte code including these offset attributes. Tools using these values in general have access to the source code anyway as most often the code is pretty printed in HTML or something else. So mapping a single file offset to a certain line + offset combination would be easily possible during parsing the source code for such tools. So in case the usefulness of properly tracing above mentioned information is common sense - what would be the best way ? Here some aspects: - interleaved output with byte code vs. separate output (file) interface - replace/reuse/adapt jcov code vs. keep jcov as it is and implement new stuff from scratch in parallel (compatibility?) - absolute file offsets as you mentioned vs. something else ? regards, alex > > -- Jon > > > > > Alex Rau wrote: >> Hi all, >> >> I've searched the web and asked at forum.sun.com but my answer >> regarding the javac compiler couldn't be answered yet. so here we >> go with a rational first: >> >> Rational: I'd like to achieve the following: The byte code created >> with javac should not only contain line number information in >> debug mode, but additionally I want to track exactly which >> statement (including column information as there can be multiple >> statements in one source code line) leads to a certain bytecode >> instruction or a set of instructions. I strongly need this kind of >> functionality in javac as the project I'm working on is settled in >> the testing area (mutation testing in java on bytecode level >> which you can imagine as some kind of (beta) code coverage >> software with a different and IMHO superior technique - http:// >> retroduction.org for more details if you are interested). The >> software must be able to report mutated *statements* which means >> that line informations are insufficient. >> >> My Question is: in older JDK's there was something called JCov >> which enhanced byte code with additional information regarding >> which statements finally led to a/multiple bytecode instruction >> (s). I stumbled upon this while debugging javac when I wanted to >> learn it's design/code. I think it's mostly what I need - however >> the JCov switch is a hidden feature. It was "more" public in JDK >> 1.2 and was pretended to have been ported to the JVMPI interface >> later. However I did not find where the port should have been >> integrated - I'm no JVMPI (and JVMTI) guru. Honestly I doubt that >> something similar is in the JVM(P/T)I toolset... >> >> So perhaps someone has more knowledge about JCov and what happened >> to it. Furthermore I'd like to push a discussion on whether this >> would be a candidate for the kitchen sink (no JLS changes, just >> internal) with the goal to implement the above described >> functionality *including a supported and public interface* (not a >> hidden feature anymore). The first benefit could then obviously be >> that javac could be mutation tested ;) Furthermore other Java >> developers would have solid information and documentation about >> this API instead of relying on mostly unknown and hidden features. >> >> Best Regards, >> >> Alex >> > From John.Rose at Sun.COM Wed Apr 16 17:08:23 2008 From: John.Rose at Sun.COM (John Rose) Date: Wed, 16 Apr 2008 17:08:23 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> Message-ID: <31C56CAF-888B-4251-BF10-957E2E362DF2@sun.com> On Apr 16, 2008, at 4:47 PM, Alex Rau wrote: > - absolute file offsets as you mentioned vs. something else ? Those are simplest. BTW, 64-bit offsets are overkill, given the 16- and 32-bit limitations elsewhere in the format. Slightly more compressible (and invariant under low-level encoding changes) would be token serial numbers. The consumer of the index information is likely to have a lexer available. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080416/4cae5956/attachment.html From Jonathan.Gibbons at Sun.COM Wed Apr 16 17:14:15 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 16 Apr 2008 17:14:15 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> Message-ID: <48069657.6050307@sun.com> Alex Rau wrote: > On 17.04.2008, at 00:12, Jonathan Gibbons wrote: > >> Jcov is still around, though it has never really got the care and >> attention it merited. Every now and then, there is interest in >> making it more available. It generally comes down to lack of demand >> and internal resources. :-( > > > What exactly is the purpose of jcov in current JDK's ? The coverage > feature itself has been superseded by JVMTI while the jcov > implementation still exists, is that correct ? Legacy coverage tools > (at least I know) rely anyway on line information exclusively and are > therefore not interested in column information or offsets. So what use > case is left for JCov ? Am I correct, that it just exists more or less > as an artificial piece of code from past times without a real purpose ? My understanding is that jcov is still used within Sun for determining code coverage of the various different test suites. > > Well. Actually I think the implementation deserves more attention from > the compiler's point of view. JVMTI and JVMPI focus on making the > state of the VM (during runtime) more visible. JCov in it's current > implementation makes the compiler operation (in a different way via > byte code attributes) visible and that's perfectly fine in my opinion > and useful for tools which focus on static information on class files > (independently what happens during runtime). > > It's however open whether the compiler operation information is really > required to be stored in the byte code. Another option would be to > create a single file or one file for each class which exclusively > contains the information. These files could be enhanced with other > information from the compiler execution as well (what ever that could > be) - some kind of standard compiler tracing output. > > Due to my personal interest I'd love to work on that feature. If it > all goes well and it's getting along in a way which is useful for > general purpose - perfect. We have had internal "hallway"-type discussions on the future of the CharacterRangeTable attribute and ways to go forward. Having separate files would certainly make it simpler to distribute such files for existing class libraries that do not want to incur the hit of the extra class file space required. I think that experiments like this on the compiler, and on related tools, are a great idea. To get started, you can just pull down a copy of OpenJDK from the Mercurial repositories. However, note that to contribute anything back to OpenJDK, you'll need to sign the SCA form, available on this page http://openjdk.java.net/legal/ > >> The features for jcov support are still in the compiler. The switch >> is -Xjcov, it causes a CharacterRangeTable attribute to be added to >> the class file. The format of the attribute is not great -- in >> particular, it uses the old "packed line/offset" format for >> coordinates, which may not work for very long lines (over 1024 >> characters) that sometimes occur in mechanically generated code. >> Internally, javac now uses a simple character offset from the >> beginning of the file to define a source position. It would arguably >> be good to evolve the CharacterRangeTable attribute (in a compatible >> way) to using character offsets. >> >> > > I agree. I think - given that javac itself uses (as you mentioned) a > single offset value it would make sense to stick with it and use this > value for generating appropriate byte code including these offset > attributes. Tools using these values in general have access to the > source code anyway as most often the code is pretty printed in HTML or > something else. So mapping a single file offset to a certain line + > offset combination would be easily possible during parsing the source > code for such tools. The code for getting line and offset from character number is in javac, in util/Log.java. > > > So in case the usefulness of properly tracing above mentioned > information is common sense - what would be the best way ? Here some > aspects: > > - interleaved output with byte code vs. separate output (file) interface > - replace/reuse/adapt jcov code vs. keep jcov as it is and implement > new stuff from scratch in parallel (compatibility?) > - absolute file offsets as you mentioned vs. something else ? It would be interesting to get some jcov folk in the discussion to discuss the merits of making jcov available and using that as a basis for work, compared to starting over. > > regards, > > alex > > >> >> -- Jon >> >> >> >> >> Alex Rau wrote: >>> Hi all, >>> >>> I've searched the web and asked at forum.sun.com but my answer >>> regarding the javac compiler couldn't be answered yet. so here we go >>> with a rational first: >>> >>> Rational: I'd like to achieve the following: The byte code created >>> with javac should not only contain line number information in debug >>> mode, but additionally I want to track exactly which statement >>> (including column information as there can be multiple statements in >>> one source code line) leads to a certain bytecode instruction or a >>> set of instructions. I strongly need this kind of functionality in >>> javac as the project I'm working on is settled in the testing area >>> (mutation testing in java on bytecode level which you can imagine >>> as some kind of (beta) code coverage software with a different and >>> IMHO superior technique - http://retroduction.org for more details >>> if you are interested). The software must be able to report mutated >>> *statements* which means that line informations are insufficient. >>> >>> My Question is: in older JDK's there was something called JCov which >>> enhanced byte code with additional information regarding which >>> statements finally led to a/multiple bytecode instruction(s). I >>> stumbled upon this while debugging javac when I wanted to learn it's >>> design/code. I think it's mostly what I need - however the JCov >>> switch is a hidden feature. It was "more" public in JDK 1.2 and was >>> pretended to have been ported to the JVMPI interface later. However >>> I did not find where the port should have been integrated - I'm no >>> JVMPI (and JVMTI) guru. Honestly I doubt that something similar is >>> in the JVM(P/T)I toolset... >>> >>> So perhaps someone has more knowledge about JCov and what happened >>> to it. Furthermore I'd like to push a discussion on whether this >>> would be a candidate for the kitchen sink (no JLS changes, just >>> internal) with the goal to implement the above described >>> functionality *including a supported and public interface* (not a >>> hidden feature anymore). The first benefit could then obviously be >>> that javac could be mutation tested ;) Furthermore other Java >>> developers would have solid information and documentation about this >>> API instead of relying on mostly unknown and hidden features. >>> >>> Best Regards, >>> >>> Alex >>> >> > From tim.bell at sun.com Thu Apr 17 19:34:00 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:34:00 +0000 Subject: hg: jdk7/tl: 3 new changesets Message-ID: <20080418023400.9679227F16@hg.openjdk.java.net> Changeset: 05809a7eb190 Author: ohair Date: 2008-03-18 11:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/05809a7eb190 6674232: OPENJDK=false is same as OPENJDK=true Summary: If OPENJDK has a value, that value must be "true", empty value == undefined with GNU make. Reviewed-by: tbell ! make/Defs-internal.gmk Changeset: cbc8ad9dd0e0 Author: ohair Date: 2008-03-25 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/cbc8ad9dd0e0 6623832: Cleanup old j2se makefile targets Summary: Just removing unneeded makefile rules and 'control' logic. Reviewed-by: xdono ! Makefile ! make/jdk-rules.gmk Changeset: 9410f77cc30c Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/9410f77cc30c Added tag jdk7-b25 for changeset cbc8ad9dd0e0 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:34:31 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:34:31 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20080418023433.AE7E427F1B@hg.openjdk.java.net> Changeset: 5e61d5df6258 Author: ohair Date: 2008-03-25 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/5e61d5df6258 6627817: Remove ^M characters in all files (Makefiles too) Summary: Some files included the use of the ^M character, which has been deleted Reviewed-by: xdono ! src/share/classes/com/sun/corba/se/impl/corba/orb_config_design.txt ! src/share/classes/org/omg/CORBA/ir.idl ! src/share/classes/org/omg/DynamicAny/DynamicAny.idl Changeset: 0043eb3d4e62 Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0043eb3d4e62 Added tag jdk7-b25 for changeset 5e61d5df6258 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:35:48 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:35:48 +0000 Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b25 for changeset 7836be3e92d0 Message-ID: <20080418023551.EA96E27F22@hg.openjdk.java.net> Changeset: 8b0b3490194f Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b0b3490194f Added tag jdk7-b25 for changeset 7836be3e92d0 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:37:28 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:37:28 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b25 for changeset a3b3ba7d6034 Message-ID: <20080418023730.5E1FC27F29@hg.openjdk.java.net> Changeset: da43cb85fac1 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/da43cb85fac1 Added tag jdk7-b25 for changeset a3b3ba7d6034 ! .hgtags From tim.bell at sun.com Thu Apr 17 19:38:01 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:38:01 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b25 for changeset 59fd8224ba2d Message-ID: <20080418023803.E442C27F32@hg.openjdk.java.net> Changeset: debd37e1a422 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/debd37e1a422 Added tag jdk7-b25 for changeset 59fd8224ba2d ! .hgtags From tim.bell at sun.com Thu Apr 17 19:39:08 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:39:08 +0000 Subject: hg: jdk7/tl/jdk: 12 new changesets Message-ID: <20080418024141.1488F27F37@hg.openjdk.java.net> Changeset: f1c168caf94f Author: ohair Date: 2008-03-18 11:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1c168caf94f 6674226: Warning errors in freetypecheck Summary: Just corrected some C code to remove warning errors from gcc. Reviewed-by: tbell ! make/tools/freetypecheck/freetypecheck.c Changeset: e564dc9241e5 Author: ohair Date: 2008-03-18 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e564dc9241e5 6611788: chmod a+x bin/winver.exe in make/tools/winver/Makefile fails on a read only file system Summary: Tell Mercurial this file has execute permission. Reviewed-by: tbell Changeset: ea98209ac149 Author: ohair Date: 2008-03-18 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea98209ac149 6674232: OPENJDK=false is same as OPENJDK=true Summary: OPENJDK should be empty (undefined) or "true". Reviewed-by: tbell ! make/common/Defs.gmk Changeset: e98ce66d7630 Author: ohair Date: 2008-03-18 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e98ce66d7630 6654458: /java/devtools findbugs doesn't work on windows Summary: Changes to both ant and findbugs version checking. Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 9ae5ccf6891c Author: ohair Date: 2008-03-19 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ae5ccf6891c 6611629: Avoid hardcoded cygwin paths for memory detection Summary: Use free with sygwin, mem or systeminfo otherwise, to get MB_OF_MEMORY on windows. Reviewed-by: tbell ! make/common/shared/Platform.gmk Changeset: 9b0d53aa8549 Author: ohair Date: 2008-03-25 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b0d53aa8549 6627817: Remove ^M characters in all files (Makefiles too) Summary: Some files included the use of the ^M character, which has been deleted. Reviewed-by: xdono ! make/common/shared/Sanity.gmk ! make/docs/CORE_PKGS.gmk ! src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties ! src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.dtd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/schema/etsi.xsd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/javax/swing/plaf/synth/doc-files/synth.dtd ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/demo/jfc/Notepad/resources/Notepad.properties ! src/share/sample/vm/clr-jvm/Makefile ! src/share/sample/vm/clr-jvm/README.txt ! src/share/sample/vm/clr-jvm/invoker.cs ! src/share/sample/vm/jvm-clr/README.txt ! src/share/sample/vm/jvm-clr/invoked.cs Changeset: 40b6f7fcac38 Author: ohair Date: 2008-03-26 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/40b6f7fcac38 Merge Changeset: 75fca0b0ab83 Author: xdono Date: 2008-03-27 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75fca0b0ab83 Merge Changeset: 6e25a8a3f8c6 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e25a8a3f8c6 Added tag jdk7-b25 for changeset 75fca0b0ab83 ! .hgtags Changeset: e6da580585e9 Author: tbell Date: 2008-04-07 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6da580585e9 Merge ! make/common/shared/Defs.gmk Changeset: 4708b9a13f24 Author: tbell Date: 2008-04-11 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4708b9a13f24 Merge Changeset: 74a42d77106b Author: tbell Date: 2008-04-15 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74a42d77106b Merge From tim.bell at sun.com Thu Apr 17 19:44:34 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:44:34 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20080418024440.5980927F3C@hg.openjdk.java.net> Changeset: 18f0b1b5ffd6 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/18f0b1b5ffd6 Added tag jdk7-b25 for changeset 58039502942e ! .hgtags Changeset: c46d25a2350a Author: tbell Date: 2008-04-11 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c46d25a2350a Merge Changeset: 627deea1ea4f Author: tbell Date: 2008-04-15 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/627deea1ea4f Merge From keith.mcguigan at sun.com Thu Apr 17 21:22:54 2008 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Fri, 18 Apr 2008 04:22:54 +0000 Subject: hg: jdk7/tl/jdk: 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes Message-ID: <20080418042306.9898F27F49@hg.openjdk.java.net> Changeset: 2bfddc119eea Author: kamg Date: 2008-04-17 22:00 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2bfddc119eea 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes Summary: Initial checkin of JSDT code Reviewed-by: sspitsyn, sbohne ! make/com/sun/Makefile + make/com/sun/tracing/Makefile + make/com/sun/tracing/dtrace/Makefile ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk ! make/sun/Makefile + make/sun/tracing/Makefile + make/sun/tracing/dtrace/Makefile + make/sun/tracing/dtrace/mapfile-vers + src/share/classes/com/sun/tracing/Probe.java + src/share/classes/com/sun/tracing/ProbeName.java + src/share/classes/com/sun/tracing/Provider.java + src/share/classes/com/sun/tracing/ProviderFactory.java + src/share/classes/com/sun/tracing/ProviderName.java + src/share/classes/com/sun/tracing/dtrace/ArgsAttributes.java + src/share/classes/com/sun/tracing/dtrace/Attributes.java + src/share/classes/com/sun/tracing/dtrace/DependencyClass.java + src/share/classes/com/sun/tracing/dtrace/FunctionAttributes.java + src/share/classes/com/sun/tracing/dtrace/FunctionName.java + src/share/classes/com/sun/tracing/dtrace/ModuleAttributes.java + src/share/classes/com/sun/tracing/dtrace/ModuleName.java + src/share/classes/com/sun/tracing/dtrace/NameAttributes.java + src/share/classes/com/sun/tracing/dtrace/ProviderAttributes.java + src/share/classes/com/sun/tracing/dtrace/StabilityLevel.java + src/share/classes/com/sun/tracing/dtrace/package-info.java + src/share/classes/com/sun/tracing/package-info.java + src/share/classes/sun/tracing/MultiplexProviderFactory.java + src/share/classes/sun/tracing/NullProviderFactory.java + src/share/classes/sun/tracing/PrintStreamProviderFactory.java + src/share/classes/sun/tracing/ProbeSkeleton.java + src/share/classes/sun/tracing/ProviderSkeleton.java + src/share/classes/sun/tracing/dtrace/Activation.java + src/share/classes/sun/tracing/dtrace/DTraceProbe.java + src/share/classes/sun/tracing/dtrace/DTraceProvider.java + src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java + src/share/classes/sun/tracing/dtrace/JVM.java + src/share/classes/sun/tracing/package-info.java ! src/share/javavm/export/jvm.h + src/share/native/sun/tracing/dtrace/JVM.c + src/share/native/sun/tracing/dtrace/jvm_symbols.h + src/solaris/native/sun/tracing/dtrace/jvm_symbols_md.c + src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c + test/com/sun/tracing/BasicFunctionality.java From alex at retroduction.org Sat Apr 19 04:27:08 2008 From: alex at retroduction.org (Alex Rau) Date: Sat, 19 Apr 2008 13:27:08 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <48069657.6050307@sun.com> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> <48069657.6050307@sun.com> Message-ID: <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> On 17.04.2008, at 02:14, Jonathan Gibbons wrote: > > The code for getting line and offset from character number is in > javac, in util/Log.java. > >> >> >> So in case the usefulness of properly tracing above mentioned >> information is common sense - what would be the best way ? Here >> some aspects: >> >> - interleaved output with byte code vs. separate output (file) >> interface >> - replace/reuse/adapt jcov code vs. keep jcov as it is and >> implement new stuff from scratch in parallel (compatibility?) >> - absolute file offsets as you mentioned vs. something else ? > It would be interesting to get some jcov folk in the discussion to > discuss the merits of making jcov available and using that as a > basis for work, compared to starting over. Sounds good. In the meanwhile I've added some code for writing the information into separate files (let's call it trace file). One trace file per class right beside them. What kind of format would be appropriate ? I'm currently working towards a 3 int record based ascii encoded file (human-readable, lightweight) with fields (trace id, source position, end position). The instruction trace id is used in the byte code by a new attribute called "traceid" as well (guess this setup is what John meant with token serial numbers - if not please correct me). That seems to me to be the most simple approach for getting first results which can be discussed then. Unfortunately I'm struggling with the IDE setup (new to netbeans, long-time eclipse coder). Debugging a unit test from netbeans (without ant invocation - most often getting unresolved ant properties) is a black hole for me right now :S In case someone has a hint on how to do that just send me a private email. Best regards and enjoy your weekend, Alex From Sergey.Borodin at Sun.COM Sat Apr 19 08:38:27 2008 From: Sergey.Borodin at Sun.COM (Sergey Borodin) Date: Sat, 19 Apr 2008 19:38:27 +0400 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <48069657.6050307@sun.com> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> Message-ID: <480A11F3.7030108@sun.com> Hello, I am involved in development of sun's internal jcov tool. As I heard, long ago it was part of sun's jvm, and, as I understand, this is what you're talking about. Modern jcov is standalone java application (plus some C code to implement JVMPI / JVMTI agents), which uses different techniques to instrument bytecode, before it is loaded inside VM. Those sun teams, who would like to know code coverage metrics, use our jcov. I do not know, if anybody use those JVM functionality, which you call "jcov". Regarding CharacterRangeTable, this information is used by jcov to markup src code with coverage results, in process of report generation. I will response to any your questions with pleasure, Thanks, -- Sergey Borodin Jonathan Gibbons wrote: > Alex Rau wrote: >> On 17.04.2008, at 00:12, Jonathan Gibbons wrote: >> >>> Jcov is still around, though it has never really got the care and >>> attention it merited. Every now and then, there is interest in >>> making it more available. It generally comes down to lack of demand >>> and internal resources. :-( >> >> >> What exactly is the purpose of jcov in current JDK's ? The coverage >> feature itself has been superseded by JVMTI while the jcov >> implementation still exists, is that correct ? Legacy coverage tools >> (at least I know) rely anyway on line information exclusively and >> are therefore not interested in column information or offsets. So >> what use case is left for JCov ? Am I correct, that it just exists >> more or less as an artificial piece of code from past times without >> a real purpose ? > My understanding is that jcov is still used within Sun for > determining code coverage of the various different test suites. > >> >> Well. Actually I think the implementation deserves more attention >> from the compiler's point of view. JVMTI and JVMPI focus on making >> the state of the VM (during runtime) more visible. JCov in it's >> current implementation makes the compiler operation (in a different >> way via byte code attributes) visible and that's perfectly fine in >> my opinion and useful for tools which focus on static information on >> class files (independently what happens during runtime). >> >> It's however open whether the compiler operation information is >> really required to be stored in the byte code. Another option would >> be to create a single file or one file for each class which >> exclusively contains the information. These files could be enhanced >> with other information from the compiler execution as well (what >> ever that could be) - some kind of standard compiler tracing output. >> >> Due to my personal interest I'd love to work on that feature. If it >> all goes well and it's getting along in a way which is useful for >> general purpose - perfect. > We have had internal "hallway"-type discussions on the future of the > CharacterRangeTable attribute and ways to go forward. Having separate > files would certainly make it simpler to distribute such files for > existing class libraries that do not want to incur the hit of the > extra class file space required. > > I think that experiments like this on the compiler, and on related > tools, are a great idea. To get started, you can just pull down a > copy of OpenJDK from the Mercurial repositories. However, note that > to contribute anything back to OpenJDK, you'll need to sign the SCA > form, available on this page http://openjdk.java.net/legal/ > >> >>> The features for jcov support are still in the compiler. The >>> switch is -Xjcov, it causes a CharacterRangeTable attribute to be >>> added to the class file. The format of the attribute is not great >>> -- in particular, it uses the old "packed line/offset" format for >>> coordinates, which may not work for very long lines (over 1024 >>> characters) that sometimes occur in mechanically generated code. >>> Internally, javac now uses a simple character offset from the >>> beginning of the file to define a source position. It would >>> arguably be good to evolve the CharacterRangeTable attribute (in a >>> compatible way) to using character offsets. >>> >>> >> >> I agree. I think - given that javac itself uses (as you mentioned) >> a single offset value it would make sense to stick with it and use >> this value for generating appropriate byte code including these >> offset attributes. Tools using these values in general have access >> to the source code anyway as most often the code is pretty printed >> in HTML or something else. So mapping a single file offset to a >> certain line + offset combination would be easily possible during >> parsing the source code for such tools. > > The code for getting line and offset from character number is in > javac, in util/Log.java. > >> >> >> So in case the usefulness of properly tracing above mentioned >> information is common sense - what would be the best way ? Here some >> aspects: >> >> - interleaved output with byte code vs. separate output (file) >> interface >> - replace/reuse/adapt jcov code vs. keep jcov as it is and implement >> new stuff from scratch in parallel (compatibility?) >> - absolute file offsets as you mentioned vs. something else ? > It would be interesting to get some jcov folk in the discussion to > discuss the merits of making jcov available and using that as a basis > for work, compared to starting over. > >> >> regards, >> >> alex >> >> >>> >>> -- Jon >>> >>> >>> >>> >>> Alex Rau wrote: >>>> Hi all, >>>> >>>> I've searched the web and asked at forum.sun.com but my answer >>>> regarding the javac compiler couldn't be answered yet. so here we >>>> go with a rational first: >>>> >>>> Rational: I'd like to achieve the following: The byte code created >>>> with javac should not only contain line number information in >>>> debug mode, but additionally I want to track exactly which >>>> statement (including column information as there can be multiple >>>> statements in one source code line) leads to a certain bytecode >>>> instruction or a set of instructions. I strongly need this kind of >>>> functionality in javac as the project I'm working on is settled in >>>> the testing area (mutation testing in java on bytecode level >>>> which you can imagine as some kind of (beta) code coverage >>>> software with a different and IMHO superior technique - >>>> http://retroduction.org for more details if you are interested). >>>> The software must be able to report mutated *statements* which >>>> means that line informations are insufficient. >>>> >>>> My Question is: in older JDK's there was something called JCov >>>> which enhanced byte code with additional information regarding >>>> which statements finally led to a/multiple bytecode >>>> instruction(s). I stumbled upon this while debugging javac when I >>>> wanted to learn it's design/code. I think it's mostly what I need >>>> - however the JCov switch is a hidden feature. It was "more" >>>> public in JDK 1.2 and was pretended to have been ported to the >>>> JVMPI interface later. However I did not find where the port >>>> should have been integrated - I'm no JVMPI (and JVMTI) guru. >>>> Honestly I doubt that something similar is in the JVM(P/T)I >>>> toolset... >>>> >>>> So perhaps someone has more knowledge about JCov and what happened >>>> to it. Furthermore I'd like to push a discussion on whether this >>>> would be a candidate for the kitchen sink (no JLS changes, just >>>> internal) with the goal to implement the above described >>>> functionality *including a supported and public interface* (not a >>>> hidden feature anymore). The first benefit could then obviously be >>>> that javac could be mutation tested ;) Furthermore other Java >>>> developers would have solid information and documentation about >>>> this API instead of relying on mostly unknown and hidden features. >>>> >>>> Best Regards, >>>> >>>> Alex >>>> >>> >> >> > From John.Rose at Sun.COM Sat Apr 19 11:34:02 2008 From: John.Rose at Sun.COM (John Rose) Date: Sat, 19 Apr 2008 11:34:02 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> <48069657.6050307@sun.com> <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> Message-ID: On Apr 19, 2008, at 4:27 AM, Alex Rau wrote: > what John meant with token serial numbers Serial = sequentially assigned. For some definition of token, first token in file gets serial number 1, second gets 2, etc. If complete file has N tokens, last token serial number is N. It's almost the same as byte offset, just (a) more compact and (b) more stable under semantically null edits. FWIW. Use byte offsets for simplicity! -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080419/5d0da396/attachment.html From forax at univ-mlv.fr Mon Apr 21 06:54:01 2008 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 21 Apr 2008 15:54:01 +0200 Subject: List is not equivalent to List Message-ID: <480C9C79.7070101@univ-mlv.fr> Hi all, the JLS currently considers that List is not equivalent to List. List is reified but not List so they behave differently. It's not a big problem in general, if you want a List, you declare a List But (there is always a but), when the compiler infers a type argument it's more problematic, by example, HashSet> constantClassSet=new HashSet>(); Collections.addAll(constantClassSet, String.class, Object.class ); emits a warning because the second line creates an array of Class which is not safe. I think it's stupid, i propose to modify section 15.12.2.7 (JLS3) to add a line saying that if an inferred type argument is Type with Bound the bound of the type varaible of Type, it is inferred Type. cheers, R?mi From Thomas.Hawtin at Sun.COM Mon Apr 21 07:34:54 2008 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 21 Apr 2008 15:34:54 +0100 Subject: List is not equivalent to List In-Reply-To: <480C9C79.7070101@univ-mlv.fr> References: <480C9C79.7070101@univ-mlv.fr> Message-ID: <480CA60E.4020409@sun.com> R?mi Forax wrote: > > It's not a big problem in general, if you want a List, you declare a > List > But (there is always a but), when the compiler infers a type argument > it's more problematic, by example, > > HashSet> constantClassSet=new HashSet>(); > Collections.addAll(constantClassSet, > String.class, Object.class > ); > > emits a warning because the second line creates an array of > Class which is not safe. > > I think it's stupid, i propose to modify section 15.12.2.7 (JLS3) to > add a line saying that if an inferred type argument is Type Bound> > with Bound the bound of the type varaible of Type, it is inferred Type. Would that be useful in general? Consider if you had used String.class and Integer.class. Then the inferred component type would be Class> (or something like that!). So your rule wouldn't come in to play. Tom Hawtin (Disclaimer: I am not a language lawyer.) From keith.mcguigan at sun.com Mon Apr 21 11:59:20 2008 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Mon, 21 Apr 2008 18:59:20 +0000 Subject: hg: jdk7/tl/jdk: 6691494: doc build broken in tracingdocs Message-ID: <20080421185944.5816F2707E@hg.openjdk.java.net> Changeset: 79b594e72df0 Author: kamg Date: 2008-04-21 11:24 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/79b594e72df0 6691494: doc build broken in tracingdocs Summary: Wrong variable names in makefile Reviewed-by: tbell ! make/docs/Makefile From Alex.Buckley at Sun.COM Mon Apr 21 12:35:46 2008 From: Alex.Buckley at Sun.COM (Alex Buckley) Date: Mon, 21 Apr 2008 12:35:46 -0700 Subject: List is not equivalent to List In-Reply-To: <480C9C79.7070101@univ-mlv.fr> References: <480C9C79.7070101@univ-mlv.fr> Message-ID: <480CEC92.6050502@sun.com> Remi, Please don't bring JLS changes to compiler-dev. OpenJDK is about the Java platform's implementation, not its spec. As the spec lead for the Java language and VM, I do not subscribe to compiler-dev and only occasionally review its archives. You can file spec defects and RFEs at bugs.sun.com with the Submit A Bug form: Product/Category: Java Platform Standard Edition (JDK/JRE) Subcategory: Java Language Spec. and Java Virtual Machine Spec. (specification) Release: OpenJDK Operating System: // Whatever you like See also bug 6480391. Alex R?mi Forax wrote: > Hi all, > the JLS currently considers that List is not > equivalent to List. > List is reified but not List so they behave > differently. > > It's not a big problem in general, if you want a List, you declare a > List > But (there is always a but), when the compiler infers a type argument > it's more problematic, by example, > > HashSet> constantClassSet=new HashSet>(); > Collections.addAll(constantClassSet, > String.class, Object.class > ); > > emits a warning because the second line creates an array of > Class which is not safe. > > I think it's stupid, i propose to modify section 15.12.2.7 (JLS3) to > add a line saying that if an inferred type argument is Type Bound> > with Bound the bound of the type varaible of Type, it is inferred Type. > > cheers, > R?mi From forax at univ-mlv.fr Mon Apr 21 12:35:49 2008 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 21 Apr 2008 21:35:49 +0200 Subject: List is not equivalent to List In-Reply-To: <480CA60E.4020409@sun.com> References: <480C9C79.7070101@univ-mlv.fr> <480CA60E.4020409@sun.com> Message-ID: <480CEC95.8070400@univ-mlv.fr> Tom Hawtin a ?crit : > R?mi Forax wrote: >> >> It's not a big problem in general, if you want a List, you declare >> a List >> But (there is always a but), when the compiler infers a type argument >> it's more problematic, by example, >> >> HashSet> constantClassSet=new HashSet>(); >> Collections.addAll(constantClassSet, >> String.class, Object.class >> ); >> >> emits a warning because the second line creates an array of >> Class which is not safe. >> >> I think it's stupid, i propose to modify section 15.12.2.7 (JLS3) to >> add a line saying that if an inferred type argument is Type> Bound> >> with Bound the bound of the type varaible of Type, it is inferred >> Type. > > Would that be useful in general? not in general. Just for that use case. > > Consider if you had used String.class and Integer.class. Then the > inferred component type would be Class Serializable&Comparable> (or > something like that!). So your rule wouldn't come in to play. yes. For the records, Maurizio point me that it's can be seen as a specific case of that bug: http://bugs.sun.com/view_bug.do?bug_id=6480391 > > Tom Hawtin > > (Disclaimer: I am not a language lawyer.) R?mi (Disclaimer: so am i) From Uday.Dhanikonda at Sun.COM Mon Apr 21 13:30:48 2008 From: Uday.Dhanikonda at Sun.COM (Uday Dhanikonda) Date: Mon, 21 Apr 2008 13:30:48 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> Message-ID: <480CF978.8070000@Sun.COM> Alex There was an effort by Robert recently to rewrite JCov using JVM TI. Robert can you comment on this. Thanks Uday Alex Rau wrote: > Hi all, > > I've searched the web and asked at forum.sun.com but my answer > regarding the javac compiler couldn't be answered yet. so here we go > with a rational first: > > Rational: I'd like to achieve the following: The byte code created > with javac should not only contain line number information in debug > mode, but additionally I want to track exactly which statement > (including column information as there can be multiple statements in > one source code line) leads to a certain bytecode instruction or a set > of instructions. I strongly need this kind of functionality in javac > as the project I'm working on is settled in the testing area (mutation > testing in java on bytecode level which you can imagine as some kind > of (beta) code coverage software with a different and IMHO superior > technique - http://retroduction.org for more details if you are > interested). The software must be able to report mutated *statements* > which means that line informations are insufficient. > > My Question is: in older JDK's there was something called JCov which > enhanced byte code with additional information regarding which > statements finally led to a/multiple bytecode instruction(s). I > stumbled upon this while debugging javac when I wanted to learn it's > design/code. I think it's mostly what I need - however the JCov switch > is a hidden feature. It was "more" public in JDK 1.2 and was pretended > to have been ported to the JVMPI interface later. However I did not > find where the port should have been integrated - I'm no JVMPI (and > JVMTI) guru. Honestly I doubt that something similar is in the > JVM(P/T)I toolset... > > So perhaps someone has more knowledge about JCov and what happened to > it. Furthermore I'd like to push a discussion on whether this would be > a candidate for the kitchen sink (no JLS changes, just internal) with > the goal to implement the above described functionality *including a > supported and public interface* (not a hidden feature anymore). The > first benefit could then obviously be that javac could be mutation > tested ;) Furthermore other Java developers would have solid > information and documentation about this API instead of relying on > mostly unknown and hidden features. > > Best Regards, > > Alex > From alex at retroduction.org Mon Apr 21 10:07:08 2008 From: alex at retroduction.org (Alex Rau) Date: Mon, 21 Apr 2008 19:07:08 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> <48069657.6050307@sun.com> <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> Message-ID: Here's a patch which enables the compiler to generate trace information. By using -Xtrace as compiler argument the compiler generates .trace files beside the .class files. A trace file consists of n Integer tupel < trace serial id, source code offset start, source code offset end> with fields (standard java) big-endian encoding. The trace serial ids are referenced in the byte code of each class in an attribute TraceID ( embedded in the code attribute of every method). This patch provides functional tests except for adding the attribute in the class file (difficult to test). I have to very the latter that it works as it should and/or find a way to test that. However it should be sufficient to discuss the implementation. As soon as the patch is acceptable I'll submit the SCA. Some implementation comments: - the current encoding of the trace files are *not* ASCII files as I initially said to workaround the open question how Integer's should be represented in ASCII (fixed length vs. variable length with field separators) - the output is written by a separate TraceWriter class beside ClassWriter. I think in general this is fine, however TraceWriter and ClassWriter both are more coupled to CRTable than I like. I think CRTable knows a little bit too much about representation in class and trace files - existing JCov stuff is mostly untouched and reused for creating the trace files Best Regards, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: tracepatch.diff Type: application/octet-stream Size: 80348 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080421/dff9f6b6/tracepatch.diff -------------- next part -------------- PS: to be applied in ./langtools/ with patch -p1 < tracepatch.diff On 19.04.2008, at 20:34, John Rose wrote: > On Apr 19, 2008, at 4:27 AM, Alex Rau wrote: >> what John meant with token serial numbers > > Serial = sequentially assigned. For some definition of token, > first token in file gets serial number 1, second gets 2, etc. If > complete file has N tokens, last token serial number is N. It's > almost the same as byte offset, just (a) more compact and (b) more > stable under semantically null edits. FWIW. > > Use byte offsets for simplicity! > > -- John From Robert.Field at Sun.COM Mon Apr 21 15:16:37 2008 From: Robert.Field at Sun.COM (Robert Field) Date: Mon, 21 Apr 2008 15:16:37 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <480CF978.8070000@Sun.COM> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480CF978.8070000@Sun.COM> Message-ID: <480D1245.2060008@Sun.com> I ported JCov to java.lang.instrument (a fully Java API) not to JVM TI (a native API). And it is now in active use internal to Sun. There were plans to make it open source, but I haven't heard anything about this being done -- though I don't track the project anymore. I terms of character position, this is something that has been actively requested for years -- it would need to be implemented by javac. This is needed for tools like debuggers, profilers, coverage analysis, etc. But it such an interface has not been formally defined. javac does have or did have an unofficial mode for generating character position info (for JCov, as you mention), but I am not familiar with it or its status. Compiler folk... -Robert Uday Dhanikonda wrote: > Alex > > There was an effort by Robert recently to rewrite JCov using JVM TI. > > Robert can you comment on this. > > Thanks > Uday > > Alex Rau wrote: >> Hi all, >> >> I've searched the web and asked at forum.sun.com but my answer >> regarding the javac compiler couldn't be answered yet. so here we go >> with a rational first: >> >> Rational: I'd like to achieve the following: The byte code created >> with javac should not only contain line number information in debug >> mode, but additionally I want to track exactly which statement >> (including column information as there can be multiple statements in >> one source code line) leads to a certain bytecode instruction or a >> set of instructions. I strongly need this kind of functionality in >> javac as the project I'm working on is settled in the testing area >> (mutation testing in java on bytecode level which you can imagine as >> some kind of (beta) code coverage software with a different and IMHO >> superior technique - http://retroduction.org for more details if you >> are interested). The software must be able to report mutated >> *statements* which means that line informations are insufficient. >> >> My Question is: in older JDK's there was something called JCov which >> enhanced byte code with additional information regarding which >> statements finally led to a/multiple bytecode instruction(s). I >> stumbled upon this while debugging javac when I wanted to learn it's >> design/code. I think it's mostly what I need - however the JCov >> switch is a hidden feature. It was "more" public in JDK 1.2 and was >> pretended to have been ported to the JVMPI interface later. However I >> did not find where the port should have been integrated - I'm no >> JVMPI (and JVMTI) guru. Honestly I doubt that something similar is in >> the JVM(P/T)I toolset... >> >> So perhaps someone has more knowledge about JCov and what happened to >> it. Furthermore I'd like to push a discussion on whether this would >> be a candidate for the kitchen sink (no JLS changes, just internal) >> with the goal to implement the above described functionality >> *including a supported and public interface* (not a hidden feature >> anymore). The first benefit could then obviously be that javac could >> be mutation tested ;) Furthermore other Java developers would have >> solid information and documentation about this API instead of relying >> on mostly unknown and hidden features. >> >> Best Regards, >> >> Alex >> > From alex at retroduction.org Tue Apr 22 04:04:43 2008 From: alex at retroduction.org (Alex Rau) Date: Tue, 22 Apr 2008 13:04:43 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future In-Reply-To: <480D1245.2060008@Sun.com> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480CF978.8070000@Sun.COM> <480D1245.2060008@Sun.com> Message-ID: <95B371CF-DF8E-4985-9E6B-C0113BCC0AD9@retroduction.org> On 22.04.2008, at 00:16, Robert Field wrote: > I ported JCov to java.lang.instrument (a fully Java API) not to JVM > TI (a native API). And it is now in active use internal to Sun. > There were plans to make it open source, but I haven't heard > anything about this being done -- though I don't track the project > anymore. > > I terms of character position, this is something that has been > actively requested for years -- it would need to be implemented by > javac. This is needed for tools like debuggers, profilers, > coverage analysis, etc. But it such an interface has not been > formally defined. javac does have or did have an unofficial mode > for generating character position info (for JCov, as you mention), > but I am not familiar with it or its status. Compiler folk... > > -Robert > Thanks for clarification ! That underlines my impression that the character position related stuff embedded in the existing "JCov" implementation is *not* superseded by any JVMTI (or as you said java.lang.instrument) port and that getting character positions for post-compilation tools is a useful feature. My patch sent to compiler-dev at openjdk.java.net yesterday provides a basic interface for making character positions in a simple format accessible to "user-space". Best regards, Alex > > Uday Dhanikonda wrote: >> Alex >> >> There was an effort by Robert recently to rewrite JCov using JVM TI. >> >> Robert can you comment on this. >> >> Thanks >> Uday >> From eamonn.mcmanus at sun.com Tue Apr 22 09:59:41 2008 From: eamonn.mcmanus at sun.com (eamonn.mcmanus at sun.com) Date: Tue, 22 Apr 2008 16:59:41 +0000 Subject: hg: jdk7/tl/jdk: 6692027: Custom subclasses of QueryEval don't serialize Message-ID: <20080422165957.B51CE27100@hg.openjdk.java.net> Changeset: 92ea0ac77d2f Author: emcmanus Date: 2008-04-22 18:58 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92ea0ac77d2f 6692027: Custom subclasses of QueryEval don't serialize Summary: Remove non-public superclass of QueryEval Reviewed-by: dfuchs ! src/share/classes/javax/management/AndQueryExp.java ! src/share/classes/javax/management/BetweenQueryExp.java ! src/share/classes/javax/management/BinaryRelQueryExp.java ! src/share/classes/javax/management/NotQueryExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/OrQueryExp.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/QueryEval.java + test/javax/management/query/CustomQueryTest.java From alex at retroduction.org Wed Apr 23 03:19:27 2008 From: alex at retroduction.org (Alex Rau) Date: Wed, 23 Apr 2008 12:19:27 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> <48069657.6050307@sun.com> <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> Message-ID: The patch sent 2 days ago was not sane (some changes were not diffed correctly). Here's a corrected patch. Regards Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: tracepatch.diff Type: application/octet-stream Size: 35203 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080423/88e46bf2/tracepatch.diff -------------- next part -------------- On 21.04.2008, at 19:07, Alex Rau wrote: > Here's a patch which enables the compiler to generate trace > information. By using -Xtrace as compiler argument the compiler > generates .trace files beside the .class files. A trace file > consists of n Integer tupel < trace serial id, source code offset > start, source code offset end> with fields (standard java) big- > endian encoding. The trace serial ids are referenced in the byte > code of each class in an attribute TraceID ( embedded in the code > attribute of every method). This patch provides functional tests > except for adding the attribute in the class file (difficult to > test). I have to very the latter that it works as it should and/or > find a way to test that. > > However it should be sufficient to discuss the implementation. As > soon as the patch is acceptable I'll submit the SCA. > > Some implementation comments: > > - the current encoding of the trace files are *not* ASCII files as > I initially said to workaround the open question how Integer's > should be represented in ASCII (fixed length vs. variable length > with field separators) > - the output is written by a separate TraceWriter class beside > ClassWriter. I think in general this is fine, however TraceWriter > and ClassWriter both are more coupled to CRTable than I like. I > think CRTable knows a little bit too much about representation in > class and trace files > - existing JCov stuff is mostly untouched and reused for creating > the trace files > > Best Regards, > > Alex > > > > PS: to be applied in ./langtools/ with patch -p1 < tracepatch.diff > > > > On 19.04.2008, at 20:34, John Rose wrote: > >> On Apr 19, 2008, at 4:27 AM, Alex Rau wrote: >>> what John meant with token serial numbers >> >> Serial = sequentially assigned. For some definition of token, >> first token in file gets serial number 1, second gets 2, etc. If >> complete file has N tokens, last token serial number is N. It's >> almost the same as byte offset, just (a) more compact and (b) more >> stable under semantically null edits. FWIW. >> >> Use byte offsets for simplicity! >> >> -- John > From Jonathan.Gibbons at Sun.COM Wed Apr 23 08:17:31 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 23 Apr 2008 08:17:31 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> <48069657.6050307@sun.com> <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> Message-ID: <474814F9-ADFB-454B-BCAB-9669414B4F27@sun.com> Alex, >>> However it should be sufficient to discuss the implementation. As >>> soon as the patch is acceptable I'll submit the SCA. I'm sorry, it doesn't work that way. For legal reasons, we cannot look at your patch until you have signed the SCA. Separately, although the work sounds like it has potential, I don't think it is appropriate to consider it for submission at this time. You are proposing adding a new output file format for the compiler, which is a step that should not be undertaken lightly. I'm not saying it needs anything as big as a JSR, but the file format should at least go through some sort of design review by the likely consumers of such a file. If nothing else, the Serviceability team should be involved, so that other JDK tools which might want to use the file are considered. I've started a thread on serviceability-dev for anyone interested. -- Jon On Apr 23, 2008, at 3:19 AM, Alex Rau wrote: > The patch sent 2 days ago was not sane (some changes were not diffed > correctly). Here's a corrected patch. > > Regards Alex > > On 21.04.2008, at 19:07, Alex Rau wrote: > >> Here's a patch which enables the compiler to generate trace >> information. By using -Xtrace as compiler argument the compiler >> generates .trace files beside the .class files. A trace file >> consists of n Integer tupel < trace serial id, source code offset >> start, source code offset end> with fields (standard java) big- >> endian encoding. The trace serial ids are referenced in the byte >> code of each class in an attribute TraceID ( embedded in the code >> attribute of every method). This patch provides functional tests >> except for adding the attribute in the class file (difficult to >> test). I have to very the latter that it works as it should and/or >> find a way to test that. >> >> However it should be sufficient to discuss the implementation. As >> soon as the patch is acceptable I'll submit the SCA. >> >> Some implementation comments: >> >> - the current encoding of the trace files are *not* ASCII files as >> I initially said to workaround the open question how Integer's >> should be represented in ASCII (fixed length vs. variable length >> with field separators) >> - the output is written by a separate TraceWriter class beside >> ClassWriter. I think in general this is fine, however TraceWriter >> and ClassWriter both are more coupled to CRTable than I like. I >> think CRTable knows a little bit too much about representation in >> class and trace files >> - existing JCov stuff is mostly untouched and reused for creating >> the trace files >> >> Best Regards, >> >> Alex >> >> >> >> PS: to be applied in ./langtools/ with patch -p1 < tracepatch.diff >> >> >> >> On 19.04.2008, at 20:34, John Rose wrote: >> >>> On Apr 19, 2008, at 4:27 AM, Alex Rau wrote: >>>> what John meant with token serial numbers >>> >>> Serial = sequentially assigned. For some definition of token, >>> first token in file gets serial number 1, second gets 2, etc. If >>> complete file has N tokens, last token serial number is N. It's >>> almost the same as byte offset, just (a) more compact and (b) more >>> stable under semantically null edits. FWIW. >>> >>> Use byte offsets for simplicity! >>> >>> -- John >> > From alex at retroduction.org Wed Apr 23 08:49:07 2008 From: alex at retroduction.org (Alex Rau) Date: Wed, 23 Apr 2008 17:49:07 +0200 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: <474814F9-ADFB-454B-BCAB-9669414B4F27@sun.com> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> <48069657.6050307@sun.com> <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> <474814F9-ADFB-454B-BCAB-9669414B4F27@sun.com> Message-ID: <2CAE4C54-B531-4199-B564-380A435EA746@retroduction.org> On 23.04.2008, at 17:17, Jonathan Gibbons wrote: > Alex, > >>>> However it should be sufficient to discuss the implementation. >>>> As soon as the patch is acceptable I'll submit the SCA. > > > I'm sorry, it doesn't work that way. For legal reasons, we cannot > look at your patch until you have signed the SCA. > I've submitted the SCA yesterday via Fax (sorry, forgot to mention). > Separately, although the work sounds like it has potential, I don't > think it is appropriate to consider it for submission at this time. > You are proposing adding a new output file format for the compiler, > which is a step that should not be undertaken lightly. I'm not > saying it needs anything as big as a JSR, but the file format > should at least go through some sort of design review by the likely > consumers of such a file. If nothing else, the Serviceability team > should be involved, so that other JDK tools which might want to use > the file are considered. > > I've started a thread on serviceability-dev for anyone interested. > > -- Jon > > I'm aware of that and I think you are totally right. My intention with the patch was more kind of "proof-of-concept" and idea brainstorming how the feature could be implemented - especially as I agree with you that a formal specification/discussion basis like a dedicated JSR would probably be overkill. This (the patch) seemed to me a "more" appropriate way of talking (or at least getting started talking) about the "same thing". Please just consider it as a prototype which has nothing to do with the final implementation nor it was intended to be targeted for "submission and final integration" ( although I must admit that I am not familiar yet with the official submission process). Best Regards, Alex PS: Thanks for getting more people involved From Jonathan.Gibbons at Sun.COM Wed Apr 23 09:05:52 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 23 Apr 2008 09:05:52 -0700 Subject: Bytecode generation, Source code mappings, JCov, Future (Patch) In-Reply-To: <2CAE4C54-B531-4199-B564-380A435EA746@retroduction.org> References: <347FD74C-CE89-44CC-A9CB-545A0F877F60@retroduction.org> <480679B6.50808@sun.com> <8A670798-DF7A-439E-A0D4-06593CDF81A8@retroduction.org> <48069657.6050307@sun.com> <5F46F7B3-B75B-4A7B-A7E4-9B8E1C9C0AB0@retroduction.org> <474814F9-ADFB-454B-BCAB-9669414B4F27@sun.com> <2CAE4C54-B531-4199-B564-380A435EA746@retroduction.org> Message-ID: <543A4FFC-0C43-464D-9839-C056EC5CE105@Sun.COM> Alex, As a prototype, you could also create a project on dev.java.net and publish your work there, for people to try out and evaluate. We could link to your project from the OpenJDK compiler pages as well, if you wanted. If you start getting more traction with the idea in OpenJDK, it may be appropriate to create an OpenJDK project for the work. OpenJDK projects have to be sponsored by OpenJDK groups, and right now, my sense is that this work is a better fit for the Serviceability group, if they're interested. See http://openjdk.java.net/groups/serviceability/ for info on what they cover. If they were interested, the compiler team would obviously still be involved to deliver any necessary information from javac. -- Jon On Apr 23, 2008, at 8:49 AM, Alex Rau wrote: > > On 23.04.2008, at 17:17, Jonathan Gibbons wrote: > >> Alex, >> >>>>> However it should be sufficient to discuss the implementation. >>>>> As soon as the patch is acceptable I'll submit the SCA. >> >> >> I'm sorry, it doesn't work that way. For legal reasons, we cannot >> look at your patch until you have signed the SCA. >> > > I've submitted the SCA yesterday via Fax (sorry, forgot to mention). > >> Separately, although the work sounds like it has potential, I don't >> think it is appropriate to consider it for submission at this time. >> You are proposing adding a new output file format for the compiler, >> which is a step that should not be undertaken lightly. I'm not >> saying it needs anything as big as a JSR, but the file format >> should at least go through some sort of design review by the likely >> consumers of such a file. If nothing else, the Serviceability team >> should be involved, so that other JDK tools which might want to use >> the file are considered. >> >> I've started a thread on serviceability-dev for anyone interested. >> >> -- Jon >> >> > > I'm aware of that and I think you are totally right. My intention > with the patch was more kind of "proof-of-concept" and idea > brainstorming how the feature could be implemented - especially as I > agree with you that a formal specification/discussion basis like a > dedicated JSR would probably be overkill. This (the patch) seemed to > me a "more" appropriate way of talking (or at least getting started > talking) about the "same thing". Please just consider it as a > prototype which has nothing to do with the final implementation nor > it was intended to be targeted for "submission and final > integration" ( although I must admit that I am not familiar yet with > the official submission process). > > Best Regards, > > Alex > > PS: Thanks for getting more people involved > > From maurizio.cimadamore at sun.com Wed Apr 23 09:11:11 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 23 Apr 2008 16:11:11 +0000 Subject: hg: jdk7/tl/langtools: 6682380: Foreach loop with generics inside finally block crashes javac with -target 1.5 Message-ID: <20080423161112.B119D27376@hg.openjdk.java.net> Changeset: ec29a1a284ca Author: mcimadamore Date: 2008-04-23 17:10 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ec29a1a284ca 6682380: Foreach loop with generics inside finally block crashes javac with -target 1.5 Summary: A missing type-erasure in Lower.java causes the compiler to crash since JDK6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/foreach/T6682380.java