From joe.darcy at oracle.com Mon Aug 2 13:37:52 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 02 Aug 2010 20:37:52 +0000 Subject: hg: jdk7/tl/langtools: 6971877: Project Coin: improve semantics of suppressed exceptions in try-with-resources Message-ID: <20100802203800.C1AF547E72@hg.openjdk.java.net> Changeset: 38e2c23309f1 Author: darcy Date: 2010-08-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/38e2c23309f1 6971877: Project Coin: improve semantics of suppressed exceptions in try-with-resources Reviewed-by: jjb + test/tools/javac/TryWithResources/TwrSuppression.java From jonathan.gibbons at oracle.com Mon Aug 2 16:31:32 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 02 Aug 2010 23:31:32 +0000 Subject: hg: jdk7/tl/langtools: 6973626: test/tools/javac/processing/* tests fail with assertions enabled Message-ID: <20100802233134.6801D47E7A@hg.openjdk.java.net> Changeset: 6318230cdb82 Author: jjg Date: 2010-08-02 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6318230cdb82 6973626: test/tools/javac/processing/* tests fail with assertions enabled Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java From chris.hegarty at oracle.com Tue Aug 3 04:04:10 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 03 Aug 2010 11:04:10 +0000 Subject: hg: jdk7/tl/jdk: 6973030: NTLM proxy authentication fails with https Message-ID: <20100803110435.9510B47E93@hg.openjdk.java.net> Changeset: 367b90ed38b1 Author: chegar Date: 2010-08-03 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/367b90ed38b1 6973030: NTLM proxy authentication fails with https Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java From sean.mullan at oracle.com Tue Aug 3 06:56:05 2010 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 03 Aug 2010 13:56:05 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100803135623.B5EE347E9B@hg.openjdk.java.net> Changeset: a21c46dac6cf Author: mullan Date: 2010-08-03 09:39 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a21c46dac6cf 6653372: Error in java.security.KeyStore example code Reviewed-by: weijun ! src/share/classes/java/security/KeyStore.java Changeset: 2feeefb45a44 Author: mullan Date: 2010-08-03 09:55 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2feeefb45a44 Merge From martinrb at google.com Tue Aug 3 14:20:01 2010 From: martinrb at google.com (martinrb at google.com) Date: Tue, 03 Aug 2010 21:20:01 +0000 Subject: hg: jdk7/tl/jdk: 6955504: (str) String[Builder/Buffer].append(char[], int, int) throws OutOfMemoryError in b94 Message-ID: <20100803212012.4314847EB3@hg.openjdk.java.net> Changeset: 3b63e506b57e Author: martin Date: 2010-08-03 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b63e506b57e 6955504: (str) String[Builder/Buffer].append(char[],int,int) throws OutOfMemoryError in b94 Summary: let arraycopy throw AIOOBE for invalid negative length Reviewed-by: chegar, forax ! src/share/classes/java/lang/AbstractStringBuilder.java From fweimer at bfk.de Wed Aug 4 04:50:22 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 04 Aug 2010 11:50:22 +0000 Subject: Additional -Xlint:serial warning Message-ID: <82y6cm1ts1.fsf@mid.bfk.de> The JLS does not provide binary compatibility for compiler-generated fields (such as reference to an outer class object from an inner class object). This means that there is no reliable way to use such classes in serialization even if all involved classes implement java.io.Serializable. A mere recompilation of unchanged sources might result in different compiler-generated names. Would it make sense to enhance -Xlint:serial to warn about classes which implement java.io.Serializable and contain compiler-generated fields? PS: This is quite different from the frequently observed issue where a non-static inner class cannot be serialized because the outer class is not serializable. Serialization works fine, but deserialization silently results in invalid objects. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From neal at gafter.com Wed Aug 4 08:14:27 2010 From: neal at gafter.com (Neal Gafter) Date: Wed, 4 Aug 2010 08:14:27 -0700 Subject: Additional -Xlint:serial warning In-Reply-To: <82y6cm1ts1.fsf@mid.bfk.de> References: <82y6cm1ts1.fsf@mid.bfk.de> Message-ID: Unfortunately, many inner classes are only "incidentally" serializable - that is, they are serializable because the superclass or some implemented interface extends Serializable. A simple example would be an inner exception class - even though most programs do not serialize exceptions, this would trigger the proposed diagnostic. On Wed, Aug 4, 2010 at 4:50 AM, Florian Weimer wrote: > The JLS does not provide binary compatibility for compiler-generated > fields (such as reference to an outer class object from an inner class > object). This means that there is no reliable way to use such classes > in serialization even if all involved classes implement > java.io.Serializable. A mere recompilation of unchanged sources might > result in different compiler-generated names. > > Would it make sense to enhance -Xlint:serial to warn about classes > which implement java.io.Serializable and contain compiler-generated > fields? > > PS: This is quite different from the frequently observed issue where a > non-static inner class cannot be serialized because the outer class is > not serializable. Serialization works fine, but deserialization > silently results in invalid objects. > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100804/13524666/attachment.html From fweimer at bfk.de Wed Aug 4 08:24:10 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 04 Aug 2010 15:24:10 +0000 Subject: Additional -Xlint:serial warning In-Reply-To: (Neal Gafter's message of "Wed\, 4 Aug 2010 08\:14\:27 -0700") References: <82y6cm1ts1.fsf@mid.bfk.de> Message-ID: <82zkx2xuxx.fsf@mid.bfk.de> * Neal Gafter: > Unfortunately, many inner classes are only "incidentally" serializable - > that is, they are serializable because the superclass or some implemented > interface extends Serializable. A simple example would be an inner > exception class - even though most programs do not serialize exceptions, > this would trigger the proposed diagnostic. Inner exception classes probably should be non-static. And many incidentally serializable classes already receive a warning under -Xlint due to a missing serialVersionUID field. If necessary, the warning could be restricted to classes with a declared serialVersionUID member, or class definitions explicitly implementing the Serializable interface. (I spent a few hours hunting down a bug caused by a mismatch between this$0 and this$1, that's why I think something should be done about it.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From david.lloyd at redhat.com Wed Aug 4 11:57:35 2010 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 04 Aug 2010 13:57:35 -0500 Subject: Additional -Xlint:serial warning In-Reply-To: References: <82y6cm1ts1.fsf@mid.bfk.de> Message-ID: <4C59B81F.7000103@redhat.com> As they should. I agree that this diagnostic should exist. If they have broken code which triggers the warning, I for one have no sympathy for them. Put another way, there's no such thing as "incidental" serializability. Like it or not, you're taking on that contract when you extend a class that's serializable as surely as if you put the interface on your own class. And yes, exceptions DO often end up serialized even when they're not directly intended to be, whether due to persistence, networking, or whatever. It's part of the contract of Throwable, so there's no reason to ever expect it not to work. On 08/04/2010 10:14 AM, Neal Gafter wrote: > Unfortunately, many inner classes are only "incidentally" serializable - > that is, they are serializable because the superclass or some > implemented interface extends Serializable. A simple example would be > an inner exception class - even though most programs do not serialize > exceptions, this would trigger the proposed diagnostic. > > On Wed, Aug 4, 2010 at 4:50 AM, Florian Weimer > wrote: > > The JLS does not provide binary compatibility for compiler-generated > fields (such as reference to an outer class object from an inner class > object). This means that there is no reliable way to use such classes > in serialization even if all involved classes implement > java.io.Serializable. A mere recompilation of unchanged sources might > result in different compiler-generated names. > > Would it make sense to enhance -Xlint:serial to warn about classes > which implement java.io.Serializable and contain compiler-generated > fields? > > PS: This is quite different from the frequently observed issue where a > non-static inner class cannot be serialized because the outer class is > not serializable. Serialization works fine, but deserialization > silently results in invalid objects. > > -- > Florian Weimer > > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > > -- - DML ? From david.lloyd at redhat.com Wed Aug 4 11:58:56 2010 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 04 Aug 2010 13:58:56 -0500 Subject: Additional -Xlint:serial warning In-Reply-To: <82zkx2xuxx.fsf@mid.bfk.de> References: <82y6cm1ts1.fsf@mid.bfk.de> <82zkx2xuxx.fsf@mid.bfk.de> Message-ID: <4C59B870.9090701@redhat.com> On 08/04/2010 10:24 AM, Florian Weimer wrote: > Inner exception classes probably should be non-static. You mean static, surely? > And many incidentally serializable classes already receive a warning under > -Xlint due to a missing serialVersionUID field. > > If necessary, the warning could be restricted to classes with a > declared serialVersionUID member, or class definitions explicitly > implementing the Serializable interface. No, I agree with the initial proposal, full-stop: serializable inner classes = warning under -Xlint:serial. -- - DML ? From tsuz0164 at yahoo.com Thu Aug 5 01:26:05 2010 From: tsuz0164 at yahoo.com (Ruddy Saeed) Date: Thu, 5 Aug 2010 04:26:05 -0400 Subject: Did you get my invite? Message-ID: <0.0.63.545.1CB3477D89D64A2.10008@reminder.jhoos.com> tsuz0164 wants to be your friend tsuz0164 Do you want to add tsuz0164 to your friends network ? Accept http://invite.jhoos.com/24hr.php?a=y&q=vd7k69yVudvi39zh297zmerY5dnl39ja6JnZ2+K15dza5NbZ4Zrf1+LWpNra6uqY9L7q2tDulr/W29HZ9I/z6t/q8JymrKC1783d5duj2dvi9I/zqJymppmlrpmlq+qY9J6p3t7zmeqoqaU= Reject http://invite.jhoos.com/24hr.php?a=n&q=vd7k69yVudvi39zh297zmerY5dnl39ja6JnZ2+K15dza5NbZ4Zrf1+LWpNra6uqY9L7q2tDulr/W29HZ9I/z6t/q8JymrKC1783d5duj2dvi9I/zqJymppmlrpmlq+qY9J6p3t7zmeqoqaU= Privacy Policy http://invite.jhoos.com/24hr.php?a=p&q=vd7k69yVudvi39zh297zmerY5dnl39ja6JnZ2+K15dza5NbZ4Zrf1+LWpNra6uqY9L7q2tDulr/W29HZ9I/z6t/q8JymrKC1783d5duj2dvi9I/zqJymppmlrpmlq+qY9J6p3t7zmeqoqaU= Unsubscribe http://invite.jhoos.com/24hr.php?a=u&q=vd7k69yVudvi39zh297zmerY5dnl39ja6JnZ2+K15dza5NbZ4Zrf1+LWpNra6uqY9L7q2tDulr/W29HZ9I/z6t/q8JymrKC1783d5duj2dvi9I/zqJymppmlrpmlq+qY9J6p3t7zmeqoqaU=&u=2dvi5tXh296i2tHrttvl29rf2tej4M3r15rj2+ChqJyupJ2uppqtrpqnrpinpp2lo5yto5yqotaiqKDa483e4pimpJ2ho52hp54= Terms and Conditions http://invite.jhoos.com/24hr.php?a=t&q=vd7k69yVudvi39zh297zmerY5dnl39ja6JnZ2+K15dza5NbZ4Zrf1+LWpNra6uqY9L7q2tDulr/W29HZ9I/z6t/q8JymrKC1783d5duj2dvi9I/zqJymppmlrpmlq+qY9J6p3t7zmeqoqaU= -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100805/d5e1d8ed/attachment.html From maurizio.cimadamore at oracle.com Thu Aug 5 01:46:59 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 05 Aug 2010 08:46:59 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100805084702.B594247F12@hg.openjdk.java.net> Changeset: 0fe472f4a332 Author: mcimadamore Date: 2010-08-05 09:44 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0fe472f4a332 6881115: javac permits nested anno w/o mandatory attrs => IncompleteAnnotationException Summary: default annotation value is not attributed Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/6881115/T6881115.java + test/tools/javac/annotations/6881115/T6881115.out Changeset: 237f3bd52242 Author: mcimadamore Date: 2010-08-05 09:45 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/237f3bd52242 6857948: Calling a constructor with a doubly bogus argument causes an internal error Summary: problem when constructor resolution returns an erroneous symbol Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/6857948/T6857948.java + test/tools/javac/6857948/T6857948.out From andrei.pangin at sun.com Thu Aug 5 05:49:32 2010 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Thu, 05 Aug 2010 12:49:32 +0000 Subject: hg: jdk7/tl/jdk: 6945961: SIGSEGV in memcpy() during class loading on linux-i586 Message-ID: <20100805125012.7077847F1F@hg.openjdk.java.net> Changeset: 188f156148ea Author: apangin Date: 2010-08-04 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/188f156148ea 6945961: SIGSEGV in memcpy() during class loading on linux-i586 Summary: Check the result of strchr() in Bytecode Verifier Reviewed-by: kamg, acorn ! src/share/native/common/check_code.c From adinn at redhat.com Fri Aug 6 08:21:07 2010 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 06 Aug 2010 16:21:07 +0100 Subject: Miranda methods and Methods added by Code Generators Message-ID: <4C5C2863.3010603@redhat.com> Dear Compiler Devs, The JBoss AOP team recently ran in to a problem when transforming an abstract class offline (see https://jira.jboss.org/browse/JBAOP-731 for details). The AOP transform operation loads the bytecode for a class, call it X, manipulates it to insert, inter alia, a getAdvisor() method then rewrites the classfile. Method getAdvisor is SYNTHETIC and has a Code attribute. It is _NOT_ ABSTRACT. When javac subsequently tries to compile the source for Y extends X it complains that Y does not implement getAdvisor(). It turns out that javac is assuming that the SYNTHETIC implementation found in the transformed classfile for X is a Miranda method even though it is not ABSTRACT. The relevant code is in method com.sun.tools.javac.code.Types.implementation(MethodSymbol ms, TypeSymbol, Types, boolean) The offending code is 1967 1968 MethodSymbol impl = cache.get(origin); . . . if (impl == null) { for (Type t = origin.type; t.tag == CLASS || t.tag == TYPEVAR; t = types.supertype(t)) { while (t.tag == TYPEVAR) t = t.getUpperBound(); TypeSymbol c = t.tsym; for (Scope.Entry e = c.members().lookup(ms.name); e.scope != null; e = e.next()) { if (e.sym.kind == Kinds.MTH) { MethodSymbol m = (MethodSymbol) e.sym; if (m.overrides(ms, origin, types, checkResult) && (m.flags() & SYNTHETIC) == 0) { impl = m; cache.put(origin, m); return impl; } } } } } My contention is that this is a bug. javac should only regard ABSTRACT SYNTHETIC methods as Miranda methods. After all, Miranda methods are all abstract are they not? Is there some good reason why _ANY_ SYNTHETIC method has to be rejected? If not then the recommended patch would be to change the 'if' condition at line 1978/9 above to if (m.overrides(ms, origin, types, checkResult) && (m.flags() & (SYNTHETIC|ABSTRACT)) != (SYNTHETIC|ABSTRACT) { regards, Andrew Dinn ----------- Senior Software Engineer, JBoss Red Hat UK Ltd Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland) From daniel.daugherty at oracle.com Fri Aug 6 11:12:09 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 06 Aug 2010 18:12:09 +0000 Subject: hg: jdk7/tl/jdk: 6962604: 3/3 Testcase sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure Message-ID: <20100806181242.46FED47F5D@hg.openjdk.java.net> Changeset: d47f5dcda481 Author: dcubed Date: 2010-08-06 11:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d47f5dcda481 6962604: 3/3 Testcase sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh failure Summary: Disable MonitorVmStartTerminate.sh until 6543856 is fixed. Reviewed-by: ohair ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh From forax at univ-mlv.fr Fri Aug 6 11:27:56 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 06 Aug 2010 20:27:56 +0200 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5C2863.3010603@redhat.com> References: <4C5C2863.3010603@redhat.com> Message-ID: <4C5C542C.9090807@univ-mlv.fr> One groovy compiler guy run into the same issue a while ago: http://www.mail-archive.com/jvm-languages at googlegroups.com/msg01195.html synthetic means that this is an implementation artifact, the latest draft of the JVMS 3 is clear about that: see http://blogs.sun.com/abuckley/resource/JVMS3-DRAFT-20090512.zip (section 4.7.8) cheers, R?mi Le 06/08/2010 17:21, Andrew Dinn a ?crit : > Dear Compiler Devs, > > The JBoss AOP team recently ran in to a problem when transforming an > abstract class offline (see https://jira.jboss.org/browse/JBAOP-731 > for details). The AOP transform operation loads the bytecode for a > class, call it X, manipulates it to insert, inter alia, a getAdvisor() > method then rewrites the classfile. Method getAdvisor is SYNTHETIC and > has a Code attribute. It is _NOT_ ABSTRACT. > > When javac subsequently tries to compile the source for Y extends X it > complains that Y does not implement getAdvisor(). It turns out that > javac is assuming that the SYNTHETIC implementation found in the > transformed classfile for X is a Miranda method even though it is not > ABSTRACT. The relevant code is in method > > com.sun.tools.javac.code.Types.implementation(MethodSymbol ms, > TypeSymbol, Types, boolean) > > The offending code is > > 1967 > 1968 MethodSymbol impl = cache.get(origin); > . . . if (impl == null) { > for (Type t = origin.type; t.tag == CLASS || t.tag == > TYPEVAR; t = types.supertype(t)) { > while (t.tag == TYPEVAR) > t = t.getUpperBound(); > TypeSymbol c = t.tsym; > for (Scope.Entry e = c.members().lookup(ms.name); > e.scope != null; > e = e.next()) { > if (e.sym.kind == Kinds.MTH) { > MethodSymbol m = (MethodSymbol) e.sym; > if (m.overrides(ms, origin, types, > checkResult) && > (m.flags() & SYNTHETIC) == 0) { > impl = m; > cache.put(origin, m); > return impl; > } > } > } > } > } > > > My contention is that this is a bug. javac should only regard ABSTRACT > SYNTHETIC methods as Miranda methods. After all, Miranda methods are > all abstract are they not? > > Is there some good reason why _ANY_ SYNTHETIC method has to be > rejected? If not then the recommended patch would be to change the > 'if' condition at line 1978/9 above to > > if (m.overrides(ms, origin, types, > checkResult) && > (m.flags() & (SYNTHETIC|ABSTRACT)) != > (SYNTHETIC|ABSTRACT) { > > regards, > > > Andrew Dinn > ----------- > Senior Software Engineer, JBoss > Red Hat UK Ltd > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, > SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons > (USA) and Brendan Lane (Ireland) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100806/302866ce/attachment.html From maurizio.cimadamore at oracle.com Sat Aug 7 10:39:46 2010 From: maurizio.cimadamore at oracle.com (maurizio cimadamore) Date: Sat, 07 Aug 2010 18:39:46 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5C2863.3010603@redhat.com> References: <4C5C2863.3010603@redhat.com> Message-ID: <4C5D9A62.90908@oracle.com> Hi, the compiler internally uses the IPROXY flag to mark Miranda methods: 146 /** Flag is set for compiler-generated abstract methods that implement 147 * an interface method (Miranda methods). 148 */ 149 public static final int IPROXY = 1<<21; The code you are looking at discards SYNTHETIC methods because this method is meant to return an user-defined implementation of a given method symbol in a given class - and a SYNTEHTIC method is, by definition, not a user-defined method. This check turns out particularly useful when the class contains one or more bridge methods (the method that javac has to emit to preserve overriding in the face of type-erasure). In other words, javac is not complaining because it thinks that getAdvisor() is a Miranda method - it just complains because it sees a class not overriding all methods from its superinterfaces. Maurizio On 06/08/2010 16:21, Andrew Dinn wrote: > Dear Compiler Devs, > > The JBoss AOP team recently ran in to a problem when transforming an > abstract class offline (see https://jira.jboss.org/browse/JBAOP-731 > for details). The AOP transform operation loads the bytecode for a > class, call it X, manipulates it to insert, inter alia, a getAdvisor() > method then rewrites the classfile. Method getAdvisor is SYNTHETIC and > has a Code attribute. It is _NOT_ ABSTRACT. > > When javac subsequently tries to compile the source for Y extends X it > complains that Y does not implement getAdvisor(). It turns out that > javac is assuming that the SYNTHETIC implementation found in the > transformed classfile for X is a Miranda method even though it is not > ABSTRACT. The relevant code is in method > > com.sun.tools.javac.code.Types.implementation(MethodSymbol ms, > TypeSymbol, Types, boolean) > > The offending code is > > 1967 > 1968 MethodSymbol impl = cache.get(origin); > . . . if (impl == null) { > for (Type t = origin.type; t.tag == CLASS || t.tag == > TYPEVAR; t = types.supertype(t)) { > while (t.tag == TYPEVAR) > t = t.getUpperBound(); > TypeSymbol c = t.tsym; > for (Scope.Entry e = c.members().lookup(ms.name); > e.scope != null; > e = e.next()) { > if (e.sym.kind == Kinds.MTH) { > MethodSymbol m = (MethodSymbol) e.sym; > if (m.overrides(ms, origin, types, > checkResult) && > (m.flags() & SYNTHETIC) == 0) { > impl = m; > cache.put(origin, m); > return impl; > } > } > } > } > } > > > My contention is that this is a bug. javac should only regard ABSTRACT > SYNTHETIC methods as Miranda methods. After all, Miranda methods are > all abstract are they not? > > Is there some good reason why _ANY_ SYNTHETIC method has to be > rejected? If not then the recommended patch would be to change the > 'if' condition at line 1978/9 above to > > if (m.overrides(ms, origin, types, > checkResult) && > (m.flags() & (SYNTHETIC|ABSTRACT)) != > (SYNTHETIC|ABSTRACT) { > > regards, > > > Andrew Dinn > ----------- > Senior Software Engineer, JBoss > Red Hat UK Ltd > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod > Street, Windsor, Berkshire, > SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons > (USA) and Brendan Lane (Ireland) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100807/774dd0eb/attachment.html From maurizio.cimadamore at oracle.com Mon Aug 9 04:59:52 2010 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 09 Aug 2010 12:59:52 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5FC16D.5070507@redhat.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> Message-ID: <4C5FEDB8.80907@oracle.com> > > Now you may be right that this is nothing to do with Miranda methods. > I cannot really look into the minds of whoever originally designed the > code in order to argue a case. But javac is plainly wrong in stating > that Child does not have an implementation for getAdvisor(). This > method is defined by Parent and has perfectly valid, executable code. > So, Child ought to inherit this implementation. Javac complains about Child not having an 'explicit' override of getAdvisor(), where by 'explicit' I mean a user-defined one (not SYNTHETIC). As I said, bridge methods are an important case of synthetic methods that should *not* be taken into account when determining as to whether a subclass implements all superclass/superinterfaces abstract methods. Now, I admit that the currently implemented check is probably too strict for you, but please, keep in mind that the scenario you are describing (class with just a synthetic implementation of a superinterface method) is something that simply cannot happen when compiling Java sources - that's why javac is not prepared to handle this case [in the case of bridge methods, there's always at least one user-defined implementation in addition to compiler-generated ones, so the check in question is never problematic]. Maurizio From maurizio.cimadamore at oracle.com Mon Aug 9 06:11:25 2010 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 09 Aug 2010 14:11:25 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5FFC47.9090703@redhat.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> Message-ID: <4C5FFE7D.6030600@oracle.com> > Your description of the current situation is not quite accurate. When > javac compiles the source of Child it is not at that time compiling > the source of Parent. It only has the bytecode of Parent available > (the generated SYNTHETIC method _only occurs_ in the bytecode). So, it > is possible for javac to end up finding SYNTHETIC methods in its > method tables which it has not itself introduced directly through > analysis of source code. Are you suggesting that the check can erroneously fail in a scenario without AOP? If so, please post an example. > > What I don't understand is why you have to rely on just the SYNTHETIC > attribute to identify the cases which javac should discount. Looking > at ClassWriter.java it appears that bridge methods are written to the > classfile with the BRIDGE attribute. Similarly, Miranda methods are > written with the SYNTHETIC and ABSTRACT attribute. So, why > automatically discount SYNTHETIC methods? Could you not instead > discount SYNTHETIC|BRIDGE or SYNTHETIC|ABSTRACT methods? That's what I had in mind when I said that the check could be perceived as too strict. Maurizio From neal at gafter.com Mon Aug 9 07:26:04 2010 From: neal at gafter.com (Neal Gafter) Date: Mon, 9 Aug 2010 07:26:04 -0700 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5FFE7D.6030600@oracle.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> Message-ID: <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> The SYNTHETIC attribute is currently defined to be for use on symbols that the compiler should ignore for purposes of semantic analysis. -Neal On Aug 9, 2010, at 6:11 AM, Maurizio Cimadamore wrote: > >> Your description of the current situation is not quite accurate. When javac compiles the source of Child it is not at that time compiling the source of Parent. It only has the bytecode of Parent available (the generated SYNTHETIC method _only occurs_ in the bytecode). So, it is possible for javac to end up finding SYNTHETIC methods in its method tables which it has not itself introduced directly through analysis of source code. > Are you suggesting that the check can erroneously fail in a scenario without AOP? If so, please post an example. >> >> What I don't understand is why you have to rely on just the SYNTHETIC attribute to identify the cases which javac should discount. Looking at ClassWriter.java it appears that bridge methods are written to the classfile with the BRIDGE attribute. Similarly, Miranda methods are written with the SYNTHETIC and ABSTRACT attribute. So, why automatically discount SYNTHETIC methods? Could you not instead discount SYNTHETIC|BRIDGE or SYNTHETIC|ABSTRACT methods? > That's what I had in mind when I said that the check could be perceived as too strict. > > Maurizio From neal at gafter.com Mon Aug 9 09:54:21 2010 From: neal at gafter.com (Neal Gafter) Date: Mon, 9 Aug 2010 09:54:21 -0700 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C60181A.4090705@redhat.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> <4C60181A.4090705@redhat.com> Message-ID: On Mon, Aug 9, 2010 at 8:00 AM, Andrew Dinn wrote: > http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002253.html > > The JVM spec appears to indicate that SYNTHETIC merely means not present in > the source code. The associated thread mentioned something about the > language spec providing a different meaning. Can you explain where exactly > your definition above comes from? > It comes from the practice of implementing the language. In other words, that was the working definition that we used, even though the definition was never published in a publicly available document. We never did get around to producing a compiler specification, which would have been the right place to document it. As a simple example, the compiler-provided default constructor is added by the compiler, but it is not synthetic because it is supposed to be visible for the purposes of the language. The synthetic flag was systematically added to precisely those symbols that should not be visible in the language. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100809/ab6de564/attachment.html From john.r.rose at oracle.com Mon Aug 9 16:07:53 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 9 Aug 2010 16:07:53 -0700 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> <4C60181A.4090705@redhat.com> Message-ID: <7817E6EE-EDEE-4A3C-BB82-766355C245A9@oracle.com> On Aug 9, 2010, at 9:54 AM, Neal Gafter wrote: > The synthetic flag was systematically added to precisely those symbols that should not be visible in the language. Well said. Thanks, Neal. If it weren't for explicit marks on this category of definitions in the bytecodes, it would be dangerous for the compiler to emit internal "helper" methods, fields, or classes. They would be visible to other classes (if not private) and to reflection. But they shouldn't be treated as if they were written or expected by the programmer. -- John From neal at gafter.com Tue Aug 10 07:18:08 2010 From: neal at gafter.com (Neal Gafter) Date: Tue, 10 Aug 2010 07:18:08 -0700 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C6125B6.2010809@redhat.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> <4C60181A.4090705@redhat.com> <7817E6EE-EDEE-4A3C-BB82-766355C245A9@oracle.com> <4C6125B6.2010809@redhat.com> Message-ID: On Tue, Aug 10, 2010 at 3:11 AM, Andrew Dinn wrote: > Perhaps what is needed is for the interface to be SYNTHETIC or, at least, > for it's methods to be SYNTHETIC. Would this actually work? i.e. assume we > were to compile the interface and then bytecode transform it so that either > it or its methods were tagged with SYNTHETIC. If we then place this and the > transformed superclass in the classpath would the checkOverride code still > look for an implementation for the interface method on the subclass or would > it ignore the interface methods on the assumption that they do not require > validation? > That might work (it might ignore them). If your intent is that the interface and its members are not visible to the programmers, that would be appropriate. However, be aware that in that case you are circumventing some javac/language checks. If it does not work, I suspect the compiler team would welcome a patch that makes it work. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100810/cd16d944/attachment.html From maurizio.cimadamore at oracle.com Tue Aug 10 08:20:35 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 10 Aug 2010 15:20:35 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100810152038.B396E47051@hg.openjdk.java.net> Changeset: a2d8c7071f24 Author: mcimadamore Date: 2010-08-10 14:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a2d8c7071f24 6975275: diamond implementation needs some cleanup Summary: resolution issues during diamond inference should be reported through Resolve.logResolveError() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: ea1930f4b789 Author: mcimadamore Date: 2010-08-10 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ea1930f4b789 6975231: Regression test for 6881115 is failing with compiler output not matching expected output Summary: missing symbols are collected in an HashSet which doesn't preserve ordering Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/annotations/6881115/T6881115.out + test/tools/javac/diags/examples/AnnotationMissingValues1.java From chris.hegarty at oracle.com Tue Aug 10 09:31:19 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 10 Aug 2010 16:31:19 +0000 Subject: hg: jdk7/tl/jdk: 6882910: Unexplained lack of IP4 network ability when transparent IP6 to IP4 is disabled. Message-ID: <20100810163132.5012247056@hg.openjdk.java.net> Changeset: 1f996198877b Author: chegar Date: 2010-08-10 17:30 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f996198877b 6882910: Unexplained lack of IP4 network ability when transparent IP6 to IP4 is disabled. Reviewed-by: alanb ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/sun/nio/ch/Net.c From adinn at redhat.com Mon Aug 9 01:50:53 2010 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 09 Aug 2010 09:50:53 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5D9A62.90908@oracle.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> Message-ID: <4C5FC16D.5070507@redhat.com> Hi Maurizio, On 08/07/2010 06:39 PM, maurizio cimadamore wrote: > the compiler internally uses the IPROXY flag to mark Miranda methods: > > 146 /** Flag is set for compiler-generated abstract methods that implement > > 147 * an interface method (Miranda methods). > > 148 */ > > 149 public static final int IPROXY = 1<<21; > > > The code you are looking at discards SYNTHETIC methods because this > method is meant to return an user-defined implementation of a given > method symbol in a given class - and a SYNTEHTIC method is, by > definition, not a user-defined method. This check turns out particularly > useful when the class contains one or more bridge methods (the method > that javac has to emit to preserve overriding in the face of type-erasure). > > In other words, javac is not complaining because it thinks that > getAdvisor() is a Miranda method - it just complains because it sees a > class not overriding all methods from its superinterfaces. Yes, I noted that javac adds the IPROXY method attribute to any Miranda methods it generates during the compile. But in this case I am referring to a Miranda method generated during a previous compile then written to the bytecode file for the class. Are you sugesting that Miranda methods do not get written to the abstract class's bytecode file? As far as I coudl tell they are written out as ABSTRACT SYNTHETIC methods but without the IPROXY attribute (this attribute is private to javac). Anyway, your comment merely provides an account of why the check is made but this does not really address its validity. You are absolutely right that in the circumstances I highlighted the purpose of the check is to see whether the class has overridden all methods inherited from its superinterfaces. Well, in this case the answer is that the class is valid and the check is wrong. The situation is as follows. We have a POJO class parent abstract class Parent { public abstract Foo getFoo(); . . . } AOP transforms this class as follows abstract class Parent implements Advised { // synthetic method added by AOP public Advisor getAdvisor() { . . . } public abstract Foo getFoo(); . . . } interface Advised { public Advisor getAdvisor() } The bytecode file for this class contains an implementation of getAdvisor() but it is tagged with the SYNTHETIC attribute. Now we define a class Child as follows class Child extends Parent { public Foo getFoo() { . . . } Now javac is asked to compile Child and the AOP transformed bytecode for Parent is placed in the class path. javac complains that Child does not implement getAdvisor(). Well, it does not need to because the transformed code for Parent implements it. The immediate reason why the parent implementation of getAdvisor() is discounted is because the generated code for getAdvisor() is SYNTHETIC and the check I highlighted ignores SYNTHETIC methods. Now you may be right that this is nothing to do with Miranda methods. I cannot really look into the minds of whoever originally designed the code in order to argue a case. But javac is plainly wrong in stating that Child does not have an implementation for getAdvisor(). This method is defined by Parent and has perfectly valid, executable code. So, Child ought to inherit this implementation. In fact when Parent is not an abstract class the SYNTHETIC code is inherited and executed without any problem. It is only in the case where the parent is abstract that this issue arises (I'll just note that this is because the check is only made when there may be Miranda methods to look for). So, irrespective of motive can you explain to me why it is correct to disregard this SYNTHETIC implementation? regards, Andrew Dinn ----------- From adinn at redhat.com Mon Aug 9 06:01:59 2010 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 09 Aug 2010 14:01:59 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5FEDB8.80907@oracle.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> Message-ID: <4C5FFC47.9090703@redhat.com> On 08/09/2010 12:59 PM, Maurizio Cimadamore wrote: > Javac complains about Child not having an 'explicit' override of > getAdvisor(), where by 'explicit' I mean a user-defined one (not > SYNTHETIC). As I said, bridge methods are an important case of synthetic > methods that should *not* be taken into account when determining as to > whether a subclass implements all superclass/superinterfaces abstract > methods. Yes, I understand that javac needs to be able to discount the SYNTHETIC methods it adds to classes. In fact, my motivation for posting on this issue is to try to pin down the semantics of the SYNTHETIC attribute. AOP adds it to generated methods for good reasons (JBoss Application Server needs to discount these methods when it applies runtime container transformations to the code). If the assumption that it can use this attribute to identify AOP generated code is invalid I would like to know exactly why. > Now, I admit that the currently implemented check is probably too strict > for you, but please, keep in mind that the scenario you are describing > (class with just a synthetic implementation of a superinterface method) > is something that simply cannot happen when compiling Java sources - > that's why javac is not prepared to handle this case [in the case of > bridge methods, there's always at least one user-defined implementation > in addition to compiler-generated ones, so the check in question is > never problematic]. Your description of the current situation is not quite accurate. When javac compiles the source of Child it is not at that time compiling the source of Parent. It only has the bytecode of Parent available (the generated SYNTHETIC method _only occurs_ in the bytecode). So, it is possible for javac to end up finding SYNTHETIC methods in its method tables which it has not itself introduced directly through analysis of source code. What I don't understand is why you have to rely on just the SYNTHETIC attribute to identify the cases which javac should discount. Looking at ClassWriter.java it appears that bridge methods are written to the classfile with the BRIDGE attribute. Similarly, Miranda methods are written with the SYNTHETIC and ABSTRACT attribute. So, why automatically discount SYNTHETIC methods? Could you not instead discount SYNTHETIC|BRIDGE or SYNTHETIC|ABSTRACT methods? Are you saying that you cannot rely on the BRIDGE attribute to identify bridge methods? (I am assuming that the generated ones have SYNTHETIC|BRIDGE in their flags list while the user-defined ones merely have BRIDGE -- is that not the case?). regards, Andrew Dinn ----------- From adinn at redhat.com Mon Aug 9 06:56:45 2010 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 09 Aug 2010 14:56:45 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <4C5FFE7D.6030600@oracle.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> Message-ID: <4C60091D.5080908@redhat.com> On 08/09/2010 02:11 PM, Maurizio Cimadamore wrote: >> Your description of the current situation is not quite accurate. When >> javac compiles the source of Child it is not at that time compiling >> the source of Parent. It only has the bytecode of Parent available >> (the generated SYNTHETIC method _only occurs_ in the bytecode). So, it >> is possible for javac to end up finding SYNTHETIC methods in its >> method tables which it has not itself introduced directly through >> analysis of source code. > Are you suggesting that the check can erroneously fail in a scenario > without AOP? If so, please post an example. Err, no, not exactly. Although it is not specifically the use of AOP which is pertinent here. Any bytecode transformer can take a compiled class, introduce extra interfaces and implementations of the interfaces' methods into the class then rewrite the bytecode file. If it labels these methods as SYNTHETIC then the question is how should javac interpret this when it compiles sources against the transformed bytecode. The point I was trying to make was that javac does not always see the source for every class it handles during a compile -- some of the code is only available as bytecode. Clearly it can assume that SYNTHETIC methods of classes it has translated from source are so because it has labelled them so. Clearly it also does assume that any code found in bytecode which is SYNTHETIC must have been labelled as SYNTHETIC by it on a previous compile. This was obviously a valid assumption before anyone implemented a bytecode transformer. All I am saying is that it is not necessarily valid now. These days the tool chain is more complex than just javac. As a consequence of this assumption javac assumes that anything with the SYNTHETIC attribute cannot be regarded as an implementation of an abstract method - it assumes this even if the method also has bytecode. Now, that definitely looks to be an anomaly prima facie as far as Im concerned. Whether or not this is a valid assumption on its own terms it is most definitely at variance with what the JVM does. The latter will happily load and execute SYNTHETIC bytecode. As I said previously, take away the abstract qualifies in the Parent child example and you can will see the JVM happily execute Parent.getAdvisor() when a call is made to child.getAdvisor() where child is an instance of Child. In fact, there is a more immediate disparity between the JVM and javac which applies even in the case where abstract classes are involved. The problem I raised in my example only occurs if the AOP transform is applied between two successive compiles, first of Parent then of Child. If you compile them both in one call to javac and then transform Parent to add interface Advised and method getAdvisor() you arrive at the situation javac is banning: a SYNTHETIC implementation of Parent.getAdvisor() on abstract class Parent inherited by a non-abstract subclass Child. In this case the JVM will load Parrent and Child and validate both classes. It is quite happy to accept the SYNTHETIC implementation of getAdvisor() as an implementation of the method declared in interface Advised. This is why I regards the behaviour of javac as an error. At the very least it is a rather obvious inconsistency between what the JVM and the compiler take to be the semantics of SYNTHETIC. More importantly, by applying this narrower meaning to SYNTHETIC javac is stopping other compile-chain tools profiting from the availability of the SYNTHETIC flag. Now maybe they ought to use their own attributes to identify that this is generated code but it would be much easier and more convenient if this meaning were applied consistently by JVM, javac and other compile-chain tools. >> What I don't understand is why you have to rely on just the SYNTHETIC >> attribute to identify the cases which javac should discount. Looking >> at ClassWriter.java it appears that bridge methods are written to the >> classfile with the BRIDGE attribute. Similarly, Miranda methods are >> written with the SYNTHETIC and ABSTRACT attribute. So, why >> automatically discount SYNTHETIC methods? Could you not instead >> discount SYNTHETIC|BRIDGE or SYNTHETIC|ABSTRACT methods? > That's what I had in mind when I said that the check could be perceived > as too strict. Well, ok then, I do perceive it as too strict. So, here's the $64M questionL can this be relaxed :-) regards, Andrew Dinn ----------- From adinn at redhat.com Mon Aug 9 07:44:30 2010 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 09 Aug 2010 15:44:30 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> Message-ID: <4C60144E.2070905@redhat.com> On 08/09/2010 03:26 PM, Neal Gafter wrote: > The SYNTHETIC attribute is currently defined to be for use on symbols > that the compiler should ignore for purposes of semantic analysis. Well, thanks for the definition. That's very clear albeit it still leaves me slightly unsatisfied (but not dissatisfied) over the fact that the JVM is somewhat at variance with this (it's semantic being "it has bytecode so I'll bite"). I'll report the bad news back to the AOP team and see what we can do to remedy the situation. Thank you for entertaining my complaints so patiently. regards, Andrew Dinn ----------- From adinn at redhat.com Mon Aug 9 08:00:42 2010 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 09 Aug 2010 16:00:42 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> Message-ID: <4C60181A.4090705@redhat.com> On 08/09/2010 03:26 PM, Neal Gafter wrote: > The SYNTHETIC attribute is currently defined to be for use on symbols > that the compiler should ignore for purposes of semantic analysis. Hi Neal. Back again, already :-) I hope you'll answer another question. I just noticed a reply to the list which did not come to me personally (I am not subscribed) and which referred to the latest JVM spec: http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002253.html The JVM spec appears to indicate that SYNTHETIC merely means not present in the source code. The associated thread mentioned something about the language spec providing a different meaning. Can you explain where exactly your definition above comes from? regards, Andrew Dinn ----------- From adinn at redhat.com Mon Aug 9 12:36:57 2010 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 09 Aug 2010 20:36:57 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> <4C60181A.4090705@redhat.com> Message-ID: <4C6058D9.90004@redhat.com> On 08/09/2010 05:54 PM, Neal Gafter wrote: > It comes from the practice of implementing the language. In other words, > that was the working definition that we used, even though the definition was > never published in a publicly available document. We never did get around > to producing a compiler specification, which would have been the right place > to document it. As a simple example, the compiler-provided default > constructor is added by the compiler, but it is not synthetic because it is > supposed to be visible for the purposes of the language. The synthetic flag > was systematically added to precisely those symbols that should not be > visible in the language. Hmm, now that's interesting because exactly the same kind of rationale led us to tag AOP helper methods like getAdvisor() as SYNTHETIC. These methods only exist as mechanism to implement semantic extensions (e.g. to allow annotations like @Transactional etc to change the way the source gets executed). So they should not themselves be susceptible to such transformations hence we used SYNTHETIC to make them 'invisible' to the transformation process. Now this may not be the correct attribute for us to be using but maybe there ought to be some sort of standard way to identify this category of code, not just for AOP but for other transformation processes. I have a wider stake in this as my own project, Byteman, also uses code transformation and needs to be able to recognise and avoid transforming code generated by other transformation processes. I wonder if there is any mileage in pursuing this further? Interesting too that the Groovy implementation ran foul of the same misunderstanding as we did. Perhaps this needs a small subcommittee to discuss it to death :-) regards, Andrew Dinn ----------- From adinn at redhat.com Tue Aug 10 03:11:02 2010 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 10 Aug 2010 11:11:02 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: <7817E6EE-EDEE-4A3C-BB82-766355C245A9@oracle.com> References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> <4C60181A.4090705@redhat.com> <7817E6EE-EDEE-4A3C-BB82-766355C245A9@oracle.com> Message-ID: <4C6125B6.2010809@redhat.com> On 08/10/2010 12:07 AM, John Rose wrote: > If it weren't for explicit marks on this category of definitions in > the bytecodes, it would be dangerous for the compiler to emit > internal "helper" methods, fields, or classes. They would be visible > to other classes (if not private) and to reflection. But they > shouldn't be treated as if they were written or expected by the > programmer. Well, that's also true of some, if not all, of the code generated by many bytecode transformers. As I remarked in an earlier note the compiler tool chain is now much wider than just javac. However, these other tools have have different requirements for visibility, perhaps making SYNTHETIC unsuitable as a means of hiding behaviours which are there as implementation mechanism. In this present case, the subclass is failing to compile because its (abstract) parent class has been transformed to include an interface and a SYNTHETIC implementation of that interface. Since this transform is meant to be a strictly local affair confined only to the parent class this seems to be a case where use of SYNTHETIC should be appropriate. The subclass honours the original class's requirements (it implements abstract methods not introduced by the transformation) and it only fails to honour those of the transformed class because the interface method is visible but the SYNTHETIC parent class implementation is not. Perhaps what is needed is for the interface to be SYNTHETIC or, at least, for it's methods to be SYNTHETIC. Would this actually work? i.e. assume we were to compile the interface and then bytecode transform it so that either it or its methods were tagged with SYNTHETIC. If we then place this and the transformed superclass in the classpath would the checkOverride code still look for an implementation for the interface method on the subclass or would it ignore the interface methods on the assumption that they do not require validation? regards, Andrew Dinn ----------- From lance.andersen at oracle.com Tue Aug 10 07:19:03 2010 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 10 Aug 2010 14:19:03 +0000 Subject: hg: jdk7/tl/jdk: 6898593: java.sql.Date.valueOf no exception if date given is not in the JDBC date escape syntax Message-ID: <20100810141912.AA9BB4704E@hg.openjdk.java.net> Changeset: 3e239fe92832 Author: lancea Date: 2010-08-10 10:07 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3e239fe92832 6898593: java.sql.Date.valueOf no exception if date given is not in the JDBC date escape syntax Reviewed-by: minqi ! src/share/classes/java/sql/Date.java From adinn at redhat.com Tue Aug 10 07:45:45 2010 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 10 Aug 2010 15:45:45 +0100 Subject: Miranda methods and Methods added by Code Generators In-Reply-To: References: <4C5C2863.3010603@redhat.com> <4C5D9A62.90908@oracle.com> <4C5FC16D.5070507@redhat.com> <4C5FEDB8.80907@oracle.com> <4C5FFC47.9090703@redhat.com> <4C5FFE7D.6030600@oracle.com> <0CC633EF-B458-4535-95DB-D2C6ABB63D3B@gafter.com> <4C60181A.4090705@redhat.com> <7817E6EE-EDEE-4A3C-BB82-766355C245A9@oracle.com> <4C6125B6.2010809@redhat.com> Message-ID: <4C616619.7000404@redhat.com> On 08/10/2010 03:18 PM, Neal Gafter wrote: > That might work (it might ignore them). If your intent is that the > interface and its members are not visible to the programmers, that would be > appropriate. However, be aware that in that case you are circumventing some > javac/language checks. Well, we know already that we are generating code that the JVM will happily and safely eat since we can arrive at the same situation by applying the AOP transform after compiling parent and child. So, I have no worries about validity as far as the current transformation code stands -- of course, given this much rope we could still screw up later :-) > If it does not work, I suspect the compiler team would welcome a patch that > makes it work. And here's me wanting to get stuck into the hotspot code for the last 6 months without having been able to find the time. Anyway, thanks for the invitation -- I'll see what works and contribute a patch if I need and am able to. regards, Andrew Dinn ----------- From xueming.shen at oracle.com Tue Aug 10 13:17:57 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 10 Aug 2010 20:17:57 +0000 Subject: hg: jdk7/tl/jdk: 6923794: About 40 JCK test case fail with AssertionError if -esa option is specified Message-ID: <20100810201807.0018E47061@hg.openjdk.java.net> Changeset: da5b67ac7755 Author: sherman Date: 2010-08-10 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da5b67ac7755 6923794: About 40 JCK test case fail with AssertionError if -esa option is specified Summary: removed the assert Reviewed-by: alanb ! src/solaris/classes/java/io/UnixFileSystem.java ! src/windows/classes/java/io/Win32FileSystem.java From alan.bateman at oracle.com Thu Aug 12 11:56:13 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 Aug 2010 18:56:13 +0000 Subject: hg: jdk7/tl/jdk: 6971825: (so) improve scatter/gather implementation Message-ID: <20100812185626.EB50A470FC@hg.openjdk.java.net> Changeset: 11ee8b471f9c Author: alanb Date: 2010-08-12 19:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/11ee8b471f9c 6971825: (so) improve scatter/gather implementation Reviewed-by: chegar, sherman ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/IOVecWrapper.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java From mandy.chung at oracle.com Thu Aug 12 16:47:41 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 12 Aug 2010 23:47:41 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100812234800.12AEA47112@hg.openjdk.java.net> Changeset: 389bc53d0945 Author: mchung Date: 2010-08-12 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/389bc53d0945 6973831: NPE when printing stack trace of OOME Summary: Initialize suppressedExceptions field to null Reviewed-by: briangoetz, dholmes, forax ! src/share/classes/java/lang/Throwable.java Changeset: cdd6d518f47e Author: mchung Date: 2010-08-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cdd6d518f47e Merge From lana.steuck at oracle.com Thu Aug 12 22:49:18 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:49:18 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20100813054918.8EEB047131@hg.openjdk.java.net> Changeset: f8be576feefc Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f8be576feefc Added tag jdk7-b103 for changeset be2aedc4e3b1 ! .hgtags Changeset: 9f96a4269d77 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/9f96a4269d77 Added tag jdk7-b104 for changeset f8be576feefc ! .hgtags From lana.steuck at oracle.com Thu Aug 12 22:49:23 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:49:23 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20100813054924.BCA4A47132@hg.openjdk.java.net> Changeset: 9607213481d4 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/9607213481d4 Added tag jdk7-b103 for changeset 11e7678c3eb1 ! .hgtags Changeset: 6f21b030092f Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6f21b030092f Added tag jdk7-b104 for changeset 9607213481d4 ! .hgtags From lana.steuck at oracle.com Thu Aug 12 22:54:10 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:54:10 +0000 Subject: hg: jdk7/tl/jaxp: 2 new changesets Message-ID: <20100813055410.D6BED47136@hg.openjdk.java.net> Changeset: d42c4acb6424 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d42c4acb6424 Added tag jdk7-b103 for changeset b7722e878864 ! .hgtags Changeset: 3233b9a4c12e Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/3233b9a4c12e Added tag jdk7-b104 for changeset d42c4acb6424 ! .hgtags From lana.steuck at oracle.com Thu Aug 12 22:54:15 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:54:15 +0000 Subject: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20100813055415.E635A47137@hg.openjdk.java.net> Changeset: bbc4cce6c20a Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/bbc4cce6c20a Added tag jdk7-b103 for changeset 267386d6b923 ! .hgtags Changeset: 39eb4f3031f4 Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/39eb4f3031f4 Added tag jdk7-b104 for changeset bbc4cce6c20a ! .hgtags From lana.steuck at oracle.com Thu Aug 12 22:55:38 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:55:38 +0000 Subject: hg: jdk7/tl/jdk: 21 new changesets Message-ID: <20100813055900.A0CE247139@hg.openjdk.java.net> Changeset: b839344245a9 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b839344245a9 Added tag jdk7-b103 for changeset 6488b70a23cc ! .hgtags Changeset: 6950da80c75c Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6950da80c75c 6973616: Update minimum boot jdk from 1.5 to 1.6 Reviewed-by: igor, jjg ! make/common/shared/Defs-versions.gmk Changeset: dd48c78218a7 Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd48c78218a7 6971426: jdk/make/docs docs target does not work on windows Reviewed-by: igor, jjg ! make/docs/Makefile Changeset: f46ec75b1663 Author: ohair Date: 2010-08-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f46ec75b1663 6974239: Correct reference to jdk document site in javadoc Reviewed-by: skannan ! make/docs/Makefile Changeset: 1a92820132a0 Author: cl Date: 2010-08-04 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1a92820132a0 Merge Changeset: d967f8507d9d Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d967f8507d9d Added tag jdk7-b104 for changeset 1a92820132a0 ! .hgtags Changeset: 539528c5d395 Author: lana Date: 2010-07-14 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/539528c5d395 Merge Changeset: cf0c23a99823 Author: lana Date: 2010-07-29 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf0c23a99823 Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: c6f443c3d96a Author: lana Date: 2010-08-02 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6f443c3d96a Merge Changeset: c38803ce0560 Author: uta Date: 2010-07-23 18:59 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c38803ce0560 6969851: VM hangs/crashes in FileDialog test (VS2008/2010 build) Reviewed-by: prr, art ! src/windows/native/sun/windows/awt.h Changeset: 9bb8d5c093fc Author: lana Date: 2010-07-29 13:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9bb8d5c093fc Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 8a72583dc41d Author: lana Date: 2010-08-02 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8a72583dc41d Merge Changeset: 65403b9bcb58 Author: peterz Date: 2010-07-13 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/65403b9bcb58 6462562: InternationalFormatter inserts text incorrectly 6578432: Currency format instance does not work with Swing's NumberFormatter Reviewed-by: rupashka ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/InternationalFormatter.java + test/javax/swing/JFormattedTextField/Test6462562.java Changeset: a0d7b76abcd3 Author: alexp Date: 2010-07-29 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a0d7b76abcd3 4743225: Size of JComboBox list is wrong when list is populated via PopupMenuListener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java + test/javax/swing/JComboBox/4743225/bug4743225.java Changeset: 0e8acbf12695 Author: lana Date: 2010-07-29 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e8acbf12695 Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 951e46d93af0 Author: malenkov Date: 2010-07-30 19:21 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/951e46d93af0 6199676: REGRESSION: ColorChooser loses preview when change LandF in Java5 Reviewed-by: alexp, peterz ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java + test/javax/swing/JColorChooser/Test6199676.java Changeset: f40de306ab66 Author: malenkov Date: 2010-07-30 19:40 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f40de306ab66 6972468: Security manager should be used for tests in java/beans/XMLEncoder Reviewed-by: peterz ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4903007.java ! test/java/beans/XMLEncoder/javax_swing_JLayeredPane.java Changeset: ce1e26600ab7 Author: lana Date: 2010-08-02 19:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce1e26600ab7 Merge Changeset: 10e7e04d1e96 Author: lana Date: 2010-08-02 19:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/10e7e04d1e96 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 3b0abcb51280 Author: lana Date: 2010-08-09 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b0abcb51280 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 041997c49f15 Author: lana Date: 2010-08-12 19:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/041997c49f15 Merge From lana.steuck at oracle.com Thu Aug 12 22:52:06 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 05:52:06 +0000 Subject: hg: jdk7/tl/hotspot: 20 new changesets Message-ID: <20100813055241.E622447133@hg.openjdk.java.net> Changeset: efd4401fab1d Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/efd4401fab1d Added tag jdk7-b103 for changeset cb4250ef73b2 ! .hgtags Changeset: e7ec8cd4dd8a Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7ec8cd4dd8a 6962569: assembler_sparc.cpp:1969: assert(false) failed: error Summary: array_overlap_test() fails when the address range crosses the MSB boundary. Thanks to Tom and Vladimir for their help on this one. Reviewed-by: kvn, never, iveresov ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: 4e5661ba9d98 Author: tonyp Date: 2010-06-28 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4e5661ba9d98 6944166: G1: explicit GCs are not always handled correctly Summary: G1 was not handling explicit GCs correctly in many ways. It does now. See the CR for the list of improvements contained in this changeset. Reviewed-by: iveresov, ysr, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/runtime/mutexLocker.cpp Changeset: 1a1ce2076047 Author: ysr Date: 2010-07-16 10:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1a1ce2076047 Merge Changeset: ad7e433e2730 Author: ysr Date: 2010-07-20 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ad7e433e2730 Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: 131ed9a23d48 Author: ysr Date: 2010-07-21 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/131ed9a23d48 Merge Changeset: 083fde3b838e Author: jrose Date: 2010-07-15 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/083fde3b838e 6964498: JSR 292 invokedynamic sites need local bootstrap methods Summary: Add JVM_CONSTANT_InvokeDynamic records to constant pool to determine per-instruction BSMs. Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 01b172b8cd7c Author: never Date: 2010-07-16 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/01b172b8cd7c Merge Changeset: e0ba4e04c839 Author: jrose Date: 2010-07-16 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e0ba4e04c839 6969574: invokedynamic call sites deoptimize instead of executing Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 7139e81efd2d Author: never Date: 2010-07-22 15:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7139e81efd2d 6970566: runThese fails with SIGSEGV Reviewed-by: kvn ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp Changeset: 5063ce716349 Author: never Date: 2010-07-23 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5063ce716349 Merge Changeset: a93a9eda13f7 Author: jcoomes Date: 2010-07-16 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a93a9eda13f7 6962947: shared TaskQueue statistics Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 5cbac8938c4c Author: johnc Date: 2010-07-19 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5cbac8938c4c 6956639: G1: assert(cached_ptr != card_ptr) failed: shouldn't be, concurrentG1Refine.cpp:307 Summary: During concurrent refinment, filter cards in young regions after it has been determined that the region has been allocated from and the young type of the region has been set. Reviewed-by: iveresov, tonyp, jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 4f1fffe08c63 Author: ysr Date: 2010-07-21 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4f1fffe08c63 Merge Changeset: 1890dc9151da Author: ysr Date: 2010-07-23 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1890dc9151da Merge Changeset: cc3fdfeb54b0 Author: trims Date: 2010-07-29 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cc3fdfeb54b0 Merge Changeset: fd2645290e89 Author: trims Date: 2010-07-30 06:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fd2645290e89 6973381: Bump the HS19 build number to 05 Summary: Update the HS19 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 28abe3f6a5f6 Author: trims Date: 2010-08-03 19:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/28abe3f6a5f6 Merge Changeset: b4acf10eb134 Author: trims Date: 2010-08-05 02:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b4acf10eb134 Added tag hs19-b04 for changeset e55900b5c1b8 ! .hgtags Changeset: 6709c14587c2 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6709c14587c2 Added tag jdk7-b104 for changeset b4acf10eb134 ! .hgtags From lana.steuck at oracle.com Thu Aug 12 23:00:17 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 13 Aug 2010 06:00:17 +0000 Subject: hg: jdk7/tl/langtools: 5 new changesets Message-ID: <20100813060025.AE9BB4713A@hg.openjdk.java.net> Changeset: fc7219517ec1 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc7219517ec1 Added tag jdk7-b103 for changeset bd85271c580c ! .hgtags Changeset: 49489c1d8fae Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/49489c1d8fae Added tag jdk7-b104 for changeset fc7219517ec1 ! .hgtags Changeset: 186feb2042f0 Author: lana Date: 2010-08-02 19:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/186feb2042f0 Merge Changeset: aaecac256d39 Author: lana Date: 2010-08-09 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aaecac256d39 Merge Changeset: c04ae2714f52 Author: lana Date: 2010-08-12 19:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c04ae2714f52 Merge From ahughes at redhat.com Fri Aug 13 14:27:25 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 13 Aug 2010 21:27:25 +0000 Subject: hg: jdk7/tl/jdk: 6976186: Integrate Shark Message-ID: <20100813212737.E9C8A4716A@hg.openjdk.java.net> Changeset: 0cdd73548292 Author: gbenson Date: 2010-08-13 22:26 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0cdd73548292 6976186: Integrate Shark Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure. Reviewed-by: ohair ! make/jdk_generic_profile.sh From maurizio.cimadamore at oracle.com Mon Aug 16 07:06:26 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 16 Aug 2010 14:06:26 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100816140629.E3B0647206@hg.openjdk.java.net> Changeset: 27bae58329d5 Author: mcimadamore Date: 2010-08-16 14:56 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/27bae58329d5 6976649: javac does not enforce required annotation elements in arrays Summary: type annotation should take advantage of recursive annotation checking Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out ! test/tools/javac/annotations/pos/TrailingComma.java Changeset: dc550520ed6f Author: mcimadamore Date: 2010-08-16 14:58 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dc550520ed6f 6369605: Unconstrained type variables fails to include bounds Summary: unconstrained type-variables with recursive bounds are not inferred properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/generics/inference/6369605/T6369605a.java + test/tools/javac/generics/inference/6369605/T6369605b.java ! test/tools/javac/generics/inference/6638712/T6638712a.out From jonathan.gibbons at oracle.com Mon Aug 16 14:59:42 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 16 Aug 2010 21:59:42 +0000 Subject: hg: jdk7/tl/langtools: 6976833: options included twice in Example SimpleCompiler Message-ID: <20100816215944.29C474721B@hg.openjdk.java.net> Changeset: a31c511db424 Author: jjg Date: 2010-08-16 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a31c511db424 6976833: options included twice in Example SimpleCompiler Reviewed-by: darcy ! test/tools/javac/diags/Example.java From mandy.chung at oracle.com Mon Aug 16 15:36:36 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 16 Aug 2010 22:36:36 +0000 Subject: hg: jdk7/tl/jdk: 6921234: TEST_BUG: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be modified for Cygwin Message-ID: <20100816223646.22CDC4721E@hg.openjdk.java.net> Changeset: 8329ebeabc10 Author: mchung Date: 2010-08-16 15:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8329ebeabc10 6921234: TEST_BUG: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh needs to be modified for Cygwin Summary: Add check for CYGWIN Reviewed-by: ohair ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh From michael.x.mcmahon at oracle.com Tue Aug 17 07:16:41 2010 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 17 Aug 2010 14:16:41 +0000 Subject: hg: jdk7/tl/jdk: 6339649: URI.create should include a detail message when throwing IllegalArgumentException Message-ID: <20100817141706.2738447248@hg.openjdk.java.net> Changeset: 42eaa082a4e6 Author: michaelm Date: 2010-08-17 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42eaa082a4e6 6339649: URI.create should include a detail message when throwing IllegalArgumentException Summary: create enclosing exception with message of enclosed Reviewed-by: alanb, chegar ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java From xueming.shen at oracle.com Tue Aug 17 16:07:31 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 17 Aug 2010 23:07:31 +0000 Subject: hg: jdk7/tl/jdk: 6969651: TEST_BUG: tools/jar/JarEntryTime.java failed on JDK7 when run on NFS Message-ID: <20100817230740.B70464725D@hg.openjdk.java.net> Changeset: bfc3855a9341 Author: sherman Date: 2010-08-17 16:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bfc3855a9341 6969651: TEST_BUG: tools/jar/JarEntryTime.java failed on JDK7 when run on NFS Summary: changed to use more appropriate nfs file time Reviewed-by: martin ! test/tools/jar/JarEntryTime.java From kelly.ohair at oracle.com Wed Aug 18 18:46:37 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Thu, 19 Aug 2010 01:46:37 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100819014656.681F8472A0@hg.openjdk.java.net> Changeset: 01dec49e95c4 Author: ohair Date: 2010-08-18 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/01dec49e95c4 6974005: Use of cygpath in Makefile logic needs to silence error messages Reviewed-by: mchung ! make/common/shared/Defs-windows.gmk Changeset: 42bfa43f2ae1 Author: ohair Date: 2010-08-18 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42bfa43f2ae1 6932743: Makefiles not parsing version strings with - from uname -r Reviewed-by: mchung ! make/common/shared/Defs.gmk From weijun.wang at sun.com Wed Aug 18 20:27:10 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 19 Aug 2010 03:27:10 +0000 Subject: hg: jdk7/tl/jdk: 6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default. Message-ID: <20100819032719.85816472A4@hg.openjdk.java.net> Changeset: 4abd65f04638 Author: weijun Date: 2010-08-19 11:26 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4abd65f04638 6976536: Solaris JREs do not have the krb5.kdc.bad.policy configured by default. Reviewed-by: valeriep ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + test/sun/security/krb5/BadKdcDefaultValue.java From weijun.wang at sun.com Wed Aug 18 21:25:11 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 19 Aug 2010 04:25:11 +0000 Subject: hg: jdk7/tl/jdk: 6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException Message-ID: <20100819042521.C27C4472A7@hg.openjdk.java.net> Changeset: 95bb147c7c33 Author: weijun Date: 2010-08-19 12:24 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/95bb147c7c33 6921610: 1.6 update 17 and 18 throw java.lang.IndexOutOfBoundsException Reviewed-by: vinnie, xuelei ! src/share/classes/com/sun/jndi/ldap/Connection.java From maurizio.cimadamore at oracle.com Thu Aug 19 04:04:46 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 19 Aug 2010 11:04:46 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100819110452.C4D74472B7@hg.openjdk.java.net> Changeset: c655e0280bdc Author: mcimadamore Date: 2010-08-19 11:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c655e0280bdc 6886247: regression: javac crashes with an assertion error in Attr.java Summary: capture conversion does not work on nested types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/wildcards/6886247/T6886247_1.java + test/tools/javac/generics/wildcards/6886247/T6886247_2.java + test/tools/javac/generics/wildcards/6886247/T6886247_2.out Changeset: d6fe0ea070aa Author: mcimadamore Date: 2010-08-19 11:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d6fe0ea070aa 6885255: Improve usability of raw warnings Summary: raw warnings should be disabled in (i) instanceof expressions and (ii) when java.lang.Class is not parameterized Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out + test/tools/javac/warnings/6885255/T6885255.java + test/tools/javac/warnings/6885255/T6885255.out Changeset: a75770c0d7f6 Author: mcimadamore Date: 2010-08-19 11:54 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a75770c0d7f6 6977800: Regression: invalid resolution of supertype for local class Summary: resolution of superclass/superinterfaces in extends/implements clause skips local classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T6977800.java ! test/tools/javac/generics/typevars/5060485/Compatibility.java + test/tools/javac/generics/typevars/5060485/Compatibility.out + test/tools/javac/generics/typevars/5060485/Compatibility02.java + test/tools/javac/generics/typevars/5060485/Compatibility02.out From kumar.x.srinivasan at oracle.com Fri Aug 20 08:51:43 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 20 Aug 2010 15:51:43 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100820155217.D5DAB4730D@hg.openjdk.java.net> Changeset: 1ce9c1690080 Author: ksrini Date: 2010-08-19 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ce9c1690080 6888127: java.util.jar.Pack200.Packer Memory Leak Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java + src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java Changeset: 16e43f336262 Author: ksrini Date: 2010-08-20 08:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16e43f336262 6966737: (pack200) the pack200 regression tests need to be more robust. Reviewed-by: jrose, ohair + test/tools/pack200/CommandLineTests.java - test/tools/pack200/Pack200Simple.sh ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/SegmentLimit.java + test/tools/pack200/Utils.java + test/tools/pack200/pack200-verifier/data/README + test/tools/pack200/pack200-verifier/data/golden.jar + test/tools/pack200/pack200-verifier/make/build.xml + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/ClassCompare.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Globals.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/JarFileCompare.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/Main.java + test/tools/pack200/pack200-verifier/src/sun/tools/pack/verify/VerifyTreeSet.java + test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java + test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java + test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java + test/tools/pack200/pack200-verifier/src/xmlkit/CommandLineParser.java + test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java + test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java + test/tools/pack200/pack200-verifier/src/xmlkit/TokenList.java + test/tools/pack200/pack200-verifier/src/xmlkit/XMLKit.java Changeset: db1b7c10de61 Author: ksrini Date: 2010-08-20 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db1b7c10de61 Merge From chris.hegarty at oracle.com Mon Aug 23 06:36:04 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 23 Aug 2010 13:36:04 +0000 Subject: hg: jdk7/tl/jdk: 6968584: Thread should not be Cloneable Message-ID: <20100823133621.6DB78473B0@hg.openjdk.java.net> Changeset: fd28003bc1d6 Author: chegar Date: 2010-08-23 14:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd28003bc1d6 6968584: Thread should not be Cloneable Reviewed-by: dholmes ! src/share/classes/java/lang/Thread.java From chris.hegarty at oracle.com Mon Aug 23 08:28:58 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 23 Aug 2010 15:28:58 +0000 Subject: hg: jdk7/tl/jdk: 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe Message-ID: <20100823152907.B3C4D473B5@hg.openjdk.java.net> Changeset: 03218163f4d5 Author: chegar Date: 2010-08-23 16:27 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03218163f4d5 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java From maurizio.cimadamore at oracle.com Mon Aug 23 09:01:09 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 23 Aug 2010 16:01:09 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100823160112.D7979473B7@hg.openjdk.java.net> Changeset: 995bcdb9a41d Author: mcimadamore Date: 2010-08-23 16:59 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/995bcdb9a41d 6932571: Compiling Generics causing Inconvertible types Summary: Types.rewriteQuantifiers() does not work well with recursive type-variable bounds 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/cast/6270087/T6270087.java + test/tools/javac/cast/6270087/T6270087neg.java + test/tools/javac/cast/6270087/T6270087neg.out + test/tools/javac/cast/6507317/T6507317.java + test/tools/javac/cast/6569057/T6569057.java + test/tools/javac/cast/6932571/T6932571a.java + test/tools/javac/cast/6932571/T6932571b.java + test/tools/javac/cast/6932571/T6932571neg.java + test/tools/javac/cast/6932571/T6932571neg.out Changeset: 594b3c2ef585 Author: mcimadamore Date: 2010-08-23 17:00 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/594b3c2ef585 6978574: return statement in try block with multi-catch causes ClassFormatError Summary: Wrong nested loops in Gen.java causes javac to generate bad bytecode Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/multicatch/T6978574.java From alan.bateman at oracle.com Mon Aug 23 09:38:39 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 23 Aug 2010 16:38:39 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100823163858.03F76473BA@hg.openjdk.java.net> Changeset: 47ab0dcec3e8 Author: alanb Date: 2010-08-23 17:11 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47ab0dcec3e8 6978511: (file) Path.toRealPath should fail if not resolving links and file does not exist Reviewed-by: forax, chegar ! src/solaris/classes/sun/nio/fs/UnixPath.java ! test/java/nio/file/Path/Misc.java Changeset: f4a2b4e7a831 Author: alanb Date: 2010-08-23 17:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4a2b4e7a831 6431344: (fc) FileChannel.transferTo() doesn't work if address space runs out Reviewed-by: forax, chegar ! src/share/classes/sun/nio/ch/FileChannelImpl.java From jonathan.gibbons at oracle.com Mon Aug 23 11:57:57 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 23 Aug 2010 18:57:57 +0000 Subject: hg: jdk7/tl/langtools: 6975005: improve JavacProcessingEnvironment.Round abstraction Message-ID: <20100823185759.33223473C0@hg.openjdk.java.net> Changeset: 6b95dd682538 Author: jjg Date: 2010-08-23 11:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6b95dd682538 6975005: improve JavacProcessingEnvironment.Round abstraction Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6403466.out ! test/tools/javac/processing/filer/TestLastRound.out From kumar.x.srinivasan at oracle.com Mon Aug 23 12:44:11 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 23 Aug 2010 19:44:11 +0000 Subject: hg: jdk7/tl/jdk: 6531345: Memory leak in unpack200 Message-ID: <20100823194420.90502473C2@hg.openjdk.java.net> Changeset: 6317f7e2c4fd Author: ksrini Date: 2010-08-23 08:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6317f7e2c4fd 6531345: Memory leak in unpack200 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java + test/tools/pack200/UnpackerMemoryTest.java ! test/tools/pack200/Utils.java From chris.hegarty at oracle.com Mon Aug 23 14:00:32 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 23 Aug 2010 21:00:32 +0000 Subject: hg: jdk7/tl/jdk: 6977851: NPE from FileURLConnection.connect Message-ID: <20100823210042.D30B2473C8@hg.openjdk.java.net> Changeset: cb67f0263bd4 Author: chegar Date: 2010-08-23 21:59 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb67f0263bd4 6977851: NPE from FileURLConnection.connect Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java + test/sun/net/www/protocol/file/DirPermissionDenied.java + test/sun/net/www/protocol/file/DirPermissionDenied.sh From jonathan.gibbons at oracle.com Mon Aug 23 15:13:31 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 23 Aug 2010 22:13:31 +0000 Subject: hg: jdk7/tl/langtools: 6976747: JCDiagnostic: replace "boolean mandatory" with new "Set" Message-ID: <20100823221333.A95CE473CB@hg.openjdk.java.net> Changeset: a626d8c1de6e Author: jjg Date: 2010-08-23 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a626d8c1de6e 6976747: JCDiagnostic: replace "boolean mandatory" with new "Set" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java From kumar.x.srinivasan at oracle.com Mon Aug 23 17:21:38 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 24 Aug 2010 00:21:38 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100824002158.9C155473D2@hg.openjdk.java.net> Changeset: 2585368bfc7c Author: ksrini Date: 2010-08-23 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2585368bfc7c 6969063: (pack200) The default value of Pack200.Packer.SEGMENT_LIMIT property is empty string instead of -1 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java + test/tools/pack200/Pack200Props.java - test/tools/pack200/SegmentLimit.java Changeset: 732f59013e78 Author: ksrini Date: 2010-08-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/732f59013e78 6966740: (pack200) need to add the timezone regression test Reviewed-by: jrose + test/tools/pack200/TimeStamp.java ! test/tools/pack200/Utils.java From ahughes at redhat.com Tue Aug 24 05:29:08 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Tue, 24 Aug 2010 12:29:08 +0000 Subject: hg: jdk7/tl: 6976186: Integrate Shark Message-ID: <20100824122908.2F04A473ED@hg.openjdk.java.net> Changeset: 1fbed32d2ddd Author: gbenson Date: 2010-08-24 13:27 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/rev/1fbed32d2ddd 6976186: Integrate Shark Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure. Reviewed-by: ohair ! make/hotspot-rules.gmk From jonathan.gibbons at oracle.com Tue Aug 24 11:31:02 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 24 Aug 2010 18:31:02 +0000 Subject: hg: jdk7/tl/langtools: 6935638: -implicit:none prevents compilation with annotation processing Message-ID: <20100824183104.4CEC8473FD@hg.openjdk.java.net> Changeset: e9d09e97d669 Author: jjg Date: 2010-08-24 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e9d09e97d669 6935638: -implicit:none prevents compilation with annotation processing Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/processing/options/TestImplicitNone.java From jonathan.gibbons at oracle.com Tue Aug 24 15:09:37 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 24 Aug 2010 22:09:37 +0000 Subject: hg: jdk7/tl/langtools: 6929404: Filer.getResource(SOURCE_PATH, ...) does not work when -sourcepath contains >1 entry Message-ID: <20100824220939.CA0CE47405@hg.openjdk.java.net> Changeset: f3323b1c65ee Author: jjg Date: 2010-08-24 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f3323b1c65ee 6929404: Filer.getResource(SOURCE_PATH, ...) does not work when -sourcepath contains >1 entry Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java + test/tools/javac/processing/filer/TestGetResource2.java From jonathan.gibbons at oracle.com Wed Aug 25 11:24:31 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 25 Aug 2010 18:24:31 +0000 Subject: hg: jdk7/tl/langtools: 6979564: ":" for path separator in dist/bin/javac does not work on Windows Message-ID: <20100825182439.D167E47433@hg.openjdk.java.net> Changeset: 6ef801fa38b7 Author: jjg Date: 2010-08-25 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6ef801fa38b7 6979564: ":" for path separator in dist/bin/javac does not work on Windows Reviewed-by: jjh ! make/build.xml ! src/share/bin/launcher.sh-template From jonathan.gibbons at oracle.com Wed Aug 25 11:40:42 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 25 Aug 2010 18:40:42 +0000 Subject: hg: jdk7/tl/langtools: 6960424: new option -Xpkginfo for better control of when package-info.class is generated Message-ID: <20100825184044.1AF2847435@hg.openjdk.java.net> Changeset: 70ebdef189c9 Author: jjg Date: 2010-08-25 11:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/70ebdef189c9 6960424: new option -Xpkginfo for better control of when package-info.class is generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/TestPkgInfo.java From joe.darcy at oracle.com Wed Aug 25 15:36:04 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 25 Aug 2010 22:36:04 +0000 Subject: hg: jdk7/tl/jdk: 6980019: Finish rename of ARM -> try-with-resources in jdk repository Message-ID: <20100825223613.A1FB447440@hg.openjdk.java.net> Changeset: 93c49f01a4c2 Author: darcy Date: 2010-08-25 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93c49f01a4c2 6980019: Finish rename of ARM -> try-with-resources in jdk repository Reviewed-by: jjg ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java From naoto.sato at oracle.com Wed Aug 25 15:35:33 2010 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 25 Aug 2010 22:35:33 +0000 Subject: hg: jdk7/tl/langtools: 6875847: Java Locale Enhancement Message-ID: <20100825223535.1EC594743F@hg.openjdk.java.net> Changeset: ecff24121064 Author: naoto Date: 2010-08-25 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ecff24121064 6875847: Java Locale Enhancement Summary: Fix for javac to allow "sun.util.locale" package accessible. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/resources/legacy.properties From jonathan.gibbons at oracle.com Thu Aug 26 15:17:47 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 26 Aug 2010 22:17:47 +0000 Subject: hg: jdk7/tl/langtools: 6604599: ToolProvider should be less compiler-specific Message-ID: <20100826221748.E1EAC4747A@hg.openjdk.java.net> Changeset: cfd047f3cf60 Author: jjg Date: 2010-08-26 15:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cfd047f3cf60 6604599: ToolProvider should be less compiler-specific Reviewed-by: darcy ! src/share/classes/javax/tools/ToolProvider.java + test/tools/javac/api/ToolProvider/HelloWorldTest.java + test/tools/javac/api/ToolProvider/ToolProviderTest1.java + test/tools/javac/api/ToolProvider/ToolProviderTest2.java From scolebourne at joda.org Thu Aug 26 16:10:47 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 27 Aug 2010 00:10:47 +0100 Subject: Eclipse vs Javac difference Message-ID: I'm currently seeing a difference between Eclipse and Javac and am trying to determine who is at fault, and how to work around it. The code in question is at Joda Primitives - http://joda-primitives.svn.sourceforge.net/viewvc/joda-primitives/trunk/JodaPrimitives/?pathrev=30 Running maven - mvn package - shows the problem (it compiles in Eclipse 3.5.0 and not in javac 1.6.0_13-b03) \dev\joda\primitives\src\test\java\org\joda\primitives\list\impl\AbstractTestBooleanList.java:[76,39] reference to iterator is ambiguous, both method iterator() in org.joda.primitives.collection.BooleanCollection and method iterator() in java.util.List match The code includes an interface BooleanCollection that extends interface PrimitiveCollection, which extends Collection. The iterator() method is overridden covariantly in BooleanCollection to return BooleanIterator, a subinterface of PrimitiveIterator and Iterator. Any ideas? The svn repo is available to view (Apache 2 license). Stephen From jonathan.gibbons at oracle.com Thu Aug 26 16:13:57 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 26 Aug 2010 23:13:57 +0000 Subject: hg: jdk7/tl/langtools: 6980017: javap -XDdetail:source behaves badly if source not available. Message-ID: <20100826231402.47CB34747F@hg.openjdk.java.net> Changeset: ae3acbf63943 Author: jjg Date: 2010-08-26 16:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ae3acbf63943 6980017: javap -XDdetail:source behaves badly if source not available. Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java + test/tools/javap/T6980017.java From jonathan.gibbons at oracle.com Thu Aug 26 17:11:26 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Aug 2010 17:11:26 -0700 Subject: Eclipse vs Javac difference In-Reply-To: References: Message-ID: <4C7702AE.5030203@oracle.com> Stephen, Have you tried versions of JDK, such as OpenJDK 6 or OpenJDK 7? Can you boil the code down to a simple example which illustrates the different behavior? -- Jon On 08/26/2010 04:10 PM, Stephen Colebourne wrote: > I'm currently seeing a difference between Eclipse and Javac and am > trying to determine who is at fault, and how to work around it. > > The code in question is at Joda Primitives - > http://joda-primitives.svn.sourceforge.net/viewvc/joda-primitives/trunk/JodaPrimitives/?pathrev=30 > > Running maven - mvn package - shows the problem (it compiles in > Eclipse 3.5.0 and not in javac 1.6.0_13-b03) > > \dev\joda\primitives\src\test\java\org\joda\primitives\list\impl\AbstractTestBooleanList.java:[76,39] > reference to iterator is ambiguous, both method iterator() in > org.joda.primitives.collection.BooleanCollection and method iterator() > in java.util.List match > > The code includes an interface BooleanCollection that extends > interface PrimitiveCollection, which extends Collection. The > iterator() method is overridden covariantly in BooleanCollection to > return BooleanIterator, a subinterface of PrimitiveIterator > and Iterator. > > Any ideas? The svn repo is available to view (Apache 2 license). > Stephen > From lists at laerad.com Fri Aug 27 00:39:22 2010 From: lists at laerad.com (Benedict Elliott Smith) Date: Fri, 27 Aug 2010 08:39:22 +0100 Subject: Eclipse vs Javac difference In-Reply-To: <4C7702AE.5030203@oracle.com> References: <4C7702AE.5030203@oracle.com> Message-ID: This is something that bit me once - if you implement two methods from different interfaces with the same erasure, the JDK6 compiler barfs. It has definitely been fixed, but I think only in JDK7. On 27 August 2010 01:11, Jonathan Gibbons wrote: > Stephen, > > Have you tried versions of JDK, such as OpenJDK 6 or OpenJDK 7? > > Can you boil the code down to a simple example which illustrates the > different behavior? > > -- Jon > > > On 08/26/2010 04:10 PM, Stephen Colebourne wrote: > >> I'm currently seeing a difference between Eclipse and Javac and am >> trying to determine who is at fault, and how to work around it. >> >> The code in question is at Joda Primitives - >> >> http://joda-primitives.svn.sourceforge.net/viewvc/joda-primitives/trunk/JodaPrimitives/?pathrev=30 >> >> Running maven - mvn package - shows the problem (it compiles in >> Eclipse 3.5.0 and not in javac 1.6.0_13-b03) >> >> >> \dev\joda\primitives\src\test\java\org\joda\primitives\list\impl\AbstractTestBooleanList.java:[76,39] >> reference to iterator is ambiguous, both method iterator() in >> org.joda.primitives.collection.BooleanCollection and method iterator() >> in java.util.List match >> >> The code includes an interface BooleanCollection that extends >> interface PrimitiveCollection, which extends Collection. The >> iterator() method is overridden covariantly in BooleanCollection to >> return BooleanIterator, a subinterface of PrimitiveIterator >> and Iterator. >> >> Any ideas? The svn repo is available to view (Apache 2 license). >> Stephen >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100827/fd86c176/attachment.html From scolebourne at joda.org Fri Aug 27 02:06:08 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 27 Aug 2010 10:06:08 +0100 Subject: Eclipse vs Javac difference In-Reply-To: References: <4C7702AE.5030203@oracle.com> Message-ID: That sounds similar to the problem Benedict - one method inherited from two interfaces, one with a generic definition Iterator and one with an extension of that BooleanIterator. I assume the convariant return type isn't picked up after the erasure occurs. I have limited internet connection, so can't search the bug database to find the reference. This will be very difficult to work around I suspect. Stephen On 27 August 2010 08:39, Benedict Elliott Smith wrote: > This is something that bit me once - if you implement two > methods?from?different interfaces?with the same erasure, the JDK6 compiler > barfs. It has definitely been fixed, but I think only in JDK7. > > > On 27 August 2010 01:11, Jonathan Gibbons > wrote: >> >> Stephen, >> >> Have you tried versions of JDK, such as OpenJDK 6 or OpenJDK 7? >> >> Can you boil the code down to a simple example which illustrates the >> different behavior? >> >> -- Jon >> >> On 08/26/2010 04:10 PM, Stephen Colebourne wrote: >>> >>> I'm currently seeing a difference between Eclipse and Javac and am >>> trying to determine who is at fault, and how to work around it. >>> >>> The code in question is at Joda Primitives - >>> >>> http://joda-primitives.svn.sourceforge.net/viewvc/joda-primitives/trunk/JodaPrimitives/?pathrev=30 >>> >>> Running maven - mvn package - shows the problem (it compiles in >>> Eclipse 3.5.0 and not in javac 1.6.0_13-b03) >>> >>> >>> \dev\joda\primitives\src\test\java\org\joda\primitives\list\impl\AbstractTestBooleanList.java:[76,39] >>> reference to iterator is ambiguous, both method iterator() in >>> org.joda.primitives.collection.BooleanCollection and method iterator() >>> in java.util.List ?match >>> >>> The code includes an interface BooleanCollection that extends >>> interface PrimitiveCollection, which extends Collection. The >>> iterator() method is overridden covariantly in BooleanCollection to >>> return BooleanIterator, a subinterface of PrimitiveIterator >>> and Iterator. >>> >>> Any ideas? The svn repo is available to view (Apache 2 license). >>> Stephen >>> >> > > From maurizio.cimadamore at oracle.com Fri Aug 27 03:59:57 2010 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 27 Aug 2010 11:59:57 +0100 Subject: Eclipse vs Javac difference In-Reply-To: References: <4C7702AE.5030203@oracle.com> Message-ID: <4C779AAD.2080206@oracle.com> Here's a reduced test case: import java.util.*; interface BooleanList extends List, BooleanCollection { } interface BooleanCollection extends Collection { BooleanIterator iterator(); } interface BooleanIterator extends Iterator { } class Test { void test(BooleanList plist) { BooleanIterator it = plist.iterator(); } } This is a duplicate of the following bug: http://bugs.sun.com/view_bug.do?bug_id=6487370 Which is fixed in JDK 7. Maurizio On 27/08/10 10:06, Stephen Colebourne wrote: > That sounds similar to the problem Benedict - one method inherited > from two interfaces, one with a generic definition Iterator and one > with an extension of that BooleanIterator. I assume the convariant > return type isn't picked up after the erasure occurs. > > I have limited internet connection, so can't search the bug database > to find the reference. This will be very difficult to work around I > suspect. > > Stephen > > > On 27 August 2010 08:39, Benedict Elliott Smith wrote: > >> This is something that bit me once - if you implement two >> methods from different interfaces with the same erasure, the JDK6 compiler >> barfs. It has definitely been fixed, but I think only in JDK7. >> >> >> On 27 August 2010 01:11, Jonathan Gibbons >> wrote: >> >>> Stephen, >>> >>> Have you tried versions of JDK, such as OpenJDK 6 or OpenJDK 7? >>> >>> Can you boil the code down to a simple example which illustrates the >>> different behavior? >>> >>> -- Jon >>> >>> On 08/26/2010 04:10 PM, Stephen Colebourne wrote: >>> >>>> I'm currently seeing a difference between Eclipse and Javac and am >>>> trying to determine who is at fault, and how to work around it. >>>> >>>> The code in question is at Joda Primitives - >>>> >>>> http://joda-primitives.svn.sourceforge.net/viewvc/joda-primitives/trunk/JodaPrimitives/?pathrev=30 >>>> >>>> Running maven - mvn package - shows the problem (it compiles in >>>> Eclipse 3.5.0 and not in javac 1.6.0_13-b03) >>>> >>>> >>>> \dev\joda\primitives\src\test\java\org\joda\primitives\list\impl\AbstractTestBooleanList.java:[76,39] >>>> reference to iterator is ambiguous, both method iterator() in >>>> org.joda.primitives.collection.BooleanCollection and method iterator() >>>> in java.util.List match >>>> >>>> The code includes an interface BooleanCollection that extends >>>> interface PrimitiveCollection, which extends Collection. The >>>> iterator() method is overridden covariantly in BooleanCollection to >>>> return BooleanIterator, a subinterface of PrimitiveIterator >>>> and Iterator. >>>> >>>> Any ideas? The svn repo is available to view (Apache 2 license). >>>> Stephen >>>> >>>> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20100827/cf781436/attachment.html From jonathan.gibbons at oracle.com Fri Aug 27 17:15:21 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 28 Aug 2010 00:15:21 +0000 Subject: hg: jdk7/tl/langtools: 6980724: test/tools/javac/InterfaceAssert.java sometimes fails Message-ID: <20100828001523.5E57B474CE@hg.openjdk.java.net> Changeset: 3a9f319be48a Author: jjg Date: 2010-08-27 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3a9f319be48a 6980724: test/tools/javac/InterfaceAssert.java sometimes fails Reviewed-by: darcy ! test/tools/javac/InterfaceAssert.java From jonathan.gibbons at oracle.com Fri Aug 27 17:21:05 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 28 Aug 2010 00:21:05 +0000 Subject: hg: jdk7/tl/langtools: 6570730: com.sun.source.tree.ModifiersTree.getFlags() should return class type Message-ID: <20100828002107.6DB23474CF@hg.openjdk.java.net> Changeset: b4e7a57af8df Author: jjg Date: 2010-08-27 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b4e7a57af8df 6570730: com.sun.source.tree.ModifiersTree.getFlags() should return class type Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java - test/tools/javac/T6341023.java + test/tools/javac/tree/ClassTreeTest.java + test/tools/javac/tree/TreeKindTest.java From jonathan.gibbons at oracle.com Fri Aug 27 17:59:21 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 28 Aug 2010 00:59:21 +0000 Subject: hg: jdk7/tl/langtools: 6980707: Reduce use of IOException in JavaCompiler Message-ID: <20100828005922.F1F49474D2@hg.openjdk.java.net> Changeset: eb7c263aab73 Author: jjg Date: 2010-08-27 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/eb7c263aab73 6980707: Reduce use of IOException in JavaCompiler Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/FatalError.java ! test/tools/javac/diags/examples.not-yet.txt From martinrb at google.com Sat Aug 28 12:20:29 2010 From: martinrb at google.com (martinrb at google.com) Date: Sat, 28 Aug 2010 19:20:29 +0000 Subject: hg: jdk7/tl/jdk: 6980747: Runtime.exec can fail due to SecurityException (lnx) Message-ID: <20100828192038.BD37F474F8@hg.openjdk.java.net> Changeset: 1470dffe6551 Author: martin Date: 2010-08-28 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1470dffe6551 6980747: Runtime.exec can fail due to SecurityException (lnx) Summary: Add missing doPrivileged to UNIXProcess.java.linux Reviewed-by: alanb ! src/solaris/classes/java/lang/UNIXProcess.java.linux + test/java/lang/ProcessBuilder/SecurityManagerClinit.java From weijun.wang at sun.com Mon Aug 30 00:29:59 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Mon, 30 Aug 2010 07:29:59 +0000 Subject: hg: jdk7/tl/jdk: 6911951: NTLM should be a supported Java SASL mechanism Message-ID: <20100830073009.75A1047541@hg.openjdk.java.net> Changeset: 9be643e70f42 Author: weijun Date: 2010-08-30 14:37 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9be643e70f42 6911951: NTLM should be a supported Java SASL mechanism Reviewed-by: vinnie, michaelm + src/share/classes/com/sun/security/ntlm/Client.java + src/share/classes/com/sun/security/ntlm/NTLM.java + src/share/classes/com/sun/security/ntlm/NTLMException.java + src/share/classes/com/sun/security/ntlm/Server.java + src/share/classes/com/sun/security/ntlm/Version.java ! src/share/classes/com/sun/security/sasl/Provider.java + src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java + src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java + src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java + test/com/sun/security/sasl/ntlm/NTLMTest.java From jonathan.gibbons at oracle.com Mon Aug 30 18:03:57 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 31 Aug 2010 01:03:57 +0000 Subject: hg: jdk7/tl/langtools: 6403465: javac should defer diagnostics until it can be determined they are persistent Message-ID: <20100831010359.3E5A947568@hg.openjdk.java.net> Changeset: 4124840b35fe Author: jjg Date: 2010-08-30 18:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4124840b35fe 6403465: javac should defer diagnostics until it can be determined they are persistent Reviewed-by: mcimadamore, darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/processing/6430209/b6341534.java + test/tools/javac/processing/errors/TestSuppression.java From jonathan.gibbons at oracle.com Mon Aug 30 19:21:54 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Aug 2010 19:21:54 -0700 Subject: Additional -Xlint:serial warning In-Reply-To: <82y6cm1ts1.fsf@mid.bfk.de> References: <82y6cm1ts1.fsf@mid.bfk.de> Message-ID: <4C7C6742.2050302@oracle.com> On 08/04/2010 04:50 AM, Florian Weimer wrote: > The JLS does not provide binary compatibility for compiler-generated > fields (such as reference to an outer class object from an inner class > object). This means that there is no reliable way to use such classes > in serialization even if all involved classes implement > java.io.Serializable. A mere recompilation of unchanged sources might > result in different compiler-generated names. > > Would it make sense to enhance -Xlint:serial to warn about classes > which implement java.io.Serializable and contain compiler-generated > fields? > > PS: This is quite different from the frequently observed issue where a > non-static inner class cannot be serialized because the outer class is > not serializable. Serialization works fine, but deserialization > silently results in invalid objects. > > Filed as issue 6981095, it should be visible on bugs.sun.com in the next few days. -- Jon From mandy.chung at oracle.com Tue Aug 31 09:19:33 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 31 Aug 2010 16:19:33 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100831161952.0AC864758A@hg.openjdk.java.net> Changeset: 6586ab5b79f4 Author: mchung Date: 2010-08-31 09:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6586ab5b79f4 6981005: TEST BUG: java/lang/ClassLoader/TestCrossDelegate.sh timeout on windows Summary: Increase timeout value Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh Changeset: def50d3ad78e Author: mchung Date: 2010-08-31 09:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/def50d3ad78e 6977548: Broken link in ClassLoader.defineClass javadoc Reviewed-by: valeriep ! src/share/classes/java/lang/ClassLoader.java From kelly.ohair at oracle.com Tue Aug 31 15:51:20 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 31 Aug 2010 22:51:20 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20100831225121.E937F475A2@hg.openjdk.java.net> Changeset: 519daea48888 Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/519daea48888 Added tag jdk7-b105 for changeset 6f21b030092f ! .hgtags Changeset: 0f60cf26c5b5 Author: ohair Date: 2010-08-30 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0f60cf26c5b5 6981043: Clean out all native code makefile logic from corba repository Reviewed-by: jjg ! make/Makefile ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk - make/common/Library.gmk - make/common/Mapfile-vers.gmk ! make/common/Rules.gmk - make/common/internal/NativeCompileRules.gmk - make/common/shared/Compiler-gcc.gmk - make/common/shared/Compiler-msvc.gmk - make/common/shared/Compiler-sun.gmk - make/common/shared/Compiler.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk ! make/org/omg/idl/Makefile From kelly.ohair at oracle.com Tue Aug 31 15:49:35 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 31 Aug 2010 22:49:35 +0000 Subject: hg: jdk7/tl/jaxws: 6962317: jdk7 jaxws source bundle still needs rebranding; ... Message-ID: <20100831224935.D045B475A0@hg.openjdk.java.net> Changeset: c6c2f9094bdd Author: ohair Date: 2010-08-30 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/c6c2f9094bdd 6962317: jdk7 jaxws source bundle still needs rebranding 6955300: Missing files in the jaf source bundle Reviewed-by: ramap ! jaxws.properties