From jhs at edg.com Thu May 1 14:32:35 2014
From: jhs at edg.com (John Spicer)
Date: Thu, 1 May 2014 10:32:35 -0400
Subject: Annotations on generic constructors
Message-ID: <73C228F2-D310-485B-8FBD-83787806F36F@edg.com>
javac accepts this usage:
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;
@Target(ElementType.TYPE_USE)
@interface T { }
class X {
@T X() { }
}
but that seems to be prohibited by the constructor declaration syntax, which only allows annotations before the TypeParameters.
Should this case be rejected?
John Spicer
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From tom.schindl at bestsolution.at Thu May 1 16:11:05 2014
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 01 May 2014 18:11:05 +0200
Subject: Possible Bug in javac unchecked cast detection
Message-ID: <53627219.10500@bestsolution.at>
Hi,
While cleaning up the javafx codebase (who has a lot of use of generics)
I came across casts the eclipse java compiler marks as unchecked while
javac -Xlint:all does not warn about.
The following snippet shows gist of the problem:
> package a;
>
> public class CastTest {
> public interface BaseInterface {
>
> }
>
> public interface SubInterfaceA extends BaseInterface {
>
> }
>
> public interface SubInterfaceB extends BaseInterface {
>
> }
>
> public static void main(String[] args) {
> SubInterfaceA a = null;
> SubInterfaceB b = (SubInterfaceB) a; // javac does not warn
> b = (SubInterfaceB)(BaseInterface)a;
>
> }
> }
I first thought of a bug in the eclipse compiler but they claim their
compiler is correct because the spec says:
> "A cast from a type S to a parameterized type (?4.5) T is unchecked
> unless at least one of the following is true:
> * S <: T
> * All of the type arguments (?4.5.1) of T are unbounded wildcards
> * T <: S and S has no subtype X other than T where the type arguments
> of X are not contained in the type arguments of T."
So before fileing a bug and start fixing the javafx code I wanted to get
feedback from the compiler gurus on this list who is right and who is wrong.
Thanks
Tom
From alex.buckley at oracle.com Thu May 1 18:41:24 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 01 May 2014 11:41:24 -0700
Subject: Possible Bug in javac unchecked cast detection
In-Reply-To: <53627219.10500@bestsolution.at>
References: <53627219.10500@bestsolution.at>
Message-ID: <53629554.7050208@oracle.com>
Eclipse is right. Given the interface declarations below, a cast from
SubInterfaceA to SubInterfaceB is unchecked. By JLS
5.5.2, an unchecked warning is due unless @SuppressWarnings is in
effect; lint mode doesn't matter.
Alex
On 5/1/2014 9:11 AM, Tom Schindl wrote:
> Hi,
>
> While cleaning up the javafx codebase (who has a lot of use of generics)
> I came across casts the eclipse java compiler marks as unchecked while
> javac -Xlint:all does not warn about.
>
> The following snippet shows gist of the problem:
>
>> package a;
>>
>> public class CastTest {
>> public interface BaseInterface {
>>
>> }
>>
>> public interface SubInterfaceA extends BaseInterface {
>>
>> }
>>
>> public interface SubInterfaceB extends BaseInterface {
>>
>> }
>>
>> public static void main(String[] args) {
>> SubInterfaceA a = null;
>> SubInterfaceB b = (SubInterfaceB) a; // javac does not warn
>> b = (SubInterfaceB)(BaseInterface)a;
>>
>> }
>> }
>
> I first thought of a bug in the eclipse compiler but they claim their
> compiler is correct because the spec says:
>
>
>> "A cast from a type S to a parameterized type (?4.5) T is unchecked
>> unless at least one of the following is true:
>> * S <: T
>> * All of the type arguments (?4.5.1) of T are unbounded wildcards
>> * T <: S and S has no subtype X other than T where the type arguments
>> of X are not contained in the type arguments of T."
>
> So before fileing a bug and start fixing the javafx code I wanted to get
> feedback from the compiler gurus on this list who is right and who is wrong.
>
> Thanks
>
> Tom
>
From alex.buckley at oracle.com Thu May 1 18:52:01 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 01 May 2014 11:52:01 -0700
Subject: Annotations on generic constructors
In-Reply-To: <73C228F2-D310-485B-8FBD-83787806F36F@edg.com>
References: <73C228F2-D310-485B-8FBD-83787806F36F@edg.com>
Message-ID: <536297D1.2010200@oracle.com>
See the thread "Queries about JDK-8035890" on type-annotations-dev:
http://mail.openjdk.java.net/pipermail/type-annotations-dev/2014-March/thread.html.
I wouldn't bet on javac allowing that @T for much longer. (I assumed
Werner would file a spec bug, but that has not happened.)
Alex
On 5/1/2014 7:32 AM, John Spicer wrote:
> javac accepts this usage:
>
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Target;
> @Target(ElementType.TYPE_USE)
> @interface T { }
> class X {
> @T X() { }
> }
>
> but that seems to be prohibited by the constructor declaration syntax,
> which only allows annotations before the TypeParameters.
>
> Should this case be rejected?
>
> John Spicer
From tom.schindl at bestsolution.at Fri May 2 08:12:08 2014
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Fri, 02 May 2014 10:12:08 +0200
Subject: Possible Bug in javac unchecked cast detection
In-Reply-To: <53629554.7050208@oracle.com>
References: <53627219.10500@bestsolution.at> <53629554.7050208@oracle.com>
Message-ID: <53635358.7010706@bestsolution.at>
Hi Alex,
Thanks for the confirmation. I'll file a bug against javac then. What I
don't yet understand how one can fix such a situation without a warning
or why JLS does not allow the cast.
I can fix the unchecked warning with but then (if turned on in my
Eclipse I get a warning about an unnecessary typecast - so do IntelliJ
users)
b = (SubInterfaceB)(BaseInterface)a;
which of course is correct because one does not need to cast
SubInterfaceA to BaseInterface. The only solution to work without
any warning suppression is using an intermediate variable.
BaseInterface temp = a;
b = (SubInterfaceB)temp;
what i don't fully grasp then why JLS does not directly allow me to cast
from SubInterfaceA to SubInterfaceB.
Tom
On 01.05.14 20:41, Alex Buckley wrote:
> Eclipse is right. Given the interface declarations below, a cast from
> SubInterfaceA to SubInterfaceB is unchecked. By JLS
> 5.5.2, an unchecked warning is due unless @SuppressWarnings is in
> effect; lint mode doesn't matter.
>
> Alex
>
> On 5/1/2014 9:11 AM, Tom Schindl wrote:
>> Hi,
>>
>> While cleaning up the javafx codebase (who has a lot of use of generics)
>> I came across casts the eclipse java compiler marks as unchecked while
>> javac -Xlint:all does not warn about.
>>
>> The following snippet shows gist of the problem:
>>
>>> package a;
>>>
>>> public class CastTest {
>>> public interface BaseInterface {
>>>
>>> }
>>>
>>> public interface SubInterfaceA extends BaseInterface {
>>>
>>> }
>>>
>>> public interface SubInterfaceB extends BaseInterface {
>>>
>>> }
>>>
>>> public static void main(String[] args) {
>>> SubInterfaceA a = null;
>>> SubInterfaceB b = (SubInterfaceB) a; // javac
>>> does not warn
>>> b = (SubInterfaceB)(BaseInterface)a;
>>>
>>> }
>>> }
>>
>> I first thought of a bug in the eclipse compiler but they claim their
>> compiler is correct because the spec says:
>>
>>
>>> "A cast from a type S to a parameterized type (?4.5) T is unchecked
>>> unless at least one of the following is true:
>>> * S <: T
>>> * All of the type arguments (?4.5.1) of T are unbounded wildcards
>>> * T <: S and S has no subtype X other than T where the type
>>> arguments
>>> of X are not contained in the type arguments of T."
>>
>> So before fileing a bug and start fixing the javafx code I wanted to get
>> feedback from the compiler gurus on this list who is right and who is
>> wrong.
>>
>> Thanks
>>
>> Tom
>>
From alex.buckley at oracle.com Fri May 2 19:55:29 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 02 May 2014 12:55:29 -0700
Subject: Possible Bug in javac unchecked cast detection
In-Reply-To: <53635358.7010706@bestsolution.at>
References: <53627219.10500@bestsolution.at> <53629554.7050208@oracle.com>
<53635358.7010706@bestsolution.at>
Message-ID: <5363F831.1040400@oracle.com>
If none of the interface declarations were generic, then the language
would happily accept the cast from SubInterfaceA to SubInterfaceB; as
JLS 5.5.1 says, "the cast is always legal at compile time (because even
if T does not implement S, a subclass of T might)."
With generic declarations, the unchecked cast rules come into play,
aiming to warn you if anything happens that could possibly lead to a
ClassCastException at run time. These rules could have been smarter, to
detect the common superinterface of SubInterfaceA and
SubInterfaceB, but that decision was not taken in 1998.
Alex
On 5/2/2014 1:12 AM, Tom Schindl wrote:
> Hi Alex,
>
> Thanks for the confirmation. I'll file a bug against javac then. What I
> don't yet understand how one can fix such a situation without a warning
> or why JLS does not allow the cast.
>
> I can fix the unchecked warning with but then (if turned on in my
> Eclipse I get a warning about an unnecessary typecast - so do IntelliJ
> users)
>
> b = (SubInterfaceB)(BaseInterface)a;
>
> which of course is correct because one does not need to cast
> SubInterfaceA to BaseInterface. The only solution to work without
> any warning suppression is using an intermediate variable.
>
> BaseInterface temp = a;
> b = (SubInterfaceB)temp;
>
> what i don't fully grasp then why JLS does not directly allow me to cast
> from SubInterfaceA to SubInterfaceB.
>
> Tom
>
> On 01.05.14 20:41, Alex Buckley wrote:
>> Eclipse is right. Given the interface declarations below, a cast from
>> SubInterfaceA to SubInterfaceB is unchecked. By JLS
>> 5.5.2, an unchecked warning is due unless @SuppressWarnings is in
>> effect; lint mode doesn't matter.
>>
>> Alex
>>
>> On 5/1/2014 9:11 AM, Tom Schindl wrote:
>>> Hi,
>>>
>>> While cleaning up the javafx codebase (who has a lot of use of generics)
>>> I came across casts the eclipse java compiler marks as unchecked while
>>> javac -Xlint:all does not warn about.
>>>
>>> The following snippet shows gist of the problem:
>>>
>>>> package a;
>>>>
>>>> public class CastTest {
>>>> public interface BaseInterface {
>>>>
>>>> }
>>>>
>>>> public interface SubInterfaceA extends BaseInterface {
>>>>
>>>> }
>>>>
>>>> public interface SubInterfaceB extends BaseInterface {
>>>>
>>>> }
>>>>
>>>> public static void main(String[] args) {
>>>> SubInterfaceA a = null;
>>>> SubInterfaceB b = (SubInterfaceB) a; // javac
>>>> does not warn
>>>> b = (SubInterfaceB)(BaseInterface)a;
>>>>
>>>> }
>>>> }
>>>
>>> I first thought of a bug in the eclipse compiler but they claim their
>>> compiler is correct because the spec says:
>>>
>>>
>>>> "A cast from a type S to a parameterized type (?4.5) T is unchecked
>>>> unless at least one of the following is true:
>>>> * S <: T
>>>> * All of the type arguments (?4.5.1) of T are unbounded wildcards
>>>> * T <: S and S has no subtype X other than T where the type
>>>> arguments
>>>> of X are not contained in the type arguments of T."
>>>
>>> So before fileing a bug and start fixing the javafx code I wanted to get
>>> feedback from the compiler gurus on this list who is right and who is
>>> wrong.
>>>
>>> Thanks
>>>
>>> Tom
>>>
>
From jonathan.gibbons at oracle.com Fri May 2 22:01:17 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 02 May 2014 15:01:17 -0700
Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily
complex and platform dependent way
In-Reply-To: <20140430133307.GA13604@e6430>
References: <20140430133307.GA13604@e6430>
Message-ID: <536415AD.4070107@oracle.com>
The code to use NUL or /dev/null is somewhat icky. Is that actually the
behavior you want?
How about using ProcessBuilder.Redirect.INHERIT instead?
-- Jon
On 04/30/2014 06:33 AM, Andreas Lundblad wrote:
> Hi compiler-dev,
>
> Please review this small fix for JDK-8042088 which changes how sjavac spawns background processes.
>
> Description:
> Sjavac starts a background server through a shell (cmd on windows, and /bin/sh on other systems). This patch changes this so that the background service is launched directly instead.
>
> Link to webrev:
> http://cr.openjdk.java.net/~alundblad/8042088
>
> Link to bug report:
> https://bugs.openjdk.java.net/browse/JDK-8042088
>
> -- Andreas
From andreas.lundblad at oracle.com Mon May 5 09:17:59 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Mon, 5 May 2014 11:17:59 +0200
Subject: RFR: 8042088: Sjavac spawns external processes in a
unnecessarily complex and platform dependent way
In-Reply-To: <536415AD.4070107@oracle.com>
References: <20140430133307.GA13604@e6430>
<536415AD.4070107@oracle.com>
Message-ID: <20140505091758.GB13904@e6430>
On Fri, May 02, 2014 at 03:01:17PM -0700, Jonathan Gibbons wrote:
> The code to use NUL or /dev/null is somewhat icky. Is that actually
> the behavior you want?
> How about using ProcessBuilder.Redirect.INHERIT instead?
I don't think we want the output of the background sjavac server to be interleaved with the output of the sjavac instance that spawned it. (Especially since the log of the background server would be chopped off once the foreground process terminates.)
The reason I can't simply leave the whole redirect logic out is because the background process halts once it's output buffer is full. The output of the background process *has* to be consumed in one way or another. I could solve this by spawning a separate thread in the foreground process whose sole purpose is to read and discand output from the background process:
Thread discardOutputThread = new Thread() {
public void run() {
InputStream is = p.getInputStream();
try { while (is.read() != -1); }
catch (IOException e) { }
}
};
discardOutputThread.setDaemon(true);
discardOutputThread.start();
It just feels a bit awkward to leave a running dummy thread behind, and I can't find any documentation on what happens when the foreground process terminates and this thread stops. (Although it *did* work on when I tested it on Windows 2003 and Ubuntu.)
So, while the NUL or /dev/null workaround does have a grain of platform dependency, I still thought it was the cleanest solution. I'm ready to reconsider this if others think differently.
I'm somewhat surprised that there is no ProcessBuilder.Redirect.DISCARD. Does anybody know why such option is "missing"? :-(
-- Andreas
From oehrstroem at gmail.com Mon May 5 11:18:03 2014
From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Mon, 5 May 2014 13:18:03 +0200
Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily
complex and platform dependent way
In-Reply-To: <20140505091758.GB13904@e6430>
References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com>
<20140505091758.GB13904@e6430>
Message-ID:
The output from stdout and stderr from the background must always be logged
into a file. The default name for that file is portfile+".stdouterr"
Thus you could replace stdouterrfile == null with
assert(stdouterrfile != null && stdouterrfile.length() >= 1)
And get rid of /dev/null etc.
For example if the background jvm cannot start, for example you supplied a
bad -Xms setting, you need to see the error message somewhere.
It is not a good idea to force the client jvm to keep running. The client
and the server must be independent.
2014-05-05 11:17 GMT+02:00 Andreas Lundblad :
> On Fri, May 02, 2014 at 03:01:17PM -0700, Jonathan Gibbons wrote:
> > The code to use NUL or /dev/null is somewhat icky. Is that actually
> > the behavior you want?
> > How about using ProcessBuilder.Redirect.INHERIT instead?
>
> I don't think we want the output of the background sjavac server to be
> interleaved with the output of the sjavac instance that spawned it.
> (Especially since the log of the background server would be chopped off
> once the foreground process terminates.)
>
> The reason I can't simply leave the whole redirect logic out is because
> the background process halts once it's output buffer is full. The output of
> the background process *has* to be consumed in one way or another. I could
> solve this by spawning a separate thread in the foreground process whose
> sole purpose is to read and discand output from the background process:
>
> Thread discardOutputThread = new Thread() {
> public void run() {
> InputStream is = p.getInputStream();
> try { while (is.read() != -1); }
> catch (IOException e) { }
> }
> };
> discardOutputThread.setDaemon(true);
> discardOutputThread.start();
>
> It just feels a bit awkward to leave a running dummy thread behind, and I
> can't find any documentation on what happens when the foreground process
> terminates and this thread stops. (Although it *did* work on when I tested
> it on Windows 2003 and Ubuntu.)
>
> So, while the NUL or /dev/null workaround does have a grain of platform
> dependency, I still thought it was the cleanest solution. I'm ready to
> reconsider this if others think differently.
>
> I'm somewhat surprised that there is no ProcessBuilder.Redirect.DISCARD.
> Does anybody know why such option is "missing"? :-(
>
> -- Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From nkweteyimdaisy at gmail.com Mon May 5 13:55:38 2014
From: nkweteyimdaisy at gmail.com (Daisy Nkweteyim)
Date: Mon, 5 May 2014 14:55:38 +0100
Subject: Building Javac Code
Message-ID:
Hi
I hope I'm on the right mailing list.
I downloaded the javac source code from
http://hg.openjdk.java.net/jdk7/jdk7/langtools. I looked at the README on
how to build it here
1). First of all I don't have the exact files and directories indicated in
the README
2) To build I have to access the installation directory then run ant. How
is the download?
? zip file installed?
Thanks.?
*Daisy Nkweteyim Cameroon*
? ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonathan.gibbons at oracle.com Mon May 5 19:52:37 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 May 2014 12:52:37 -0700
Subject: interactions between type annotations and language model APIs.
Message-ID: <5367EC05.50900@oracle.com>
In cleaning up the reference implementation of type annotations, we've
uncovered some questions pertaining to the interactions between the type
annotations and language model APIs.
In particular, TypeMirror is now an AnnotatedConstruct, and various
methods in javax.lang.model.util.Types return computed TypeMirrors --
for example, capture(TypeMirror), directSupertypes(TypeMirror),
erasure(TypeMirror), etc.
In cases where the argument has type annotations, what type annotations
(if any) should appear on the return value?
It would help to see clarification added to the specifications, either
generally, or on a case-by-case basis for the affected methods.
-- Jon
From eric.mccorkle at oracle.com Mon May 5 20:36:21 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 05 May 2014 16:36:21 -0400
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <5367EC05.50900@oracle.com>
References: <5367EC05.50900@oracle.com>
Message-ID: <5367F645.50502@oracle.com>
An additional question I would like to raise deals with the relationship
between type annotations and subtyping.
Offhand, there are four possible ways by which annotations might
interact with subtying: covariance (the annotation is preserved for all
subtypes, but not supertypes), contravariance (the annotation is
preserved for all supertypes, but not subtypes), anyvariance (the
annotation is preserved for both super- and subtypes), and invariance
(the annotation is not preserved).
Additionally, there's the question of whether for some interface I and
annotation @A, one can have both I and @A I in an interface heirarchy.
I'll put forward that type annotations need to be able to support all
these possibilities, and that there ought to be additional facilities
for defining how a given annotation type behaves in these contexts.
These are all future-facing considerations, of course. I'm mentioning
them here because they came up in discussions of the issues Jon raised,
but they do not need to be addressed in the same timeline.
On 05/05/14 15:52, Jonathan Gibbons wrote:
> In cleaning up the reference implementation of type annotations, we've
> uncovered some questions pertaining to the interactions between the type
> annotations and language model APIs.
>
> In particular, TypeMirror is now an AnnotatedConstruct, and various
> methods in javax.lang.model.util.Types return computed TypeMirrors --
> for example, capture(TypeMirror), directSupertypes(TypeMirror),
> erasure(TypeMirror), etc.
>
> In cases where the argument has type annotations, what type annotations
> (if any) should appear on the return value?
>
> It would help to see clarification added to the specifications, either
> generally, or on a case-by-case basis for the affected methods.
>
> -- Jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL:
From alex.buckley at oracle.com Mon May 5 20:48:38 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 05 May 2014 13:48:38 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <5367EC05.50900@oracle.com>
References: <5367EC05.50900@oracle.com>
Message-ID: <5367F926.30009@oracle.com>
On 5/5/2014 12:52 PM, Jonathan Gibbons wrote:
> In particular, TypeMirror is now an AnnotatedConstruct, and various
> methods in javax.lang.model.util.Types return computed TypeMirrors --
> for example, capture(TypeMirror), directSupertypes(TypeMirror),
> erasure(TypeMirror), etc.
Right, because jx.l.m.t.TypeMirror always represented the use of a type
at a particular location in source - which can now usually be annotated.
> In cases where the argument has type annotations, what type annotations
> (if any) should appear on the return value?
>
> It would help to see clarification added to the specifications, either
> generally, or on a case-by-case basis for the affected methods.
To be specific, the "generator" methods in jx.l.m.u.Types are these ten:
asMemberOf
boxedClass
capture
directSupertypes
erasure
getArrayType
getDeclaredType x2
getWildcardType
unboxedType
Generally, the "correct" thing to do would be to inspect the TypeMirror
argument and thread its type annotations into the TypeMirror result. But
not always: just because '@Foo String' appears in source does not mean
that calling directSupertypes on its mirror should return '@Foo Object'.
There is also a limitation of the API for wildcard annotations:
getWildcardType could produce a mirror for '? extends @Foo ...' and '?
super @Foo ...' but not '@Foo ? extends ...' or '@Foo ? super ...'.
Joe, what is your view on retrofitting type annotations into Types?
Alex
From jonathan.gibbons at oracle.com Tue May 6 15:36:08 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 May 2014 08:36:08 -0700
Subject: Building Javac Code
In-Reply-To:
References:
Message-ID: <53690168.1050109@oracle.com>
Unless you have specific reasons for using jdk7, I recommend using the
latest released version of javac in the jdk8 repositories.
If you are new to OpenJDK, I would recommend getting the full source
code for OpenJDK and building that, which includes building javac. The
build system in JDK 8 is much improved over that in JDK 7 and makes
building the full product much easier. You can find build instructions
by searching for "build OpenJDK 8".
-- Jon
On 05/05/2014 06:55 AM, Daisy Nkweteyim wrote:
> Hi
> I hope I'm on the right mailing list.
> I downloaded the javac source code from
> http://hg.openjdk.java.net/jdk7/jdk7/langtools. I looked at the README
> on how to build it here
> 1). First of all I don't have the exact files and directories
> indicated in the README
> 2) To build I have to access the installation directory then run ant.
> How is the download?
> ? zip file installed?
>
> Thanks. ?
>
> /Daisy Nkweteyim
> Cameroon/
> ? ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vicente.romero at oracle.com Tue May 6 15:41:41 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 06 May 2014 16:41:41 +0100
Subject: Type inference of non-existent method references crashes the
compiler
In-Reply-To:
References:
Message-ID: <536902B5.1060509@oracle.com>
Hi Victor,
Thanks for the report. I'm looking at it,
Vicente
On 23/04/14 04:57, Victor Williams Stafusa da Silva wrote:
> Hi.
> I just created a new bug report titled "Type inference of non-existent
> method references crashes the compiler"
>
> Basically, the following code crashes the compiler (1.8.0_05) with a
> NullPointerException:
>
> class TestBug {
> static TestBug bug() {
> return new TestBug<>(TestBug::doNotExists);
> }
> }
>
> I am new to this discussion list and just want to know if somebody
> already saw that bug before.
>
> Victor Williams Stafusa da Silva
From nkweteyimdaisy at gmail.com Tue May 6 15:56:13 2014
From: nkweteyimdaisy at gmail.com (Daisy Nkweteyim)
Date: Tue, 6 May 2014 16:56:13 +0100
Subject: Building Javac Code
In-Reply-To: <53690168.1050109@oracle.com>
References:
<53690168.1050109@oracle.com>
Message-ID:
Hi,
Thanks for your replies. I found out that boot.java.home was not defined
in my build.properties so I just added it there. I ran ant and build was
successful. Thanks again.
On Tue, May 6, 2014 at 4:36 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:
> Unless you have specific reasons for using jdk7, I recommend using the
> latest released version of javac in the jdk8 repositories.
>
> If you are new to OpenJDK, I would recommend getting the full source code
> for OpenJDK and building that, which includes building javac. The build
> system in JDK 8 is much improved over that in JDK 7 and makes building the
> full product much easier. You can find build instructions by searching
> for "build OpenJDK 8".
>
> -- Jon
>
>
> On 05/05/2014 06:55 AM, Daisy Nkweteyim wrote:
>
> Hi
> I hope I'm on the right mailing list.
> I downloaded the javac source code from
> http://hg.openjdk.java.net/jdk7/jdk7/langtools. I looked at the README
> on how to build it here
> 1). First of all I don't have the exact files and directories indicated
> in the README
> 2) To build I have to access the installation directory then run ant. How
> is the download?
> ? zip file installed?
>
> Thanks. ?
>
>
> *Daisy Nkweteyim Cameroon*
> ? ?
>
>
>
--
*Daisy Nkweteyim Cameroon*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From cushon at google.com Tue May 6 18:18:06 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 6 May 2014 11:18:06 -0700
Subject: question about applicability inference with wildcards and deferred
types
Message-ID:
I encountered an example where javac8 can't perform applicability inference
for a method in the presence of wildcards. This only occurs with -source 8
-target 8. I think it is related to JDK-7177387, since the behaviour goes
away when Source.allowPoly() is disabled.
Here's the code:
===
import java.util.List;
abstract class Test {
abstract List copyOf(List extends T> lx);
abstract List filter(List lx);
// This works:
void f(List lx) {
copyOf(filter(lx));
}
// This doesn't:
void g(List> lx) {
copyOf(filter(lx));
}
}
===
The interesting bit of the error message is:
error: method copyOf in class Test cannot be applied to given types;
...
List cannot be converted to List extends CAP#2>
I think that the logic in Types.containsType could be improved to handle
this case better. Turning on the debug output (Types.debugContainsType)
reveals that javac is checking:
does "? extends capture#630 of ?" contain "capture#630 of ?" ?
=> U(capture#630 of ?) <: U(? extends capture#630 of ?)
=> java.lang.Object <: capture#630 of ?
=> false
My theory is that prior to javac8 the inferencer did not encounter
wildcards whose bound was a captured wildcard (? extends CAP of ?), and
that changed with the addition of deferred types in JDK-7177387. Perhaps
some additional logic could be added to containsType(T, S) to deal with S
being the upper bound of T?
Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oehrstroem at gmail.com Tue May 6 22:17:46 2014
From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Wed, 7 May 2014 00:17:46 +0200
Subject: RFR: 8042441: sjavac does not properly track dependencies in two
cases.
Message-ID:
Hi compiler-dev,
Please review this fix for JDK-8042441 which fixes two dependency tracking
failures in sjavac.
Description:
A fully qualified identifier for example "alfa.A a;" is not tracked,
but "import alfa.A; ... A a;" is tracked. The fix tracks the fully
qualified identifier by instrumenting Attr.java with a reportDependence in
the same way that Resolve.java is already instrumented. Thanks Jan Lahoda
for the help on where to instrument.
Also, the previous change from . to / in the arguments accidentally broke
the dependencies inside the javac_state file. A trivial fix is supplied for
this, however the tests did not catch this, since the tests did not use
packages with more than one level, ie no dots...thus the tests are improved
to actually detect this kind of error.
Link to webrev:
http://cr.openjdk.java.net/~ohrstrom/webrev-8042441/
Link to bug report:
https://bugs.openjdk.java.net/browse/JDK-8042441
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonathan.gibbons at oracle.com Tue May 6 22:57:31 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 06 May 2014 15:57:31 -0700
Subject: RFR: 8042441: sjavac does not properly track dependencies in
two cases.
In-Reply-To:
References:
Message-ID: <536968DB.4090201@oracle.com>
Fredrik,
It seems to me you are fixing two issues here -- dependency tracking
failures and test failures.
Also, in Attr.java, you have "broken" a javac convention of placing
private utility methods nearby their usage, introduced by a "// where"
comment. By placing the new method where you have, you have separated
visitSelect from the "// where" method that follows it.
-- Jon
On 05/06/2014 03:17 PM, Fredrik ?hrstr?m wrote:
> Hi compiler-dev,
>
> Please review this fix for JDK-8042441 which fixes two dependency
> tracking failures in sjavac.
>
> Description:
> A fully qualified identifier for example "alfa.A a;" is not tracked,
> but "import alfa.A; ... A a;" is tracked. The fix tracks the fully
> qualified identifier by instrumenting Attr.java with a
> reportDependence in the same way that Resolve.java is already
> instrumented. Thanks Jan Lahoda for the help on where to instrument.
>
> Also, the previous change from . to / in the arguments accidentally
> broke the dependencies inside the javac_state file. A trivial fix is
> supplied for this, however the tests did not catch this, since the
> tests did not use packages with more than one level, ie no dots...thus
> the tests are improved to actually detect this kind of error.
>
> Link to webrev:
> http://cr.openjdk.java.net/~ohrstrom/webrev-8042441/
>
>
> Link to bug report:
> https://bugs.openjdk.java.net/browse/JDK-8042441
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oehrstroem at gmail.com Wed May 7 06:05:20 2014
From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Wed, 7 May 2014 08:05:20 +0200
Subject: RFR: 8042441: sjavac does not properly track dependencies in two
cases.
In-Reply-To: <536968DB.4090201@oracle.com>
References:
<536968DB.4090201@oracle.com>
Message-ID:
2014-05-07 0:57 GMT+02:00 Jonathan Gibbons :
>
>
> Also, in Attr.java, you have "broken" a javac convention of placing
> private utility methods nearby their usage, introduced by a "// where"
> comment. By placing the new method where you have, you have separated
> visitSelect from the "// where" method that follows it.
>
I see. Fixed. Uploaded the fixed webrev in place. Please reload.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From andreas.lundblad at oracle.com Wed May 7 14:51:31 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Wed, 7 May 2014 16:51:31 +0200
Subject: RFR: 8042088: Sjavac spawns external processes in a
unnecessarily complex and platform dependent way
In-Reply-To:
References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com>
<20140505091758.GB13904@e6430>
Message-ID: <20140507145130.GH13904@e6430>
On Mon, May 05, 2014 at 01:18:03PM +0200, Fredrik ?hrstr?m wrote:
> The output from stdout and stderr from the background must always be logged
> into a file. The default name for that file is portfile+".stdouterr"
> Thus you could replace stdouterrfile == null with
>
> assert(stdouterrfile != null && stdouterrfile.length() >= 1)
>
> And get rid of /dev/null etc.
Fixed. (I went for IllegalArgumentException to avoid nasty exceptions when running without -ea.)
See new revision here:
http://cr.openjdk.java.net/~alundblad/8042088/webrev.01/
-- Andreas
From jonathan.gibbons at oracle.com Wed May 7 14:55:46 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 07 May 2014 07:55:46 -0700
Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily
complex and platform dependent way
In-Reply-To:
References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com> <20140505091758.GB13904@e6430>
Message-ID: <536A4972.1020300@oracle.com>
javac never uses assert. We have a set of methods in
javac.util.Assert that can be used instead.
-- Jon
On 05/05/2014 04:18 AM, Fredrik ?hrstr?m wrote:
> The output from stdout and stderr from the background must always be
> logged into a file. The default name for that file is
> portfile+".stdouterr"
> Thus you could replace stdouterrfile == null with
>
> assert(stdouterrfile != null && stdouterrfile.length() >= 1)
>
> And get rid of /dev/null etc.
>
> For example if the background jvm cannot start, for example you
> supplied a bad -Xms setting, you need to see the error message somewhere.
> It is not a good idea to force the client jvm to keep running. The
> client and the server must be independent.
>
>
>
>
> 2014-05-05 11:17 GMT+02:00 Andreas Lundblad
> >:
>
> On Fri, May 02, 2014 at 03:01:17PM -0700, Jonathan Gibbons wrote:
> > The code to use NUL or /dev/null is somewhat icky. Is that actually
> > the behavior you want?
> > How about using ProcessBuilder.Redirect.INHERIT instead?
>
> I don't think we want the output of the background sjavac server
> to be interleaved with the output of the sjavac instance that
> spawned it. (Especially since the log of the background server
> would be chopped off once the foreground process terminates.)
>
> The reason I can't simply leave the whole redirect logic out is
> because the background process halts once it's output buffer is
> full. The output of the background process *has* to be consumed in
> one way or another. I could solve this by spawning a separate
> thread in the foreground process whose sole purpose is to read and
> discand output from the background process:
>
> Thread discardOutputThread = new Thread() {
> public void run() {
> InputStream is = p.getInputStream();
> try { while (is.read() != -1); }
> catch (IOException e) { }
> }
> };
> discardOutputThread.setDaemon(true);
> discardOutputThread.start();
>
> It just feels a bit awkward to leave a running dummy thread
> behind, and I can't find any documentation on what happens when
> the foreground process terminates and this thread stops. (Although
> it *did* work on when I tested it on Windows 2003 and Ubuntu.)
>
> So, while the NUL or /dev/null workaround does have a grain of
> platform dependency, I still thought it was the cleanest solution.
> I'm ready to reconsider this if others think differently.
>
> I'm somewhat surprised that there is no
> ProcessBuilder.Redirect.DISCARD. Does anybody know why such option
> is "missing"? :-(
>
> -- Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oehrstroem at gmail.com Wed May 7 18:51:35 2014
From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Wed, 7 May 2014 20:51:35 +0200
Subject: RFR: 8042088: Sjavac spawns external processes in a unnecessarily
complex and platform dependent way
In-Reply-To: <20140507145130.GH13904@e6430>
References: <20140430133307.GA13604@e6430> <536415AD.4070107@oracle.com>
<20140505091758.GB13904@e6430>
<20140507145130.GH13904@e6430>
Message-ID:
Very nice cleanup!
2014-05-07 16:51 GMT+02:00 Andreas Lundblad :
> On Mon, May 05, 2014 at 01:18:03PM +0200, Fredrik ?hrstr?m wrote:
> > The output from stdout and stderr from the background must always be
> logged
> > into a file. The default name for that file is portfile+".stdouterr"
> > Thus you could replace stdouterrfile == null with
> >
> > assert(stdouterrfile != null && stdouterrfile.length() >= 1)
> >
> > And get rid of /dev/null etc.
>
> Fixed. (I went for IllegalArgumentException to avoid nasty exceptions when
> running without -ea.)
>
> See new revision here:
>
> http://cr.openjdk.java.net/~alundblad/8042088/webrev.01/
>
> -- Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oehrstroem at gmail.com Wed May 7 21:34:24 2014
From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Wed, 7 May 2014 23:34:24 +0200
Subject: RFR: 8042441: sjavac does not properly track dependencies in two
cases.
In-Reply-To:
References:
<536968DB.4090201@oracle.com>
Message-ID:
And I shrunk the size of the webrev in place, please reload and reread.
2014-05-07 8:05 GMT+02:00 Fredrik ?hrstr?m :
> 2014-05-07 0:57 GMT+02:00 Jonathan Gibbons :
>
>>
>> Also, in Attr.java, you have "broken" a javac convention of placing
>> private utility methods nearby their usage, introduced by a "// where"
>> comment. By placing the new method where you have, you have separated
>> visitSelect from the "// where" method that follows it.
>>
>
> I see. Fixed. Uploaded the fixed webrev in place. Please reload.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oehrstroem at gmail.com Wed May 7 21:36:21 2014
From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=)
Date: Wed, 7 May 2014 23:36:21 +0200
Subject: RFR: 8042699: sjavac does not properly track dependencies
Message-ID:
Hi compiler-dev,
Please review this fix for JDK-8042699 which fixes a dependency tracking
failures in sjavac.
Description:
The previous change from . to / in the arguments accidentally broke the
dependencies inside the javac_state file. A trivial fix is supplied for
this, however the tests did not catch this, since the tests did not use
packages with more than one level, ie no dots...thus the tests are improved
to actually detect this kind of error.
Link to webrev:
http://cr.openjdk.java.net/~ohrstrom/webrev-8042699/
Link to bug report:
https://bugs.openjdk.java.net/browse/JDK-8042699
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonathan.gibbons at oracle.com Wed May 7 21:38:41 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 07 May 2014 14:38:41 -0700
Subject: RFR: 8042441: sjavac does not properly track dependencies in
two cases.
In-Reply-To:
References: <536968DB.4090201@oracle.com>
Message-ID: <536AA7E1.8030801@oracle.com>
The test needs the bug number 8042441 in the @bug line for the test, but
other than that, you're good to go.
-- Jon
]
On 05/07/2014 02:34 PM, Fredrik ?hrstr?m wrote:
> And I shrunk the size of the webrev in place, please reload and reread.
>
>
> 2014-05-07 8:05 GMT+02:00 Fredrik ?hrstr?m >:
>
> 2014-05-07 0:57 GMT+02:00 Jonathan Gibbons
> >:
>
>
> Also, in Attr.java, you have "broken" a javac convention of
> placing private utility methods nearby their usage, introduced
> by a "// where" comment. By placing the new method where you
> have, you have separated visitSelect from the "// where"
> method that follows it.
>
>
> I see. Fixed. Uploaded the fixed webrev in place. Please reload.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonathan.gibbons at oracle.com Wed May 7 21:40:58 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 07 May 2014 14:40:58 -0700
Subject: RFR: 8042699: sjavac does not properly track dependencies
In-Reply-To:
References:
Message-ID: <536AA86A.5090700@oracle.com>
Add the bug number 8042699 into the @bug line in the test and you're
good to go.
You need the bug number to be present so that down stream processes can
verify that there was a specified test added that is directly relevant
to the fix.
-- Jon
On 05/07/2014 02:36 PM, Fredrik ?hrstr?m wrote:
> Hi compiler-dev,
>
> Please review this fix for JDK-8042699 which fixes a dependency
> tracking failures in sjavac.
>
> Description:
> The previous change from . to / in the arguments accidentally broke
> the dependencies inside the javac_state file. A trivial fix is
> supplied for this, however the tests did not catch this, since the
> tests did not use packages with more than one level, ie no dots...thus
> the tests are improved to actually detect this kind of error.
>
> Link to webrev:
> http://cr.openjdk.java.net/~ohrstrom/webrev-8042699/
>
>
> Link to bug report:
> https://bugs.openjdk.java.net/browse/JDK-8042699
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From eric.mccorkle at oracle.com Wed May 7 23:08:03 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 07 May 2014 19:08:03 -0400
Subject: Public review for 8040327: Eliminate AnnotatedType
Message-ID: <536ABCD3.5070109@oracle.com>
Hello,
This is the first of a series of patches which implement a significant
overhaul of type annotations code in the javac frontend. This patch
eliminates the AnnotatedType class, replacing its functionality by
storing annotations on the Type class itself.
This will eventually be rolled into a more general type metadata
framework that has been planned as part of ongoing work.
Note that this patch is also being reviewed by the langtools team using
the Crucible tool.
The webrev can be found here:
http://cr.openjdk.java.net/~emc/8040327/
The following patches are also under initial review, and will be posted
soon:
1) A patch which replaces much of the functionality in
TypeAnnotations.java with code integrated directly into the MemberEnter
and Attr phases. The end result is that Attribute.TypeCompound objects
will now contain the correct position from the moment they are created,
and the position field will be final. This patch is known colloquially
as the "positions patch", though its scope has grown considerably beyond
that.
2) A follow-up patch which removes code dead code that was replaced by
the positions patch, and removes some code duplication that was
introduced by that patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL:
From philip.race at oracle.com Thu May 8 16:35:56 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 08 May 2014 09:35:56 -0700
Subject: JDK9 build failure on Windows : javac OutOfMemoryError
In-Reply-To: <532224DF.9070202@oracle.com>
References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com>
<5320DCEB.10205@oracle.com> <532224DF.9070202@oracle.com>
Message-ID: <536BB26C.80507@oracle.com>
Do we yet have a definitive answer to whether this is a javac bug
or something that needs to be fixed in the build ?
-phil.
On 3/13/14 2:36 PM, Bradford Wetmore wrote:
> Phil,
>
> That looks exactly like my problem.
>
> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012089.html
> Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9
> using a 32-bit bootdir.
>
> > Yes, 32 bit it appears, although I didn't supply the boot dir option,
> > it chose it all by itself.
>
> I *BELIEVE* that for the bootdirs discovery (I haven't checked the
> code), if a JDK isn't given one with config's --with-boot-jdk, it
> defaults to whatever JDK is found in the path. I typically only
> install a 32-bit one, as several applets I use require 32-bit only.
>
> > Who can dig into how much heap is actually needed and see if some new
> > bug is requiring more than that ?
>
> As for how much head is actually needed, I haven't dug into it, but
> just doing a simple javac -XmxXXXM Foo.java, I could only get up to
> about 1500M. I wasn't able to build on my laptop, but my lab machine
> worked just fine, so it's probably close to the border.
>
> Brad
>
>
>
>
>
>
> On 3/12/2014 3:17 PM, Phil Race wrote:
>> Yes, 32 bit it appears, although I didn't supply the boot dir option, it
>> chose it all by itself.
>> Who can dig into how much heap is actually needed and see if some new
>> bug is
>> requiring more than that ?
>>
>> -phil.
>>
>> On 3/12/2014 3:06 PM, Mike Duigou wrote:
>>> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last
>>> week. The problem in his case was that the 32 bit VM couldn't get a
>>> large enough heap. Switching to a 64 bit boot jdk resolved the issue
>>> for him.
>>>
>>> Mike
>>>
>>> On Mar 12 2014, at 14:45 , Phil Race wrote:
>>>
>>>> I'm on Windows 7 64 bit and I've quit every app except for my
>>>> console windows
>>>> yet I still get this error below.
>>>>
>>>> How can I get past this ?
>>>>
>>>> -phil.
>>>>
>>>> ----------
>>>> ## Starting jdk
>>>> Compiling 9635 files for BUILD_JDK
>>>>
>>>>
>>>> The system is out of resources.
>>>> Consult the following stack trace for details.
>>>> java.lang.OutOfMemoryError: Java heap space
>>>> at
>>>> com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817)
>>>> at
>>>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja
>>>> va:780)
>>>> ....
>>>> ....
>>>>
>>>> make[2]: ***
>>>> [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch]
>>>>
>>>> Error 3
>>>> BuildJdk.gmk:64: recipe for target `classes-only' failed
>>>> make[1]: *** [classes-only] Error 2
>>>> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target
>>>> `jdk-only' failed
>>>> make: *** [jdk-only] Error 2
>>>> ---------------------
>>
From vicente.romero at oracle.com Thu May 8 19:21:57 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 08 May 2014 20:21:57 +0100
Subject: Possible javac bug around final and covariant overrides
In-Reply-To: <53567039.2090103@redhat.com>
References: <53567039.2090103@redhat.com>
Message-ID: <536BD955.7070904@oracle.com>
Hi David,
IMO this is a bug. I have filed
https://bugs.openjdk.java.net/browse/JDK-8042785 to track it.
Thanks for your report,
Vicente
On 22/04/14 14:35, David M. Lloyd wrote:
> While exploring adding covariant overrides for Buffer classes, it was
> discovered that javac is not making synthetic methods for covariant
> overrides match the finality of the covariant method.
>
> Simple illustration:
>
> public class Test {
> public Object foo() { return null; }
> }
> public class TestSub extends Test {
> public final String foo() { return null; }
> }
>
> Yields (javap output):
>
> public class Test {
> public Test();
> public java.lang.Object foo();
> }
> public class TestSub extends Test {
> public TestSub();
> public final java.lang.String foo();
> public java.lang.Object foo(); // <- not final?!
> }
>
> Is there a good reason for this? Hypothetically it would seem that
> this might prevent HotSpot from modifying calls to the synthetic
> method to be monomorphic. Is this a legitimate concern?
>
From wdietl at gmail.com Thu May 8 20:23:11 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Thu, 8 May 2014 16:23:11 -0400
Subject: Public review for 8040327: Eliminate AnnotatedType
In-Reply-To: <536ABCD3.5070109@oracle.com>
References: <536ABCD3.5070109@oracle.com>
Message-ID:
Hi Eric,
I had a quick look and notice:
com/sun/tools/javac/code/Printer.java:
+ List annos = t.getAnnotationMirrors();
+ if (!annos.isEmpty()) {
+ if (prefix) sb.append(' ');
+ sb.append(t.getAnnotationMirrors());
The last line could use annos instead of calling t.getAnnotationMirrors again.
+ private void printBrackets(Type t, StringBuilder sb, Locale locale) {
Type arrel = t;
while (arrel.hasTag(TypeTag.ARRAY)) {
- if (arrel.isAnnotated()) {
- sb.append(' ');
- sb.append(arrel.getAnnotationMirrors());
- sb.append(' ');
- }
+ sb.append(printAnnotations(t, true));
sb.append("[]");
- arrel = arrel.unannotatedType();
arrel = ((ArrayType) arrel).elemtype;
}
}
This change seems wrong. Previously, the type annotations on arrel
were printed on each iteration of the loop.
Now, each iteration prints the annotations on "t" - the top-level
type. The added line should be
sb.append(printAnnotation(arrel, true));
@Override
public String visitMethodType(MethodType t, Locale locale) {
- return "(" + printMethodArgs(t.argtypes, false, locale) + ")"
+ visit(t.restype, locale);
+ return printAnnotations(t) + "(" +
+ printMethodArgs(t.argtypes, false, locale) + ")" +
+ visit(t.restype, locale);
}
What is the meaning of type annotations on a MethodType? We have TAs
on the return type of a method or constructor, but those are in
t.restype.
I don't see what annotations a MethodType itself should contain and
why they would be separate from restype.
Should TAs on the receiver of a method be printed instead (in the
right location)?
Same comment for MethodType.toString() later in the diff.
MethodType.annotatedType correctly raises an error, so I don't see why
toString outputs it.
I'll wait with adapting the Checker Framework until all three patches
are available and can then give more detailed feedback.
cu, WMD.
On Wed, May 7, 2014 at 7:08 PM, Eric McCorkle wrote:
> Hello,
>
> This is the first of a series of patches which implement a significant
> overhaul of type annotations code in the javac frontend. This patch
> eliminates the AnnotatedType class, replacing its functionality by
> storing annotations on the Type class itself.
>
> This will eventually be rolled into a more general type metadata
> framework that has been planned as part of ongoing work.
>
> Note that this patch is also being reviewed by the langtools team using
> the Crucible tool.
>
> The webrev can be found here:
> http://cr.openjdk.java.net/~emc/8040327/
>
>
> The following patches are also under initial review, and will be posted
> soon:
>
> 1) A patch which replaces much of the functionality in
> TypeAnnotations.java with code integrated directly into the MemberEnter
> and Attr phases. The end result is that Attribute.TypeCompound objects
> will now contain the correct position from the moment they are created,
> and the position field will be final. This patch is known colloquially
> as the "positions patch", though its scope has grown considerably beyond
> that.
>
> 2) A follow-up patch which removes code dead code that was replaced by
> the positions patch, and removes some code duplication that was
> introduced by that patch.
--
http://www.google.com/profiles/wdietl
From alex.buckley at oracle.com Thu May 8 22:55:06 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 08 May 2014 15:55:06 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <5367F926.30009@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com>
Message-ID: <536C0B4A.5000901@oracle.com>
On 5/5/2014 1:48 PM, Alex Buckley wrote:
> To be specific, the "generator" methods in jx.l.m.u.Types are these ten:
>
> asMemberOf
> boxedClass
> capture
> directSupertypes
> erasure
> getArrayType
> getDeclaredType x2
> getWildcardType
> unboxedType
boxedClass(PrimitiveType) returns a TypeElement, i.e., a declaration, so
any type annotations on the PrimitiveType mirror are irrelevant. So
we're down to nine methods.
Eric, you indicated that you're already preserving type annotations
"everywhere they ought to be". For each of the nine Types methods that
generate a TypeMirror, can you sketch (one line) what the preservation
involves? If the answer is often "it's obvious", then I'll write the
obvious thing for the API spec.
Alex
From eric.mccorkle at oracle.com Thu May 8 23:06:53 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 08 May 2014 19:06:53 -0400
Subject: Clarification for CantAnnotateStaticClass2 test
Message-ID: <536C0E0D.6030701@oracle.com>
Hello,
In the test CantAnnotateStaticClass2, the following lines appear.
@TB Outer f1;
@TB Outer.Inner f1a;
@TB Outer.SInner f2a; // err
@TB Outer.IInner f3a; // err
In the second line, TB annotates a static class from which a member is
being selected, which should result in an error, but the test does not
expect an error message. Should there, in fact, be an error message?
Thanks,
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL:
From alex.buckley at oracle.com Thu May 8 23:19:41 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 08 May 2014 16:19:41 -0700
Subject: Clarification for CantAnnotateStaticClass2 test
In-Reply-To: <536C0E0D.6030701@oracle.com>
References: <536C0E0D.6030701@oracle.com>
Message-ID: <536C110D.8070105@oracle.com>
Good question, but the test is correct in not expecting an error from f1a.
See
http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-October/000198.html
and the ensuing rules in JLS8 9.7.4 about an "admissible" type annotation.
Alex
On 5/8/2014 4:06 PM, Eric McCorkle wrote:
> Hello,
>
> In the test CantAnnotateStaticClass2, the following lines appear.
>
>
> @TB Outer f1;
> @TB Outer.Inner f1a;
> @TB Outer.SInner f2a; // err
> @TB Outer.IInner f3a; // err
>
> In the second line, TB annotates a static class from which a member is
> being selected, which should result in an error, but the test does not
> expect an error message. Should there, in fact, be an error message?
>
> Thanks,
> Eric
>
From eric.mccorkle at oracle.com Thu May 8 23:42:51 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 08 May 2014 19:42:51 -0400
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536C0B4A.5000901@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com>
<536C0B4A.5000901@oracle.com>
Message-ID: <536C167B.5070906@oracle.com>
On 05/08/14 18:55, Alex Buckley wrote:
> On 5/5/2014 1:48 PM, Alex Buckley wrote:
>> To be specific, the "generator" methods in jx.l.m.u.Types are these ten:
>>
>> asMemberOf
>> boxedClass
>> capture
>> directSupertypes
>> erasure
>> getArrayType
>> getDeclaredType x2
>> getWildcardType
>> unboxedType
>
> boxedClass(PrimitiveType) returns a TypeElement, i.e., a declaration, so
> any type annotations on the PrimitiveType mirror are irrelevant. So
> we're down to nine methods.
>
> Eric, you indicated that you're already preserving type annotations
> "everywhere they ought to be". For each of the nine Types methods that
> generate a TypeMirror, can you sketch (one line) what the preservation
> involves? If the answer is often "it's obvious", then I'll write the
> obvious thing for the API spec.
I will make an opportunistic plug here for adding a unit test suite to
the core parts of the pipeline, which would allow us to examine these
sorts of questions in much greater detail...
In the patch currently under review, (which eliminates AnnotatedType),
the primary goal is to preserve the visible functioning of javac. This
goal is assisted by the fact that javac makes most of its important
decisions using type annotations attached to either Symbol's or
JCTree's, not Type's (in the cases where it didn't I wound up having to
make modifications anyway, due to the elimination of AnnotatedType).
I have added code that preserves type annotations everywhere that a type
(which can carry them) is copied, through Mappings. The only exception
to this is a mapping on Wildcards, because the only use does not look at
annotations.
Annotations are currently disallowed on ForAll, MethodType, and the
various types (not an exhaustive list) that exist to assist type
inference. I make no attempt to preserve them through inference,
because doing so is highly nontrivial.
Annotations are preserved through erasure. This was the behavior of
javac before the patch, and changing it may have nontrivial effects. So
if it is to be changed, that needs to be filed as a separate issue.
Annotations are not preserved when creating supertypes, lower or
upper-bounds.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL:
From erik.joelsson at oracle.com Fri May 9 08:38:02 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 09 May 2014 10:38:02 +0200
Subject: JDK9 build failure on Windows : javac OutOfMemoryError
In-Reply-To: <536BB26C.80507@oracle.com>
References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> <5320DCEB.10205@oracle.com>
<532224DF.9070202@oracle.com> <536BB26C.80507@oracle.com>
Message-ID: <536C93EA.5050209@oracle.com>
I do not know and I don't see what could be done from the build point of
view.
When we restructure the source for modules, each unit of compilation
will be much smaller so the problem will most likely go away.
/Erik
On 2014-05-08 18:35, Phil Race wrote:
> Do we yet have a definitive answer to whether this is a javac bug
> or something that needs to be fixed in the build ?
>
> -phil.
>
> On 3/13/14 2:36 PM, Bradford Wetmore wrote:
>> Phil,
>>
>> That looks exactly like my problem.
>>
>> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012089.html
>> Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9
>> using a 32-bit bootdir.
>>
>> > Yes, 32 bit it appears, although I didn't supply the boot dir option,
>> > it chose it all by itself.
>>
>> I *BELIEVE* that for the bootdirs discovery (I haven't checked the
>> code), if a JDK isn't given one with config's --with-boot-jdk, it
>> defaults to whatever JDK is found in the path. I typically only
>> install a 32-bit one, as several applets I use require 32-bit only.
>>
>> > Who can dig into how much heap is actually needed and see if some new
>> > bug is requiring more than that ?
>>
>> As for how much head is actually needed, I haven't dug into it, but
>> just doing a simple javac -XmxXXXM Foo.java, I could only get up to
>> about 1500M. I wasn't able to build on my laptop, but my lab machine
>> worked just fine, so it's probably close to the border.
>>
>> Brad
>>
>>
>>
>>
>>
>>
>> On 3/12/2014 3:17 PM, Phil Race wrote:
>>> Yes, 32 bit it appears, although I didn't supply the boot dir
>>> option, it
>>> chose it all by itself.
>>> Who can dig into how much heap is actually needed and see if some new
>>> bug is
>>> requiring more than that ?
>>>
>>> -phil.
>>>
>>> On 3/12/2014 3:06 PM, Mike Duigou wrote:
>>>> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last
>>>> week. The problem in his case was that the 32 bit VM couldn't get a
>>>> large enough heap. Switching to a 64 bit boot jdk resolved the issue
>>>> for him.
>>>>
>>>> Mike
>>>>
>>>> On Mar 12 2014, at 14:45 , Phil Race wrote:
>>>>
>>>>> I'm on Windows 7 64 bit and I've quit every app except for my
>>>>> console windows
>>>>> yet I still get this error below.
>>>>>
>>>>> How can I get past this ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> ----------
>>>>> ## Starting jdk
>>>>> Compiling 9635 files for BUILD_JDK
>>>>>
>>>>>
>>>>> The system is out of resources.
>>>>> Consult the following stack trace for details.
>>>>> java.lang.OutOfMemoryError: Java heap space
>>>>> at
>>>>> com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817)
>>>>> at
>>>>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja
>>>>> va:780)
>>>>> ....
>>>>> ....
>>>>>
>>>>> make[2]: ***
>>>>> [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch]
>>>>>
>>>>> Error 3
>>>>> BuildJdk.gmk:64: recipe for target `classes-only' failed
>>>>> make[1]: *** [classes-only] Error 2
>>>>> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target
>>>>> `jdk-only' failed
>>>>> make: *** [jdk-only] Error 2
>>>>> ---------------------
>>>
>
From joe.darcy at oracle.com Fri May 9 15:24:52 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 09 May 2014 08:24:52 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <5367F926.30009@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com>
Message-ID: <536CF344.5090402@oracle.com>
Hello,
On 5/5/2014 1:48 PM, Alex Buckley wrote:
> On 5/5/2014 12:52 PM, Jonathan Gibbons wrote:
>> In particular, TypeMirror is now an AnnotatedConstruct, and various
>> methods in javax.lang.model.util.Types return computed TypeMirrors --
>> for example, capture(TypeMirror), directSupertypes(TypeMirror),
>> erasure(TypeMirror), etc.
>
> Right, because jx.l.m.t.TypeMirror always represented the use of a
> type at a particular location in source - which can now usually be
> annotated.
>
>> In cases where the argument has type annotations, what type annotations
>> (if any) should appear on the return value?
>>
>> It would help to see clarification added to the specifications, either
>> generally, or on a case-by-case basis for the affected methods.
>
> To be specific, the "generator" methods in jx.l.m.u.Types are these ten:
>
> asMemberOf
> boxedClass
> capture
> directSupertypes
> erasure
> getArrayType
> getDeclaredType x2
> getWildcardType
> unboxedType
>
> Generally, the "correct" thing to do would be to inspect the
> TypeMirror argument and thread its type annotations into the
> TypeMirror result. But not always: just because '@Foo String' appears
> in source does not mean that calling directSupertypes on its mirror
> should return '@Foo Object'. There is also a limitation of the API for
> wildcard annotations: getWildcardType could produce a mirror for '?
> extends @Foo ...' and '? super @Foo ...' but not '@Foo ? extends ...'
> or '@Foo ? super ...'.
>
> Joe, what is your view on retrofitting type annotations into Types?
>
Hmm.
My first reaction here is that these methods should by default ignore
annotations and we should add another utility method or two like:
T withAnnotations(T typeMirror, List extends
AnnotationMirror> annotations)
T withAnnotations(T typeMirror,
AnnotatedConstruct annotationHost)
to allow the annotations savvy user to perform whatever annotation
passing along or computation is appropriate for the problem domain.
-Joe
From daniel.smith at oracle.com Fri May 9 15:59:19 2014
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 9 May 2014 09:59:19 -0600
Subject: question about applicability inference with wildcards and
deferred types
In-Reply-To:
References:
Message-ID:
Hi Liam,
Thanks for the test. This is a bug in the 'containsType' code that I've been looking into recently. I've added this example to the comments.
Report is here: https://bugs.openjdk.java.net/browse/JDK-8039214
?Dan
On May 6, 2014, at 12:18 PM, Liam Miller-Cushon wrote:
> I encountered an example where javac8 can't perform applicability inference for a method in the presence of wildcards. This only occurs with -source 8 -target 8. I think it is related to JDK-7177387, since the behaviour goes away when Source.allowPoly() is disabled.
>
> Here's the code:
>
> ===
> import java.util.List;
>
> abstract class Test {
> abstract List copyOf(List extends T> lx);
> abstract List filter(List lx);
>
> // This works:
> void f(List lx) {
> copyOf(filter(lx));
> }
>
> // This doesn't:
> void g(List> lx) {
> copyOf(filter(lx));
> }
> }
> ===
>
> The interesting bit of the error message is:
>
> error: method copyOf in class Test cannot be applied to given types;
> ...
> List cannot be converted to List extends CAP#2>
>
> I think that the logic in Types.containsType could be improved to handle this case better. Turning on the debug output (Types.debugContainsType) reveals that javac is checking:
>
> does "? extends capture#630 of ?" contain "capture#630 of ?" ?
> => U(capture#630 of ?) <: U(? extends capture#630 of ?)
> => java.lang.Object <: capture#630 of ?
> => false
>
> My theory is that prior to javac8 the inferencer did not encounter wildcards whose bound was a captured wildcard (? extends CAP of ?), and that changed with the addition of deferred types in JDK-7177387. Perhaps some additional logic could be added to containsType(T, S) to deal with S being the upper bound of T?
>
> Thanks,
> Liam
>
From eric.mccorkle at oracle.com Fri May 9 19:49:04 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 09 May 2014 15:49:04 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
Message-ID: <536D3130.2010500@oracle.com>
Hello,
This is the public review of the second in my series of patches dealing
with type annotations.
http://cr.openjdk.java.net/~emc/8027262/
This patch rearchitects the type annotations pipeline, integrating
handling of type annotations directly into the javac
MemberEnter/Annotate/Attr pipeline. It represents the majority of the
work I have been doing regarding type annotations for 8u20.
The handling of type annotations is now dispatched by the MemberEnter or
Attr visitors and uses information from those visitors. Most of the
actual functionality is now implemented in Annotate.
The new test Stress.java is the test for this patch. Stress.java will
cause 8-release javac to fail with an assertion failure. Its addition
to the test suite demonstrates that this change fixes those cases.
This patch addresses a number of JBS issues:
https://bugs.openjdk.java.net/browse/JDK-8027262
https://bugs.openjdk.java.net/browse/JDK-8027261
https://bugs.openjdk.java.net/browse/JDK-8027258
https://bugs.openjdk.java.net/browse/JDK-8027182
and possibly others as well.
Note: this patch does not attempt to remove code made obsolete; however,
any such code is very clearly marked as deprecated. Removal of dead
code will be done in the last of the series. This patch also does not
attempt to re-enable tests which were previously disabled. That will be
done as a separate patch as well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL:
From wdietl at gmail.com Fri May 9 20:20:28 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Fri, 9 May 2014 16:20:28 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To: <536D3130.2010500@oracle.com>
References: <536D3130.2010500@oracle.com>
Message-ID:
Hi Eric,
two quick questions:
- I don't see "Stress" anywhere in the patch. Is that test case included?
- Is there a reason to not use @Deprecated for the classes/methods
that will be removed?
Is this a good time to adapt the Checker Framework to these changes or
should I wait for patch 3?
Thanks,
cu, WMD.
On Fri, May 9, 2014 at 3:49 PM, Eric McCorkle wrote:
> Hello,
>
> This is the public review of the second in my series of patches dealing
> with type annotations.
>
> http://cr.openjdk.java.net/~emc/8027262/
>
> This patch rearchitects the type annotations pipeline, integrating
> handling of type annotations directly into the javac
> MemberEnter/Annotate/Attr pipeline. It represents the majority of the
> work I have been doing regarding type annotations for 8u20.
>
> The handling of type annotations is now dispatched by the MemberEnter or
> Attr visitors and uses information from those visitors. Most of the
> actual functionality is now implemented in Annotate.
>
> The new test Stress.java is the test for this patch. Stress.java will
> cause 8-release javac to fail with an assertion failure. Its addition
> to the test suite demonstrates that this change fixes those cases.
>
> This patch addresses a number of JBS issues:
> https://bugs.openjdk.java.net/browse/JDK-8027262
> https://bugs.openjdk.java.net/browse/JDK-8027261
> https://bugs.openjdk.java.net/browse/JDK-8027258
> https://bugs.openjdk.java.net/browse/JDK-8027182
> and possibly others as well.
>
> Note: this patch does not attempt to remove code made obsolete; however,
> any such code is very clearly marked as deprecated. Removal of dead
> code will be done in the last of the series. This patch also does not
> attempt to re-enable tests which were previously disabled. That will be
> done as a separate patch as well.
--
http://www.google.com/profiles/wdietl
From eric.mccorkle at oracle.com Fri May 9 20:34:38 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 09 May 2014 16:34:38 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To:
References: <536D3130.2010500@oracle.com>
Message-ID: <536D3BDE.3010806@oracle.com>
On 05/09/14 16:20, Werner Dietl wrote:
> Hi Eric,
>
> two quick questions:
>
> - I don't see "Stress" anywhere in the patch. Is that test case included?
Apologies, Stress.java got left out by accident. That has been corrected.
> - Is there a reason to not use @Deprecated for the classes/methods
> that will be removed?
There are still some uses of the deprecated code, which will produce
warnings. Since javac is required to compile with -Werror, we can't
have warnings.
> Is this a good time to adapt the Checker Framework to these changes or
> should I wait for patch 3?
You should be fine. Patch 3 does some very minor code moving, and a
whole lot of removal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL:
From wdietl at gmail.com Fri May 9 20:48:36 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Fri, 9 May 2014 16:48:36 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To: <536D3BDE.3010806@oracle.com>
References: <536D3130.2010500@oracle.com>
<536D3BDE.3010806@oracle.com>
Message-ID:
>> two quick questions:
>>
>> - I don't see "Stress" anywhere in the patch. Is that test case included?
>
> Apologies, Stress.java got left out by accident. That has been corrected.
Would it be better to write that test in the "referenceinfos" style?
At the moment Stress just makes sure that all the different syntax
elements work, which other tests in "newlocations" also do. It's not
clear which of the examples in Stress previously worked and which
didn't.
The "referenceinfos" style of tests would also make sure that the
generated bytecode contains the correct type annotations.
>> - Is there a reason to not use @Deprecated for the classes/methods
>> that will be removed?
>
> There are still some uses of the deprecated code, which will produce
> warnings. Since javac is required to compile with -Werror, we can't
> have warnings.
Ok, then I just make them @Deprecated locally to make it easier to
find my uses of these methods.
>> Is this a good time to adapt the Checker Framework to these changes or
>> should I wait for patch 3?
>
> You should be fine. Patch 3 does some very minor code moving, and a
> whole lot of removal.
Is there a timeline for this patch? If it also comes within a few
days, I'll rather wait for it.
cu, WMD.
--
http://www.google.com/profiles/wdietl
From eric.mccorkle at oracle.com Fri May 9 20:55:25 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 09 May 2014 16:55:25 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To:
References: <536D3130.2010500@oracle.com>
<536D3BDE.3010806@oracle.com>
Message-ID: <536D40BD.9020106@oracle.com>
On 05/09/14 16:48, Werner Dietl wrote:
>>> two quick questions:
>>>
>>> - I don't see "Stress" anywhere in the patch. Is that test case included?
>>
>> Apologies, Stress.java got left out by accident. That has been corrected.
>
> Would it be better to write that test in the "referenceinfos" style?
> At the moment Stress just makes sure that all the different syntax
> elements work, which other tests in "newlocations" also do. It's not
> clear which of the examples in Stress previously worked and which
> didn't.
> The "referenceinfos" style of tests would also make sure that the
> generated bytecode contains the correct type annotations.
>
The idea of Stress is to hit a whole bunch of edge cases. While I'm not
opposed to expanding the newlocations tests (or preferably, writing a
combo-test), I would prefer to put Stress in as-is.
There is also the fact that it is a kind of regression test, as it
crashes 8-release javac.
>>> Is this a good time to adapt the Checker Framework to these changes or
>>> should I wait for patch 3?
>>
>> You should be fine. Patch 3 does some very minor code moving, and a
>> whole lot of removal.
>
> Is there a timeline for this patch? If it also comes within a few
> days, I'll rather wait for it.
>
The dead code patch depends on this one (obviously), and unfortunately,
my only option for review until this patch goes in is to post a diff.
Ideally, this patch will be committed some time early next week, at
which point the dead code patch will immediately go up for review.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL:
From alex.buckley at oracle.com Fri May 9 21:36:16 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 09 May 2014 14:36:16 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536CF344.5090402@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com>
<536CF344.5090402@oracle.com>
Message-ID: <536D4A50.4070303@oracle.com>
Joe,
On 5/9/2014 8:24 AM, Joe Darcy wrote:
> My first reaction here is that these methods should by default ignore
> annotations and we should add another utility method or two like:
>
> T withAnnotations(T typeMirror, List extends
> AnnotationMirror> annotations)
>
> T withAnnotations(T typeMirror,
> AnnotatedConstruct annotationHost)
>
> to allow the annotations savvy user to perform whatever annotation
> passing along or computation is appropriate for the problem domain.
In other words, specify in javax.lang.model.util.Types that it is
unspecified as to the presence of type annotations in a TypeMirror
object returned by a Types' method ? And also, specify builder methods
that decorate an existing TypeMirror object with type annotations ?
This approach sidesteps the complexities (alluded to in my prior mail)
of trying to enrich certain methods' results with type annotations.
This approach also exposes that "there's more than one way to do it", so
we should not rush into decisions that ultimately will be part of JSR
269's next Maintenance Review. Do you keep a to-do list for 269 somewhere?
Alex
From wdietl at gmail.com Fri May 9 21:53:33 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Fri, 9 May 2014 17:53:33 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To: <536D40BD.9020106@oracle.com>
References: <536D3130.2010500@oracle.com>
<536D3BDE.3010806@oracle.com>
<536D40BD.9020106@oracle.com>
Message-ID:
In test/tools/javac/warnings/suppress/TypeAnnotations.out
9 warnings are removed.
For example, line 23 uses a @Deprecated type annotation in a cast twice.
Why don't you expect the warnings for this anymore?
cu, WMD.
On Fri, May 9, 2014 at 4:55 PM, Eric McCorkle wrote:
> On 05/09/14 16:48, Werner Dietl wrote:
>>>> two quick questions:
>>>>
>>>> - I don't see "Stress" anywhere in the patch. Is that test case included?
>>>
>>> Apologies, Stress.java got left out by accident. That has been corrected.
>>
>> Would it be better to write that test in the "referenceinfos" style?
>> At the moment Stress just makes sure that all the different syntax
>> elements work, which other tests in "newlocations" also do. It's not
>> clear which of the examples in Stress previously worked and which
>> didn't.
>> The "referenceinfos" style of tests would also make sure that the
>> generated bytecode contains the correct type annotations.
>>
>
> The idea of Stress is to hit a whole bunch of edge cases. While I'm not
> opposed to expanding the newlocations tests (or preferably, writing a
> combo-test), I would prefer to put Stress in as-is.
>
> There is also the fact that it is a kind of regression test, as it
> crashes 8-release javac.
>
>>>> Is this a good time to adapt the Checker Framework to these changes or
>>>> should I wait for patch 3?
>>>
>>> You should be fine. Patch 3 does some very minor code moving, and a
>>> whole lot of removal.
>>
>> Is there a timeline for this patch? If it also comes within a few
>> days, I'll rather wait for it.
>>
>
> The dead code patch depends on this one (obviously), and unfortunately,
> my only option for review until this patch goes in is to post a diff.
>
> Ideally, this patch will be committed some time early next week, at
> which point the dead code patch will immediately go up for review.
--
http://www.google.com/profiles/wdietl
From joe.darcy at oracle.com Fri May 9 22:38:33 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 09 May 2014 15:38:33 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536D4A50.4070303@oracle.com>
References: <5367EC05.50900@oracle.com>
<5367F926.30009@oracle.com> <536CF344.5090402@oracle.com>
<536D4A50.4070303@oracle.com>
Message-ID: <536D58E9.8030009@oracle.com>
Hi Alex,
On 5/9/2014 2:36 PM, Alex Buckley wrote:
> Joe,
>
> On 5/9/2014 8:24 AM, Joe Darcy wrote:
>> My first reaction here is that these methods should by default ignore
>> annotations and we should add another utility method or two like:
>>
>> T withAnnotations(T typeMirror, List extends
>> AnnotationMirror> annotations)
>>
>> T withAnnotations(T typeMirror,
>> AnnotatedConstruct annotationHost)
>>
>> to allow the annotations savvy user to perform whatever annotation
>> passing along or computation is appropriate for the problem domain.
>
> In other words, specify in javax.lang.model.util.Types that it is
> unspecified as to the presence of type annotations in a TypeMirror
> object returned by a Types' method ?
Or even go further and state no annotations are propagated.
> And also, specify builder methods that decorate an existing TypeMirror
> object with type annotations ?
Right.
>
> This approach sidesteps the complexities (alluded to in my prior mail)
> of trying to enrich certain methods' results with type annotations.
Indeed.
>
> This approach also exposes that "there's more than one way to do it",
> so we should not rush into decisions that ultimately will be part of
> JSR 269's next Maintenance Review. Do you keep a to-do list for 269
> somewhere?
>
Given the desired semantics of the annotations being used in these cases
are largely extra-lingual, I don't think trying to specify their
propagation in javax.lang.model is wise.
For tracking purposes, a JBS bug in core-libs / javax.lang.model would
be appropriate.
Thanks,
-Joe
From alex.buckley at oracle.com Fri May 9 22:59:02 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 09 May 2014 15:59:02 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536D58E9.8030009@oracle.com>
References: <5367EC05.50900@oracle.com>
<5367F926.30009@oracle.com> <536CF344.5090402@oracle.com>
<536D4A50.4070303@oracle.com> <536D58E9.8030009@oracle.com>
Message-ID: <536D5DB6.1080706@oracle.com>
On 5/9/2014 3:38 PM, Joe Darcy wrote:
> Given the desired semantics of the annotations being used in these cases
> are largely extra-lingual, I don't think trying to specify their
> propagation in javax.lang.model is wise.
Clearly, general TypeMirror combinators in jx.l.m.u.Types are not
expected to be sensitive to the meaning of type annotations. For
example, isSameType is not expected to compare type annotations within
its two TypeMirror arguments.
But while the _semantics_ of the annotations are extra-lingual, their
_existence_ is not. That's why I called out specific TypeMirror
generators in jx.l.m.u.Types. For example, if I have a TypeMirror that
represents '@Foo List', and I pass it to the erasure method,
then I could reasonably expect to get back a TypeMirror that represents
'@Foo List'. Similarly for getArrayType, getDeclaredType, etc.
All that said, preserving the existence of type annotations in all
TypeMirror generators is quite complicated.
> For tracking purposes, a JBS bug in core-libs / javax.lang.model would
> be appropriate.
It's not clear to me what the actual behavior of Types' methods is
today, which is why I proposed to specify that it's not specified
(inspired by Class#getDeclaredMethods being specified to return methods
in an unspecified order).
Jon, Eric, would that be OK?
Alex
From eric.mccorkle at oracle.com Fri May 9 23:21:25 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 09 May 2014 19:21:25 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To:
References: <536D3130.2010500@oracle.com>
<536D3BDE.3010806@oracle.com>
<536D40BD.9020106@oracle.com>
Message-ID: <536D62F5.6000008@oracle.com>
On 05/09/14 17:53, Werner Dietl wrote:
> In test/tools/javac/warnings/suppress/TypeAnnotations.out
> 9 warnings are removed.
> For example, line 23 uses a @Deprecated type annotation in a cast twice.
> Why don't you expect the warnings for this anymore?
If you look, you will notice that all the removed warnings are
duplicates of other warnings.
There was a bug in the original implementation that apparently caused
warnings coming from annotations on instanceof and cast (and probably
other things) to be emitted twice.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL:
From wdietl at gmail.com Fri May 9 23:24:44 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Fri, 9 May 2014 19:24:44 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To: <536D62F5.6000008@oracle.com>
References: <536D3130.2010500@oracle.com>
<536D3BDE.3010806@oracle.com>
<536D40BD.9020106@oracle.com>
<536D62F5.6000008@oracle.com>
Message-ID:
Ah, sorry for missing that!
cu, WMD.
On Fri, May 9, 2014 at 7:21 PM, Eric McCorkle wrote:
> On 05/09/14 17:53, Werner Dietl wrote:
>> In test/tools/javac/warnings/suppress/TypeAnnotations.out
>> 9 warnings are removed.
>> For example, line 23 uses a @Deprecated type annotation in a cast twice.
>> Why don't you expect the warnings for this anymore?
>
> If you look, you will notice that all the removed warnings are
> duplicates of other warnings.
>
> There was a bug in the original implementation that apparently caused
> warnings coming from annotations on instanceof and cast (and probably
> other things) to be emitted twice.
--
http://www.google.com/profiles/wdietl
From jonathan.gibbons at oracle.com Sat May 10 00:03:38 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 09 May 2014 17:03:38 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536D5DB6.1080706@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com>
<536D58E9.8030009@oracle.com> <536D5DB6.1080706@oracle.com>
Message-ID: <536D6CDA.5060506@oracle.com>
On 05/09/2014 03:59 PM, Alex Buckley wrote:
> On 5/9/2014 3:38 PM, Joe Darcy wrote:
>> Given the desired semantics of the annotations being used in these cases
>> are largely extra-lingual, I don't think trying to specify their
>> propagation in javax.lang.model is wise.
>
> Clearly, general TypeMirror combinators in jx.l.m.u.Types are not
> expected to be sensitive to the meaning of type annotations. For
> example, isSameType is not expected to compare type annotations within
> its two TypeMirror arguments.
>
> But while the _semantics_ of the annotations are extra-lingual, their
> _existence_ is not. That's why I called out specific TypeMirror
> generators in jx.l.m.u.Types. For example, if I have a TypeMirror that
> represents '@Foo List', and I pass it to the erasure method,
> then I could reasonably expect to get back a TypeMirror that
> represents '@Foo List'. Similarly for getArrayType, getDeclaredType, etc.
>
> All that said, preserving the existence of type annotations in all
> TypeMirror generators is quite complicated.
>
>> For tracking purposes, a JBS bug in core-libs / javax.lang.model would
>> be appropriate.
>
> It's not clear to me what the actual behavior of Types' methods is
> today, which is why I proposed to specify that it's not specified
> (inspired by Class#getDeclaredMethods being specified to return
> methods in an unspecified order).
>
> Jon, Eric, would that be OK?
>
> Alex
It seems to me that specifying the behavior to be unspecified is (a)
avoiding the issue and (b) not helpful to clients.
It's one thing to say the order of methods in a class is unspecified,
when it is clear that no semantic change occurs if they are shuffled,
but it is another to say, "eh, they may be there, they may not be
there". Any client wanting to build deterministic behavior on top of an
API like that now has to deal with the possibility that none, some or
all of the annotations may survive the call.
I like your differentiation between the semantics of type annotations
and the existence of type annotations. I think the spec-gurus for
javax.lang.model, having determined that the number of generator methods
is countable on their two hands, could determine a boolean value for
each finger and give a thumbs up or thumbs down as to whether the annos
survive the call.
If in doubt, specify that none survive, and give clients a determinsitic
base on which to build their own type systems.
-- Jon
From brucechapman at paradise.net.nz Sun May 11 08:35:34 2014
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Sun, 11 May 2014 20:35:34 +1200
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536D4A50.4070303@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com>
<536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com>
Message-ID: <536F3656.1050100@paradise.net.nz>
I think you are on the right track here. Types' methods would probably
strip type annotations, but provide tools for the user to reinsert them
when the user knows that is appropriate and valuable given the semantics
of the annotation and what the code is trying to do. I am presuming
Joe's second method would in some way back substitute an annotated type
for an (possibly) unannotated type within the typeMirror argument?
withAnnotations(typeof(List), typeof(@Nullable String)> would
return typeof(List<@Nullable String>?
if so, what happens when the second argument appears more than once in
the first argument? e.g. Map?
Despite these difficulties, I still think stripping then tools to
reinsert the type annotations is what would be most useful.
The alternative would be some way to tell types' method what should happen.
Bruce
On 10/05/2014 9:36 a.m., Alex Buckley wrote:
> Joe,
>
> On 5/9/2014 8:24 AM, Joe Darcy wrote:
>> My first reaction here is that these methods should by default ignore
>> annotations and we should add another utility method or two like:
>>
>> T withAnnotations(T typeMirror, List extends
>> AnnotationMirror> annotations)
>>
>> T withAnnotations(T typeMirror,
>> AnnotatedConstruct annotationHost)
>>
>> to allow the annotations savvy user to perform whatever annotation
>> passing along or computation is appropriate for the problem domain.
>
> In other words, specify in javax.lang.model.util.Types that it is
> unspecified as to the presence of type annotations in a TypeMirror
> object returned by a Types' method ? And also, specify builder methods
> that decorate an existing TypeMirror object with type annotations ?
>
> This approach sidesteps the complexities (alluded to in my prior mail)
> of trying to enrich certain methods' results with type annotations.
>
> This approach also exposes that "there's more than one way to do it",
> so we should not rush into decisions that ultimately will be part of
> JSR 269's next Maintenance Review. Do you keep a to-do list for 269
> somewhere?
>
> Alex
>
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
From joe.darcy at oracle.com Sun May 11 16:23:58 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 11 May 2014 09:23:58 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536F3656.1050100@paradise.net.nz>
References: <5367EC05.50900@oracle.com>
<5367F926.30009@oracle.com> <536CF344.5090402@oracle.com>
<536D4A50.4070303@oracle.com> <536F3656.1050100@paradise.net.nz>
Message-ID: <536FA41E.5090708@oracle.com>
Hi Bruce,
On 5/11/2014 1:35 AM, Bruce Chapman wrote:
> I think you are on the right track here. Types' methods would probably
> strip type annotations, but provide tools for the user to reinsert
> them when the user knows that is appropriate and valuable given the
> semantics of the annotation and what the code is trying to do. I am
> presuming Joe's second method would in some way back substitute an
> annotated type for an (possibly) unannotated type within the
> typeMirror argument?
The intention is the second method was that the returned value would be
a wrapper around the first argument that had the annotations of the
second argument.
>
> withAnnotations(typeof(List), typeof(@Nullable String)> would
> return typeof(List<@Nullable String>?
I intended this to return
@Nullable List
>
> if so, what happens when the second argument appears more than once in
> the first argument? e.g. Map?
>
> Despite these difficulties, I still think stripping then tools to
> reinsert the type annotations is what would be most useful.
>
> The alternative would be some way to tell types' method what should
> happen.
I don't see you good way to approach that problem. Stripping the
annotations and allowing them to be added, gives interested parties full
control while being a tractable API.
Thanks,
-Joe
>
> Bruce
>
>
> On 10/05/2014 9:36 a.m., Alex Buckley wrote:
>> Joe,
>>
>> On 5/9/2014 8:24 AM, Joe Darcy wrote:
>>> My first reaction here is that these methods should by default ignore
>>> annotations and we should add another utility method or two like:
>>>
>>> T withAnnotations(T typeMirror, List extends
>>> AnnotationMirror> annotations)
>>>
>>> T withAnnotations(T typeMirror,
>>> AnnotatedConstruct annotationHost)
>>>
>>> to allow the annotations savvy user to perform whatever annotation
>>> passing along or computation is appropriate for the problem domain.
>>
>> In other words, specify in javax.lang.model.util.Types that it is
>> unspecified as to the presence of type annotations in a TypeMirror
>> object returned by a Types' method ? And also, specify builder
>> methods that decorate an existing TypeMirror object with type
>> annotations ?
>>
>> This approach sidesteps the complexities (alluded to in my prior
>> mail) of trying to enrich certain methods' results with type
>> annotations.
>>
>> This approach also exposes that "there's more than one way to do it",
>> so we should not rush into decisions that ultimately will be part of
>> JSR 269's next Maintenance Review. Do you keep a to-do list for 269
>> somewhere?
>>
>> Alex
>>
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
From brucechapman at paradise.net.nz Mon May 12 09:17:53 2014
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Mon, 12 May 2014 21:17:53 +1200
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536FA41E.5090708@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com>
<536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com>
<536F3656.1050100@paradise.net.nz> <536FA41E.5090708@oracle.com>
Message-ID: <537091C1.8040009@paradise.net.nz>
On 12/05/2014 4:23 a.m., Joe Darcy wrote:
> Hi Bruce,
> On 5/11/2014 1:35 AM, Bruce Chapman wrote:
>> I think you are on the right track here. Types' methods would
>> probably strip type annotations, but provide tools for the user to
>> reinsert them when the user knows that is appropriate and valuable
>> given the semantics of the annotation and what the code is trying to
>> do. I am presuming Joe's second method would in some way back
>> substitute an annotated type for an (possibly) unannotated type
>> within the typeMirror argument?
>
> The intention is the second method was that the returned value would
> be a wrapper around the first argument that had the annotations of the
> second argument.
So wouldn't the second argument be better as List?
>
>>
>> withAnnotations(typeof(List), typeof(@Nullable String)> would
>> return typeof(List<@Nullable String>?
>
> I intended this to return
>
> @Nullable List
So how would we construct (for example) List<@Nullable String> if
Types.getDeclaredType() stripped @Nullable off String, and there is no
deep back substitution?
And given that deep back substitution is also problematic, could it work
if we had an explicit function to (possibly recursively) strip all
annotations from a type, or strip specified (with a List)
annotations from a type, but did not strip in Types' existing methods?
We might also need a stripAnnotationsExcept(TypeMirror t,
List retainedAnnotationTypes) to provide for all
possibilities. Along with something to add annotations, I think that
would provide a full set of construction techniques. Users would still
need to write their own versions of Types.isXXX() if the annotations
were significant for their use case.
Are Michael Ernst and JSR308 E.G. across this thread?
Bruce
>
>>
>> if so, what happens when the second argument appears more than once
>> in the first argument? e.g. Map?
>>
>> Despite these difficulties, I still think stripping then tools to
>> reinsert the type annotations is what would be most useful.
>>
>> The alternative would be some way to tell types' method what should
>> happen.
>
> I don't see you good way to approach that problem. Stripping the
> annotations and allowing them to be added, gives interested parties
> full control while being a tractable API.
>
> Thanks,
>
> -Joe
>
>>
>> Bruce
>>
>>
>> On 10/05/2014 9:36 a.m., Alex Buckley wrote:
>>> Joe,
>>>
>>> On 5/9/2014 8:24 AM, Joe Darcy wrote:
>>>> My first reaction here is that these methods should by default ignore
>>>> annotations and we should add another utility method or two like:
>>>>
>>>> T withAnnotations(T typeMirror, List extends
>>>> AnnotationMirror> annotations)
>>>>
>>>> T withAnnotations(T typeMirror,
>>>> AnnotatedConstruct annotationHost)
>>>>
>>>> to allow the annotations savvy user to perform whatever annotation
>>>> passing along or computation is appropriate for the problem domain.
>>>
>>> In other words, specify in javax.lang.model.util.Types that it is
>>> unspecified as to the presence of type annotations in a TypeMirror
>>> object returned by a Types' method ? And also, specify builder
>>> methods that decorate an existing TypeMirror object with type
>>> annotations ?
>>>
>>> This approach sidesteps the complexities (alluded to in my prior
>>> mail) of trying to enrich certain methods' results with type
>>> annotations.
>>>
>>> This approach also exposes that "there's more than one way to do
>>> it", so we should not rush into decisions that ultimately will be
>>> part of JSR 269's next Maintenance Review. Do you keep a to-do list
>>> for 269 somewhere?
>>>
>>> Alex
>>>
>>
>>
>> ---
>> This email is free from viruses and malware because avast! Antivirus
>> protection is active.
>> http://www.avast.com
>>
>
>
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
From daniel.smith at oracle.com Mon May 12 18:16:05 2014
From: daniel.smith at oracle.com (Dan Smith)
Date: Mon, 12 May 2014 12:16:05 -0600
Subject: RFR: JDK-8042882: Support verbosity options in langtools testing
Message-ID:
A patch to enhance langtools/test/Makefile is inline, below.
This addresses JDK-8042882, adding a variable to control verbosity. I've also slipped in a fix for JDK-8032441, eliminating the use of the MaxPermSize JVM option (deprecated in 8, gone in 9) when running JCK tests.
?Dan
# HG changeset patch
# Parent e5d0d7510671bc6725cb0f231553697bf6ca76b6
diff -r e5d0d7510671 test/Makefile
--- a/test/Makefile Fri May 09 14:56:59 2014 -0600
+++ b/test/Makefile Mon May 12 12:05:29 2014 -0600
@@ -186,6 +186,12 @@
JTREG_OPTIONS += -timeoutFactor:$(JTREG_TIMEOUT_FACTOR)
endif
+# Default verbosity setting for jtreg
+JTREG_VERBOSE = fail,error,nopass
+
+# Default verbosity setting for jck
+JCK_VERBOSE = non-pass
+
# Assertions: some tests show failures when assertions are enabled.
# Since javac is typically loaded via the bootclassloader (either via TESTJAVA
# or TESTBOOTCLASSPATH), you may need -esa to enable assertions in javac.
@@ -256,6 +262,8 @@
# Version of java used to run jtreg. Should normally be the same as TESTJAVA
# TESTJAVA
# Version of java to be tested.
+# JTREG_VERBOSE
+# Verbosity setting for jtreg
# JTREG_OPTIONS
# Additional options for jtreg
# JTREG_TESTDIRS
@@ -273,7 +281,7 @@
JT_JAVA=$(JT_JAVA) $(JTREG) \
-J-Xmx512m \
-vmoption:-Xmx768m \
- -a -ignore:quiet -v:fail,error,nopass \
+ -a -ignore:quiet $(if $(JTREG_VERBOSE),-v:$(JTREG_VERBOSE)) \
-r:$(JTREG_OUTPUT_DIR)/JTreport \
-w:$(JTREG_OUTPUT_DIR)/JTwork \
-jdk:$(TESTJAVA) \
@@ -312,6 +320,8 @@
# Default is JDK 7
# TESTJAVA
# Version of java to be tested.
+# JCK_VERBOSE
+# Verbosity setting for jtjck
# JCK_COMPILER_OPTIONS
# Additional options for JCK-compiler
# JCK_COMPILER_TESTDIRS
@@ -325,9 +335,9 @@
@rm -f -r $(JCK_COMPILER_OUTPUT_DIR)/work $(JCK_COMPILER_OUTPUT_DIR)/report \
$(JCK_COMPILER_OUTPUT_DIR)/diff.html $(JCK_COMPILER_OUTPUT_DIR)/status.txt
@mkdir -p $(JCK_COMPILER_OUTPUT_DIR)
- $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \
+ $(JT_JAVA)/bin/java -Xmx512m \
-jar $(JCK_HOME)/JCK-compiler-8/lib/jtjck.jar \
- -v:non-pass \
+ $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \
-r:$(JCK_COMPILER_OUTPUT_DIR)/report \
-w:$(JCK_COMPILER_OUTPUT_DIR)/work \
-jdk:$(TESTJAVA) \
@@ -361,6 +371,8 @@
# Version of java used to run JCK. Should normally be the same as TESTJAVA
# TESTJAVA
# Version of java to be tested.
+# JCK_VERBOSE
+# Verbosity setting for jtjck
# JCK_RUNTIME_OPTIONS
# Additional options for JCK-runtime
# JCK_RUNTIME_TESTDIRS
@@ -374,9 +386,9 @@
@rm -f -r $(JCK_RUNTIME_OUTPUT_DIR)/work $(JCK_RUNTIME_OUTPUT_DIR)/report \
$(JCK_RUNTIME_OUTPUT_DIR)/diff.html $(JCK_RUNTIME_OUTPUT_DIR)/status.txt
@mkdir -p $(JCK_RUNTIME_OUTPUT_DIR)
- $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \
+ $(JT_JAVA)/bin/java -Xmx512m \
-jar $(JCK_HOME)/JCK-runtime-8/lib/jtjck.jar \
- -v:non-pass \
+ $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \
-r:$(JCK_RUNTIME_OUTPUT_DIR)/report \
-w:$(JCK_RUNTIME_OUTPUT_DIR)/work \
-jdk:$(TESTJAVA) \
From alex.buckley at oracle.com Mon May 12 21:13:25 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 12 May 2014 14:13:25 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <537091C1.8040009@paradise.net.nz>
References: <5367EC05.50900@oracle.com>
<5367F926.30009@oracle.com> <536CF344.5090402@oracle.com>
<536D4A50.4070303@oracle.com> <536F3656.1050100@paradise.net.nz>
<536FA41E.5090708@oracle.com> <537091C1.8040009@paradise.net.nz>
Message-ID: <53713975.80205@oracle.com>
On 5/12/2014 2:17 AM, Bruce Chapman wrote:
> Are Michael Ernst and JSR308 E.G. across this thread?
JSR 308 has had its Final Release, so officially the EG has disbanded,
and Mike and I are co-Maintenance Leads. I have cc'd him so he is aware
of this thread. That said, the reflective aspects of JSR 308 - Core
Reflection, Language Model, and Annotation Processing - were generally
handled by Oracle.
Alex
From alex.buckley at oracle.com Mon May 12 21:26:09 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 12 May 2014 14:26:09 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <536D6CDA.5060506@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536D58E9.8030009@oracle.com>
<536D5DB6.1080706@oracle.com> <536D6CDA.5060506@oracle.com>
Message-ID: <53713C71.3000402@oracle.com>
On 5/9/2014 5:03 PM, Jonathan Gibbons wrote:
> If in doubt, specify that none survive, and give clients a determinsitic
> base on which to build their own type systems.
This seems to be the right approach, given the limitations of the
existing Types API and the many possible operations for adding,
deleting, and replacing type annotations.
I will file a JBS bug to specify that no type annotations appear in the
return values of Types' methods. Actually designing new methods in
Types, or even a whole new API, is beyond the scope the bug; it would
require a JEP.
Alex
From mike.duigou at oracle.com Mon May 12 21:33:45 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 12 May 2014 14:33:45 -0700
Subject: RFR: JDK-8042882: Support verbosity options in langtools testing
In-Reply-To:
References:
Message-ID: <5E8F9C91-D94D-45DF-B5B0-7C60381B6618@oracle.com>
Looks good to me.
A very useful addition that I plan to port to the jdk repo.
Mike
On May 12 2014, at 11:16 , Dan Smith wrote:
> A patch to enhance langtools/test/Makefile is inline, below.
>
> This addresses JDK-8042882, adding a variable to control verbosity. I've also slipped in a fix for JDK-8032441, eliminating the use of the MaxPermSize JVM option (deprecated in 8, gone in 9) when running JCK tests.
>
> ?Dan
>
> # HG changeset patch
> # Parent e5d0d7510671bc6725cb0f231553697bf6ca76b6
>
> diff -r e5d0d7510671 test/Makefile
> --- a/test/Makefile Fri May 09 14:56:59 2014 -0600
> +++ b/test/Makefile Mon May 12 12:05:29 2014 -0600
> @@ -186,6 +186,12 @@
> JTREG_OPTIONS += -timeoutFactor:$(JTREG_TIMEOUT_FACTOR)
> endif
>
> +# Default verbosity setting for jtreg
> +JTREG_VERBOSE = fail,error,nopass
> +
> +# Default verbosity setting for jck
> +JCK_VERBOSE = non-pass
> +
> # Assertions: some tests show failures when assertions are enabled.
> # Since javac is typically loaded via the bootclassloader (either via TESTJAVA
> # or TESTBOOTCLASSPATH), you may need -esa to enable assertions in javac.
> @@ -256,6 +262,8 @@
> # Version of java used to run jtreg. Should normally be the same as TESTJAVA
> # TESTJAVA
> # Version of java to be tested.
> +# JTREG_VERBOSE
> +# Verbosity setting for jtreg
> # JTREG_OPTIONS
> # Additional options for jtreg
> # JTREG_TESTDIRS
> @@ -273,7 +281,7 @@
> JT_JAVA=$(JT_JAVA) $(JTREG) \
> -J-Xmx512m \
> -vmoption:-Xmx768m \
> - -a -ignore:quiet -v:fail,error,nopass \
> + -a -ignore:quiet $(if $(JTREG_VERBOSE),-v:$(JTREG_VERBOSE)) \
> -r:$(JTREG_OUTPUT_DIR)/JTreport \
> -w:$(JTREG_OUTPUT_DIR)/JTwork \
> -jdk:$(TESTJAVA) \
> @@ -312,6 +320,8 @@
> # Default is JDK 7
> # TESTJAVA
> # Version of java to be tested.
> +# JCK_VERBOSE
> +# Verbosity setting for jtjck
> # JCK_COMPILER_OPTIONS
> # Additional options for JCK-compiler
> # JCK_COMPILER_TESTDIRS
> @@ -325,9 +335,9 @@
> @rm -f -r $(JCK_COMPILER_OUTPUT_DIR)/work $(JCK_COMPILER_OUTPUT_DIR)/report \
> $(JCK_COMPILER_OUTPUT_DIR)/diff.html $(JCK_COMPILER_OUTPUT_DIR)/status.txt
> @mkdir -p $(JCK_COMPILER_OUTPUT_DIR)
> - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \
> + $(JT_JAVA)/bin/java -Xmx512m \
> -jar $(JCK_HOME)/JCK-compiler-8/lib/jtjck.jar \
> - -v:non-pass \
> + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \
> -r:$(JCK_COMPILER_OUTPUT_DIR)/report \
> -w:$(JCK_COMPILER_OUTPUT_DIR)/work \
> -jdk:$(TESTJAVA) \
> @@ -361,6 +371,8 @@
> # Version of java used to run JCK. Should normally be the same as TESTJAVA
> # TESTJAVA
> # Version of java to be tested.
> +# JCK_VERBOSE
> +# Verbosity setting for jtjck
> # JCK_RUNTIME_OPTIONS
> # Additional options for JCK-runtime
> # JCK_RUNTIME_TESTDIRS
> @@ -374,9 +386,9 @@
> @rm -f -r $(JCK_RUNTIME_OUTPUT_DIR)/work $(JCK_RUNTIME_OUTPUT_DIR)/report \
> $(JCK_RUNTIME_OUTPUT_DIR)/diff.html $(JCK_RUNTIME_OUTPUT_DIR)/status.txt
> @mkdir -p $(JCK_RUNTIME_OUTPUT_DIR)
> - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \
> + $(JT_JAVA)/bin/java -Xmx512m \
> -jar $(JCK_HOME)/JCK-runtime-8/lib/jtjck.jar \
> - -v:non-pass \
> + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \
> -r:$(JCK_RUNTIME_OUTPUT_DIR)/report \
> -w:$(JCK_RUNTIME_OUTPUT_DIR)/work \
> -jdk:$(TESTJAVA) \
>
From joe.darcy at oracle.com Mon May 12 21:39:26 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 12 May 2014 14:39:26 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <537091C1.8040009@paradise.net.nz>
References: <5367EC05.50900@oracle.com>
<5367F926.30009@oracle.com> <536CF344.5090402@oracle.com>
<536D4A50.4070303@oracle.com> <536F3656.1050100@paradise.net.nz>
<536FA41E.5090708@oracle.com> <537091C1.8040009@paradise.net.nz>
Message-ID: <53713F8E.1060009@oracle.com>
Hi Bruce,
On 5/12/2014 2:17 AM, Bruce Chapman wrote:
> On 12/05/2014 4:23 a.m., Joe Darcy wrote:
>> Hi Bruce,
>> On 5/11/2014 1:35 AM, Bruce Chapman wrote:
>>> I think you are on the right track here. Types' methods would
>>> probably strip type annotations, but provide tools for the user to
>>> reinsert them when the user knows that is appropriate and valuable
>>> given the semantics of the annotation and what the code is trying to
>>> do. I am presuming Joe's second method would in some way back
>>> substitute an annotated type for an (possibly) unannotated type
>>> within the typeMirror argument?
>>
>> The intention is the second method was that the returned value would
>> be a wrapper around the first argument that had the annotations of
>> the second argument.
> So wouldn't the second argument be better as List?
To flesh out the semantics of the two methods I proposed:
T withAnnotations(T typeMirror, List extends
AnnotationMirror> annotations)
T withAnnotations(T typeMirror,
AnnotatedConstruct annotationHost)
Both methods would return a wrapper object around the first argument.
The second argument would supply the annotations for the wrapper object.
In the first method, the annotation mirrors would be used; in the second
method, the wrapper would use the annotations on the second argument
(perhaps after some applicability checks). The second method has
intended to support use cases like "this type should be regarded as
having the same annotations as this object, perhaps some supertype, etc."
At least with this API sketch, this is a low-level API that would have
the expressibility to create any annotation structure. However, it might
not be very convenient to use for complicated transformations.
-Joe
From alex.buckley at oracle.com Mon May 12 22:01:07 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 12 May 2014 15:01:07 -0700
Subject: interactions between type annotations and language model APIs.
In-Reply-To: <53713C71.3000402@oracle.com>
References: <5367EC05.50900@oracle.com> <5367F926.30009@oracle.com> <536CF344.5090402@oracle.com> <536D4A50.4070303@oracle.com> <536D58E9.8030009@oracle.com> <536D5DB6.1080706@oracle.com>
<536D6CDA.5060506@oracle.com> <53713C71.3000402@oracle.com>
Message-ID: <537144A3.9040107@oracle.com>
On 5/12/2014 2:26 PM, Alex Buckley wrote:
> I will file a JBS bug to specify that no type annotations appear in the
> return values of Types' methods. Actually designing new methods in
> Types, or even a whole new API, is beyond the scope the bug; it would
> require a JEP.
https://bugs.openjdk.java.net/browse/JDK-8042981
From eric.mccorkle at oracle.com Thu May 15 16:40:48 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 15 May 2014 12:40:48 -0400
Subject: Public review of rearchitected front-end type annotations pipeline
In-Reply-To: <536D3130.2010500@oracle.com>
References: <536D3130.2010500@oracle.com>
Message-ID: <5374EE10.5060500@oracle.com>
I have integrated a number of edits to the patch, from both the public
and internal reviews, and I have fixed a few issues I found. A new
version has been posted here:
http://cr.openjdk.java.net/~emc/8027262/webrev.01/
It is likely that this change will be integrated later today, or
tomorrow. At that point, I will post the third and final patch in the
series.
On 05/09/14 15:49, Eric McCorkle wrote:
> Hello,
>
> This is the public review of the second in my series of patches dealing
> with type annotations.
>
> http://cr.openjdk.java.net/~emc/8027262/
>
> This patch rearchitects the type annotations pipeline, integrating
> handling of type annotations directly into the javac
> MemberEnter/Annotate/Attr pipeline. It represents the majority of the
> work I have been doing regarding type annotations for 8u20.
>
> The handling of type annotations is now dispatched by the MemberEnter or
> Attr visitors and uses information from those visitors. Most of the
> actual functionality is now implemented in Annotate.
>
> The new test Stress.java is the test for this patch. Stress.java will
> cause 8-release javac to fail with an assertion failure. Its addition
> to the test suite demonstrates that this change fixes those cases.
>
> This patch addresses a number of JBS issues:
> https://bugs.openjdk.java.net/browse/JDK-8027262
> https://bugs.openjdk.java.net/browse/JDK-8027261
> https://bugs.openjdk.java.net/browse/JDK-8027258
> https://bugs.openjdk.java.net/browse/JDK-8027182
> and possibly others as well.
>
> Note: this patch does not attempt to remove code made obsolete; however,
> any such code is very clearly marked as deprecated. Removal of dead
> code will be done in the last of the series. This patch also does not
> attempt to re-enable tests which were previously disabled. That will be
> done as a separate patch as well.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
URL:
From eric.mccorkle at oracle.com Fri May 16 11:53:36 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 16 May 2014 07:53:36 -0400
Subject: CFV: New jdk9 Committer- Paul Govereau
Message-ID: <5375FC40.40607@oracle.com>
I hereby nominate Paul Govereau for jdk9 committer
Paul joined the langtools team at Oracle in December of 2013, and has
contributed a number of patches to both the jdk9 and 8u langtools
repository.
The following is a list of his contributions to jdk9:
8033437: javac, inconsistent generic types behaviour when compiling
together vs. separate
8030046: javac incorrectly handles absolute paths in manifest classpath
8039026: Definitely unassigned field can be accessed
8041521: JDK-8034245 breaks a bootcycle build
8034245: Refactor TopLevel tree node.
8038023: Compiler crash ClassCastException
8015499: javac, Gen is generating extra checkcast instructions in some
corner cases
8023945: javac wrongly allows a subclass of an anonymous class
8034933: Update documentation for Types.directSupertypes to clarify behavior
8025505: Constant folding deficiency
8036007: javac crashes when encountering an unresolvable interface
8035972: missing test file for 8034048
6533516: Warning needed for file with future time stamps
8034048: javac crash with method references plus lambda plus var args
8030726: tools/javac/NoStringToLower.java fails due to enforcement no
use of String.toLowerCase on non-langtools classes
8030642: Add golden files to javac/limits
Votes are due by May 30, 2014.
Only current jdk9 Committers [1] are eligible to vote on this nomination.
For Lazy Consensus voting instructions, see [2].
Eric McCorkle
[1]http://openjdk.java.net/census
[2]http://openjdk.java.net/projects/#committer-vote
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 303 bytes
Desc: not available
URL:
From vicente.romero at oracle.com Fri May 16 13:35:47 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 16 May 2014 14:35:47 +0100
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <53761433.4090808@oracle.com>
vote: yes
Vicente
On 16/05/14 12:53, Eric McCorkle wrote:
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
From karen.kinnear at oracle.com Fri May 16 14:48:05 2014
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 16 May 2014 10:48:05 -0400
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <6498E2DF-E40C-46EC-83F4-3FED868E337C@oracle.com>
Vote: yes
On May 16, 2014, at 7:53 AM, Eric McCorkle wrote:
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
From staffan.larsen at oracle.com Fri May 16 15:28:52 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 16 May 2014 17:28:52 +0200
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID:
Vote: yes
On 16 maj 2014, at 13:53, Eric McCorkle wrote:
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
From john.r.rose at oracle.com Fri May 16 15:34:26 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 16 May 2014 08:34:26 -0700
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <95C1FD44-5068-42AC-AFE0-26952DC14EE1@oracle.com>
Vote: yes
? John
> On May 16, 2014, at 4:53 AM, Eric McCorkle wrote:
>
> I hereby nominate Paul Govereau for jdk9 committer
From mike.duigou at oracle.com Fri May 16 15:58:24 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 16 May 2014 08:58:24 -0700
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID:
Vote: YES
On May 16 2014, at 04:53 , Eric McCorkle wrote:
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
From Xuelei.Fan at Oracle.Com Fri May 16 16:06:37 2014
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Sat, 17 May 2014 00:06:37 +0800
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <5D82E5A1-EA2A-485F-A504-7754F0FC2B01@Oracle.Com>
Vote: yes.
Xuelei
> On May 16, 2014, at 7:53 PM, Eric McCorkle wrote:
>
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
From vicente.romero at oracle.com Fri May 16 17:11:40 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 16 May 2014 18:11:40 +0100
Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785
Message-ID: <537646CC.4090008@oracle.com>
Hi Alex,
Regarding the bug report in the subject. I initially considered it a bug
but now I'm wondering about the meaning of a final flag in a bridge
method. Also I didn't find in the spec a reference saying what flags can
be applied to bridge methods. For example can a bridge method be
strictfp too?
Thanks,
Vicente
From david.lloyd at redhat.com Fri May 16 17:19:55 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 16 May 2014 12:19:55 -0500
Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785
In-Reply-To: <537646CC.4090008@oracle.com>
References: <537646CC.4090008@oracle.com>
Message-ID: <537648BB.8090601@redhat.com>
On 05/16/2014 12:11 PM, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Alex,
>
> Regarding the bug report in the subject. I initially considered it a bug
> but now I'm wondering about the meaning of a final flag in a bridge
> method. Also I didn't find in the spec a reference saying what flags can
> be applied to bridge methods. For example can a bridge method be
> strictfp too?
>
> Thanks,
> Vicente
Why would a final flag have any different meaning for a bridge method?
Also, I don't see any reason why strictfp would be disallowed (bridge
methods do have bodies after all), though it might not be "strictly"
useful in practice. Maybe it'd be relevant to instrumentors though?
--
- DML
From alex.buckley at oracle.com Fri May 16 19:38:15 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 16 May 2014 12:38:15 -0700
Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785
In-Reply-To: <537646CC.4090008@oracle.com>
References: <537646CC.4090008@oracle.com>
Message-ID: <53766927.2030008@oracle.com>
Hi Vicente,
On 5/16/2014 10:11 AM, Vicente-Arturo Romero-Zaldivar wrote:
> Regarding the bug report in the subject. I initially considered it a bug
> but now I'm wondering about the meaning of a final flag in a bridge
> method. Also I didn't find in the spec a reference saying what flags can
> be applied to bridge methods. For example can a bridge method be
> strictfp too?
As David indicated, there is no "problem" with a bridge method being
marked final (or strictfp) in the class file. It's syntactically legal
(access_flags allows it) and semantically level (you can meaningfully
have a bridge method that is not overrideable).
My concern is with unforeseen consequences at the language level. Today
it is possible to override a bridge method - yes, it's almost certainly
accidental, but if we start making some bridge methods final then some
programs are going to break. But, the number of such programs will be
low, and arguably they never deserved to compile. So, I would go ahead
with the bug fix.
Alex
From david.lloyd at redhat.com Fri May 16 19:46:48 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 16 May 2014 14:46:48 -0500
Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785
In-Reply-To: <53766927.2030008@oracle.com>
References: <537646CC.4090008@oracle.com> <53766927.2030008@oracle.com>
Message-ID: <53766B28.3010706@redhat.com>
On 05/16/2014 02:38 PM, Alex Buckley wrote:
> Hi Vicente,
>
> On 5/16/2014 10:11 AM, Vicente-Arturo Romero-Zaldivar wrote:
>> Regarding the bug report in the subject. I initially considered it a bug
>> but now I'm wondering about the meaning of a final flag in a bridge
>> method. Also I didn't find in the spec a reference saying what flags can
>> be applied to bridge methods. For example can a bridge method be
>> strictfp too?
>
> As David indicated, there is no "problem" with a bridge method being
> marked final (or strictfp) in the class file. It's syntactically legal
> (access_flags allows it) and semantically level (you can meaningfully
> have a bridge method that is not overrideable).
>
> My concern is with unforeseen consequences at the language level. Today
> it is possible to override a bridge method - yes, it's almost certainly
> accidental, but if we start making some bridge methods final then some
> programs are going to break. But, the number of such programs will be
> low, and arguably they never deserved to compile. So, I would go ahead
> with the bug fix.
Not to mention any program which is relying on finality as a security
mechanism...
--
- DML
From vicente.romero at oracle.com Fri May 16 21:09:41 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 16 May 2014 22:09:41 +0100
Subject: question about https://bugs.openjdk.java.net/browse/JDK-8042785
In-Reply-To: <53766B28.3010706@redhat.com>
References: <537646CC.4090008@oracle.com> <53766927.2030008@oracle.com>
<53766B28.3010706@redhat.com>
Message-ID: <53767E95.9090005@oracle.com>
Hi Alex,
Thanks for your replay. I already have a fix for this bug that is
copying flags like final and strictfp from the original method to the
bridge method, and no one else. But I preferred to double check with you
before going on with the fix.
Thanks,
Vicente
On 16/05/14 20:46, David M. Lloyd wrote:
> On 05/16/2014 02:38 PM, Alex Buckley wrote:
>> Hi Vicente,
>>
>> On 5/16/2014 10:11 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>> Regarding the bug report in the subject. I initially considered it a
>>> bug
>>> but now I'm wondering about the meaning of a final flag in a bridge
>>> method. Also I didn't find in the spec a reference saying what flags
>>> can
>>> be applied to bridge methods. For example can a bridge method be
>>> strictfp too?
>>
>> As David indicated, there is no "problem" with a bridge method being
>> marked final (or strictfp) in the class file. It's syntactically legal
>> (access_flags allows it) and semantically level (you can meaningfully
>> have a bridge method that is not overrideable).
>>
>> My concern is with unforeseen consequences at the language level. Today
>> it is possible to override a bridge method - yes, it's almost certainly
>> accidental, but if we start making some bridge methods final then some
>> programs are going to break. But, the number of such programs will be
>> low, and arguably they never deserved to compile. So, I would go ahead
>> with the bug fix.
>
> Not to mention any program which is relying on finality as a security
> mechanism...
>
From david.r.chase at oracle.com Fri May 16 12:14:53 2014
From: david.r.chase at oracle.com (David Chase)
Date: Fri, 16 May 2014 08:14:53 -0400
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <7EB574BC-F75E-4FCF-A1BA-DEC3AAC012A5@oracle.com>
Vote: yes
On 2014-05-16, at 7:53 AM, Eric McCorkle wrote:
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From yumin.qi at oracle.com Fri May 16 15:43:36 2014
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 16 May 2014 08:43:36 -0700
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <53763228.20006@oracle.com>
Vote: Yes
On 5/16/2014 4:53 AM, Eric McCorkle wrote:
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
From serguei.spitsyn at oracle.com Tue May 20 07:18:32 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 20 May 2014 00:18:32 -0700
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <537B01C8.7060601@oracle.com>
Vote: yes
From kumar.x.srinivasan at oracle.com Wed May 21 18:21:18 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 21 May 2014 11:21:18 -0700
Subject: CFV: New jdk9 Committer- Paul Govereau
In-Reply-To: <5375FC40.40607@oracle.com>
References: <5375FC40.40607@oracle.com>
Message-ID: <537CEE9E.60201@oracle.com>
Vote: yes
Kumar
On 5/16/2014 4:53 AM, Eric McCorkle wrote:
> I hereby nominate Paul Govereau for jdk9 committer
>
> Paul joined the langtools team at Oracle in December of 2013, and has
> contributed a number of patches to both the jdk9 and 8u langtools
> repository.
>
> The following is a list of his contributions to jdk9:
>
> 8033437: javac, inconsistent generic types behaviour when compiling
> together vs. separate
> 8030046: javac incorrectly handles absolute paths in manifest classpath
> 8039026: Definitely unassigned field can be accessed
> 8041521: JDK-8034245 breaks a bootcycle build
> 8034245: Refactor TopLevel tree node.
> 8038023: Compiler crash ClassCastException
> 8015499: javac, Gen is generating extra checkcast instructions in some
> corner cases
> 8023945: javac wrongly allows a subclass of an anonymous class
> 8034933: Update documentation for Types.directSupertypes to clarify behavior
> 8025505: Constant folding deficiency
> 8036007: javac crashes when encountering an unresolvable interface
> 8035972: missing test file for 8034048
> 6533516: Warning needed for file with future time stamps
> 8034048: javac crash with method references plus lambda plus var args
> 8030726: tools/javac/NoStringToLower.java fails due to enforcement no
> use of String.toLowerCase on non-langtools classes
> 8030642: Add golden files to javac/limits
>
> Votes are due by May 30, 2014.
>
> Only current jdk9 Committers [1] are eligible to vote on this nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Eric McCorkle
>
>
> [1]http://openjdk.java.net/census
> [2]http://openjdk.java.net/projects/#committer-vote
>
From joe.darcy at oracle.com Tue May 27 16:35:49 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 27 May 2014 09:35:49 -0700
Subject: Question on JEP 119: javax.lang.model Implementation Backed by
Core Reflection
In-Reply-To: <53831018.3060703@linux.vnet.ibm.com>
References: <53831018.3060703@linux.vnet.ibm.com>
Message-ID: <5384BEE5.20301@oracle.com>
On 05/26/2014 02:57 AM, Shi Jun Zhang wrote:
> Hi,
>
> I'm interested in the implementation of JEP 119, however there is no
> RFE in this JEP [1]. What I only find is a changeset for 8004133 [2]
> in langtools repository and it only provides a sample Java file.
>
> My question is that is this the only change for this JEP 119? Is there
> any new API provided as it is described in the JEP?
>
> [1] http://openjdk.java.net/jeps/119
> [2] http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/bcd927639039
>
Hello,
In JDK 8, the sample code you found is the extent of the
javax.lang.model implementation backed by core reflection feature.
HTH,
-Joe
From joe.darcy at oracle.com Wed May 28 02:14:23 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 27 May 2014 19:14:23 -0700
Subject: Draft JEP for comment: Milling Project Coin: softening some rough
edges
Message-ID: <5385467F.9010107@oracle.com>
Hello,
For your consideration, I submit a draft JEP covering
Milling Project Coin: softening some rough edges
https://bugs.openjdk.java.net/browse/JDK-8042880
Full text of the JEP is below. To be clear, this is *not* a call to run
"Coin 2.0," nor is it an effort to work on features that were dropped
from Project Coin. This JEP is just to describe some maintenance-level
changes, most of which were identified as possible future work in the
JSR 334 drafts.
Thanks,
-Joe
Summary
The small language changes included in Project Coin / JSR 334 as part of
JDK 7 / Java SE 7 have been easy to use and have worked well in
practice. However, several amendments could address a few rough edges of
those changes.
Non-goals
This JEP does *not* propose to run a "Coin 2.0" effort or to generally
solicit new language proposals.
Description
Three amendments to the Project Coin features are proposed:
1) Allow @SafeVargs on private instance methods. The @SafeVarargs
annotation can only be applied to methods which cannot be overridden,
including static methods and final instance methods. Private instance
methods are another use case that @SafeVargs could accommodate.
2) Allow effectively final variables to be used as resources in the
try-with-resources statement. The final version of try-with-resources
statement in Java SE 7 requires a fresh variable to be declared for each
resource being managed by the statement. This was a change from earlier
iterations of the feature. The public review draft of JSR 334 discusses
the rationale for the change from the early draft review version of
try-with-resource which allowed an expression managed by the statement.
The JSR 334 expert group was in favor of an additional refinement of
try-with-resources: if the resource is referenced by a final or
effectively final variable, a try-with-resources statement can manage
the resource without a new variable being declared. This restricted
expression being managed by a try-with-resources statement avoids the
semantic issues which motivated removing general expression support. At
the time the expert group settled on this refinement, there was
insufficient time in the release schedule to accommodate the change.
3) Allow diamond with inner classes if the argument type of the
inferred type is denotable. Because the inferred type using diamond with
an inner class constructor could be outside of the set of types
supported by the signature attribute, using diamond with inner classes
was disallowed in Java SE 7. As noted in the JSR 334 proposed final
draft, it would be possible to ease this restriction if the inferred
type was denotable.
In the space of Java language changes, these refinements are very small
changes. The @SafeVarags change might only involve changing a sentence
or two of the specification with a similarly sized change in javac.
However, as with any Java language change, care must be taken to handle
all the pieces of the platform that need updating.
Testing
The language changes would require the usual unit and regression tests
for javac. The JCK compiler suite would need to be updated, both
positive tests and negative tests.
From jose.cornado at gmail.com Wed May 28 17:32:01 2014
From: jose.cornado at gmail.com (=?UTF-8?Q?Jos=C3=A9_Cornado?=)
Date: Wed, 28 May 2014 11:32:01 -0600
Subject: help with unusual warning
Message-ID:
Hello!
I just got this message:
Note: Cannot write values to this compiler:
com.sun.tools.javac.processing.JavacProcessingEnvironment
This is the first time I have seen it. I am scratching my head why this
would be happening .
Is this the right group to address this?
Thanks a lot!!!
--
Jos? Cornado
--
home: http://www.efekctive.com
blog: http://blogging.efekctive.com
----------------------
Everything has been said before, but since nobody listens we have to keep
going back and beginning all over again.
Andre Gide
--
Jos? Cornado
--
home: http://www.efekctive.com
blog: http://blogging.efekctive.com
----------------------
Everything has been said before, but since nobody listens we have to keep
going back and beginning all over again.
Andre Gide
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonathan.gibbons at oracle.com Wed May 28 19:28:49 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 May 2014 12:28:49 -0700
Subject: help with unusual warning
In-Reply-To:
References:
Message-ID: <538638F1.7020203@oracle.com>
What tools are you using and what command line or other activity are you
doing to provoke this message?
-- Jon
On 05/28/2014 10:32 AM, Jos? Cornado wrote:
> Hello!
>
> I just got this message:
>
> Note: Cannot write values to this compiler:
> com.sun.tools.javac.processing.JavacProcessingEnvironment
>
> This is the first time I have seen it. I am scratching my head why
> this would be happening .
>
> Is this the right group to address this?
>
>
> Thanks a lot!!!
>
> --
> Jos? Cornado
>
> --
>
> home: http://www.efekctive.com
> blog: http://blogging.efekctive.com
> ----------------------
>
> Everything has been said before, but since nobody listens we have to
> keep going back and beginning all over again.
>
> Andre Gide
>
> --
> Jos? Cornado
>
> --
>
> home: http://www.efekctive.com
> blog: http://blogging.efekctive.com
> ----------------------
>
> Everything has been said before, but since nobody listens we have to
> keep going back and beginning all over again.
>
> Andre Gide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: