From jonathan.gibbons at oracle.com  Mon Dec  1 19:43:19 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 01 Dec 2014 11:43:19 -0800
Subject: RFR: 8066000: Sjavac TaskListeners should not provide empty
	implementations
In-Reply-To: <20141127110346.GA17814@e6430>
References: <20141127110346.GA17814@e6430>
Message-ID: <547CC4D7.8060600@oracle.com>

Approved

-- Jon

On 11/27/2014 03:03 AM, Andreas Lundblad wrote:
> Hi compiler-dev,
>
> Please review this (trivial) fix for JDK-8066000.
>
> Description:
> Since JDK-8059591 the sjavac TaskListeners do no longer need to override the 'started' method.
>
> Link to web review:
> http://cr.openjdk.java.net/~alundblad/8066000
>
> Link to bug reports:
> http://bugs.openjdk.java.net/browse/JDK-8066000
>
> -- Andreas Lundblad


From andreas.lundblad at oracle.com  Thu Dec  4 15:59:33 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Thu, 4 Dec 2014 16:59:33 +0100
Subject: RFR: 8054717: SJavac should track changes in the public apis of
	classpath classes!
In-Reply-To: <20141127012617.GA17122@e6430>
References: <20141127012617.GA17122@e6430>
Message-ID: <20141204155932.GC28610@e6430>

On Thu, Nov 27, 2014 at 02:26:18AM +0100, Andreas Lundblad wrote:
> [...]
> 
> Link to web review:
> http://cr.openjdk.java.net/~alundblad/8054717
> 
> Link to bug report:
> http://bugs.openjdk.java.net/browse/JDK-8054717
> 
> -- Andreas Lundblad


New revision up for review. Updates:
- Fixed bug in parsing of sjavac_state
- Fixed bug in overloaded methods
- Changed back from newApi.containsAll(oldApi) to newApi.equals(oldApi) in recompile test. Thanks Erik ;)


Tests run:
- make clean && make images
- make clean && make java.base && touch ..../Object.java && make java.base
- make clean && make java.base && [add public field to Object.java] && make java.base
- make clean && make java.base && [touch 40 random jdk files] && make java.base [x10]
- jprt with "build only"
- all sjavac and other langtools tests


-- Andreas

From cowwoc at bbs.darktech.org  Fri Dec  5 02:05:33 2014
From: cowwoc at bbs.darktech.org (cowwoc)
Date: Thu, 4 Dec 2014 19:05:33 -0700 (MST)
Subject: Improving readability of type/casting error messages
Message-ID: <1417745133663-209424.post@n7.nabble.com>

Hi,

With the addition of lambdas in Java8, I'm running into generics error
messages more frequently than ever before and the messages have gotten less
and less readable over time.

I'll start by discussing a seemingly benign error message:

incompatible types: bad return type in lambda expression
    Promise<Optional&lt;GetPostalCode>> cannot be converted to Optional

for this code:

		Promise<Optional&lt;GetPostalCode>> result = current.map(child ->
		{
			// do something
			return Optional.empty();
		}).orElseGet(() ->
		{
			return getPostalCode();
		});
		return result;

The line triggering the error is: "return getPostalCode()"

Here's my problem:

1. getPostalCode() returns "Promise<Optional&lt;GetPostalCode>>"
2. "result" is of the same type.
3. Looking at this code, it's not obvious why the compiler is trying to cast
the output to "Optional"

I've run across this kind of problem very often. The problem I am referring
to is not the specific error message but rather the fact that you're forcing
developers to reverse engineer the compiler in their head to figure out what
is going wrong.

Instead of forcing developers to do figure out why the compiler is
attempting a seemingly wrong cast, couldn't the error message explain it
explicitly? I don't mind passing extra command-line parameters into the
compiler to get more verbose explanations, so long as this is possible.

The second kind of error I am running into is:

method thenApply in class Promise<T> cannot be applied to given types;
  required: Function<? super PostProperty,? extends U>
  found: this::addProperty
  reason: cannot infer type-variable(s) U
    (argument mismatch; bad return type in method reference
      void cannot be converted to U)
  where U,T are type-variables:
    U extends Object declared in method <U>thenApply(Function<? super T,?
extends U>)
    T extends Object declared in class Promise

I don't know about you, but (as a human being) I find this message very hard
to read. It sounds as if the message was written for computers to parse, not
people. What the compiler is actually trying to say is that
"this::addProperty returns void but thenApply() expects it to return a type
that extends Object".

Is it possible for someone to investigate improving these messages?

Thank you,
Gili



--
View this message in context: http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424.html
Sent from the OpenJDK Compiler Development mailing list archive at Nabble.com.

From jonathan.gibbons at oracle.com  Fri Dec  5 02:32:22 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 04 Dec 2014 18:32:22 -0800
Subject: Improving readability of type/casting error messages
In-Reply-To: <1417745133663-209424.post@n7.nabble.com>
References: <1417745133663-209424.post@n7.nabble.com>
Message-ID: <54811936.4040806@oracle.com>

Gili,

I am sorry you feel the error messages have gotten less readable over 
time, because we have put a significant amount of effort into improving 
the messages.

It is certainly the case that the type system has gotten a lot more 
complex over the past few releases, and in some of the more complex 
cases, it is indeed hard to create readable messages .  In particular, 
although you can interpret a series of phrases to mean

"this::addProperty returns void but thenApply() expects it to return a type
that extends Object"

that sort of transformation is almost impossible within javac, 
especially given that we need to be able to localize the message for the 
supported non-English locales.

The current design goal for the messages is to have the message begin 
with a short 1-line summary, followed by the code in question, to give 
some context, followed by any additional details the compiler is able to 
provide.

That being said, there may well be specific instances where messages can 
be improved, and we welcome input when you find specific messages that 
are unclear.

-- Jon

On 12/04/2014 06:05 PM, cowwoc wrote:
> Hi,
>
> With the addition of lambdas in Java8, I'm running into generics error
> messages more frequently than ever before and the messages have gotten less
> and less readable over time.
>
> I'll start by discussing a seemingly benign error message:
>
> incompatible types: bad return type in lambda expression
>      Promise<Optional&lt;GetPostalCode>> cannot be converted to Optional
>
> for this code:
>
> 		Promise<Optional&lt;GetPostalCode>> result = current.map(child ->
> 		{
> 			// do something
> 			return Optional.empty();
> 		}).orElseGet(() ->
> 		{
> 			return getPostalCode();
> 		});
> 		return result;
>
> The line triggering the error is: "return getPostalCode()"
>
> Here's my problem:
>
> 1. getPostalCode() returns "Promise<Optional&lt;GetPostalCode>>"
> 2. "result" is of the same type.
> 3. Looking at this code, it's not obvious why the compiler is trying to cast
> the output to "Optional"
>
> I've run across this kind of problem very often. The problem I am referring
> to is not the specific error message but rather the fact that you're forcing
> developers to reverse engineer the compiler in their head to figure out what
> is going wrong.
>
> Instead of forcing developers to do figure out why the compiler is
> attempting a seemingly wrong cast, couldn't the error message explain it
> explicitly? I don't mind passing extra command-line parameters into the
> compiler to get more verbose explanations, so long as this is possible.
>
> The second kind of error I am running into is:
>
> method thenApply in class Promise<T> cannot be applied to given types;
>    required: Function<? super PostProperty,? extends U>
>    found: this::addProperty
>    reason: cannot infer type-variable(s) U
>      (argument mismatch; bad return type in method reference
>        void cannot be converted to U)
>    where U,T are type-variables:
>      U extends Object declared in method <U>thenApply(Function<? super T,?
> extends U>)
>      T extends Object declared in class Promise
>
> I don't know about you, but (as a human being) I find this message very hard
> to read. It sounds as if the message was written for computers to parse, not
> people. What the compiler is actually trying to say is that
> "this::addProperty returns void but thenApply() expects it to return a type
> that extends Object".
>
> Is it possible for someone to investigate improving these messages?
>
> Thank you,
> Gili
>
>
>
> --
> View this message in context: http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424.html
> Sent from the OpenJDK Compiler Development mailing list archive at Nabble.com.


From cowwoc at bbs.darktech.org  Fri Dec  5 04:54:51 2014
From: cowwoc at bbs.darktech.org (cowwoc)
Date: Thu, 4 Dec 2014 21:54:51 -0700 (MST)
Subject: Improving readability of type/casting error messages
In-Reply-To: <54811936.4040806@oracle.com>
References: <1417745133663-209424.post@n7.nabble.com>
	<54811936.4040806@oracle.com>
Message-ID: <54813C6A.2070507@bbs.darktech.org>

Jon,

There has to be a way to improve this. Look at this error:

The type of <U>thenApply(Function<? super T,? extends U>) is erroneous
   where U,T are type-variables:
     U extends Object declared in method <U>thenApply(Function<? super 
T,? extends U>)
     T extends Object declared in class Promise

incompatible types: inference variable U#1 has incompatible bounds
     equality constraints: Optional<GetPostalCode>
     lower bounds: Promise<U#2>
   where U#1,T,U#2 are type-variables:
     U#1 extends Object declared in method <U#1>thenApply(Function<? 
super T,? extends U#1>)
     T extends Object declared in class Promise
     U#2 extends Object declared in method <U#2>completed(Executor,U#2)

The existing first line is kind of useless. All it says is "you used the 
wrong type in <method signature>. To find out more, read through the 
highly-technical breakdown below".

Couldn't we replace it with this?

     "Invoked thenApply(Function<A, B>) with B = Optional<GetPostalCode> 
but expected B to extend Object"

I don't need you to tell me the method signature in the summary line (I 
can read through the technical breakdown for that). Instead, you should 
focus on describing the actual vs expected values using as simple 
wording as possible. Is that possible?

Gili

On 04/12/2014 9:24 PM, Jonathan Gibbons [via OpenJDK] wrote:
> Gili,
>
> I am sorry you feel the error messages have gotten less readable over
> time, because we have put a significant amount of effort into improving
> the messages.
>
> It is certainly the case that the type system has gotten a lot more
> complex over the past few releases, and in some of the more complex
> cases, it is indeed hard to create readable messages .  In particular,
> although you can interpret a series of phrases to mean
>
> "this::addProperty returns void but thenApply() expects it to return a 
> type
> that extends Object"
>
> that sort of transformation is almost impossible within javac,
> especially given that we need to be able to localize the message for the
> supported non-English locales.
>
> The current design goal for the messages is to have the message begin
> with a short 1-line summary, followed by the code in question, to give
> some context, followed by any additional details the compiler is able to
> provide.
>
> That being said, there may well be specific instances where messages can
> be improved, and we welcome input when you find specific messages that
> are unclear.
>
> -- Jon
>
> On 12/04/2014 06:05 PM, cowwoc wrote:
>
> > Hi,
> >
> > With the addition of lambdas in Java8, I'm running into generics error
> > messages more frequently than ever before and the messages have 
> gotten less
> > and less readable over time.
> >
> > I'll start by discussing a seemingly benign error message:
> >
> > incompatible types: bad return type in lambda expression
> >      Promise<Optional&lt;GetPostalCode>> cannot be converted to 
> Optional
> >
> > for this code:
> >
> > Promise<Optional&lt;GetPostalCode>> result = current.map(child ->
> > {
> > // do something
> > return Optional.empty();
> > }).orElseGet(() ->
> > {
> > return getPostalCode();
> > });
> > return result;
> >
> > The line triggering the error is: "return getPostalCode()"
> >
> > Here's my problem:
> >
> > 1. getPostalCode() returns "Promise<Optional&lt;GetPostalCode>>"
> > 2. "result" is of the same type.
> > 3. Looking at this code, it's not obvious why the compiler is trying 
> to cast
> > the output to "Optional"
> >
> > I've run across this kind of problem very often. The problem I am 
> referring
> > to is not the specific error message but rather the fact that you're 
> forcing
> > developers to reverse engineer the compiler in their head to figure 
> out what
> > is going wrong.
> >
> > Instead of forcing developers to do figure out why the compiler is
> > attempting a seemingly wrong cast, couldn't the error message 
> explain it
> > explicitly? I don't mind passing extra command-line parameters into the
> > compiler to get more verbose explanations, so long as this is possible.
> >
> > The second kind of error I am running into is:
> >
> > method thenApply in class Promise<T> cannot be applied to given types;
> >    required: Function<? super PostProperty,? extends U>
> >    found: this::addProperty
> >    reason: cannot infer type-variable(s) U
> >      (argument mismatch; bad return type in method reference
> >        void cannot be converted to U)
> >    where U,T are type-variables:
> >      U extends Object declared in method <U>thenApply(Function<? 
> super T,?
> > extends U>)
> >      T extends Object declared in class Promise
> >
> > I don't know about you, but (as a human being) I find this message 
> very hard
> > to read. It sounds as if the message was written for computers to 
> parse, not
> > people. What the compiler is actually trying to say is that
> > "this::addProperty returns void but thenApply() expects it to return 
> a type
> > that extends Object".
> >
> > Is it possible for someone to investigate improving these messages?
> >
> > Thank you,
> > Gili
> >
> >
> >
> > --
> > View this message in context: 
> http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424.html
> > Sent from the OpenJDK Compiler Development mailing list archive at 
> Nabble.com.
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the 
> discussion below:
> http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209427.html 
>
> To unsubscribe from Improving readability of type/casting error 
> messages, click here 
> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=209424&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8MjA5NDI0fDE1NzQzMjEyNDc=>.
> NAML 
> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>





--
View this message in context: http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209438.html
Sent from the OpenJDK Compiler Development mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141204/30773b61/attachment-0001.html>

From cowwoc at bbs.darktech.org  Fri Dec  5 05:03:04 2014
From: cowwoc at bbs.darktech.org (cowwoc)
Date: Thu, 4 Dec 2014 22:03:04 -0700 (MST)
Subject: Improving readability of type/casting error messages
In-Reply-To: <54811936.4040806@oracle.com>
References: <1417745133663-209424.post@n7.nabble.com>
	<54811936.4040806@oracle.com>
Message-ID: <54813E4F.5010600@bbs.darktech.org>

The "simplified" message I quoted below was technically incorrect, but 
hopefully you still got my point. Instead of "expected B to extend 
Object" it should have read "expected B to extend Promise<? extends Object>"

The point is, let's do all the variable substitution on behalf of the 
user in the summary. Instead of Promise<U#2> the user should be seeing 
Promise<? extends Object>.

I would still keep the technical breakdown below (with all that 
wonderful U#2 stuff) but the summary should do all the mental gymnastics 
on behalf of the user.

Gili

On 05/12/2014 12:02 AM, cowwoc wrote:
> Jon,
>
> There has to be a way to improve this. Look at this error:
>
> The type of <U>thenApply(Function<? super T,? extends U>) is erroneous
>   where U,T are type-variables:
>     U extends Object declared in method <U>thenApply(Function<? super 
> T,? extends U>)
>     T extends Object declared in class Promise
>
> incompatible types: inference variable U#1 has incompatible bounds
>     equality constraints: Optional<GetPostalCode>
>     lower bounds: Promise<U#2>
>   where U#1,T,U#2 are type-variables:
>     U#1 extends Object declared in method <U#1>thenApply(Function<? 
> super T,? extends U#1>)
>     T extends Object declared in class Promise
>     U#2 extends Object declared in method <U#2>completed(Executor,U#2)
>
> The existing first line is kind of useless. All it says is "you used 
> the wrong type in <method signature>. To find out more, read through 
> the highly-technical breakdown below".
>
> Couldn't we replace it with this?
>
>     "Invoked thenApply(Function<A, B>) with B = 
> Optional<GetPostalCode> but expected B to extend Object"
>
> I don't need you to tell me the method signature in the summary line 
> (I can read through the technical breakdown for that). Instead, you 
> should focus on describing the actual vs expected values using as 
> simple wording as possible. Is that possible?
>
> Gili
>
> On 04/12/2014 9:24 PM, Jonathan Gibbons [via OpenJDK] wrote:
>> Gili,
>>
>> I am sorry you feel the error messages have gotten less readable over
>> time, because we have put a significant amount of effort into improving
>> the messages.
>>
>> It is certainly the case that the type system has gotten a lot more
>> complex over the past few releases, and in some of the more complex
>> cases, it is indeed hard to create readable messages .  In particular,
>> although you can interpret a series of phrases to mean
>>
>> "this::addProperty returns void but thenApply() expects it to return 
>> a type
>> that extends Object"
>>
>> that sort of transformation is almost impossible within javac,
>> especially given that we need to be able to localize the message for the
>> supported non-English locales.
>>
>> The current design goal for the messages is to have the message begin
>> with a short 1-line summary, followed by the code in question, to give
>> some context, followed by any additional details the compiler is able to
>> provide.
>>
>> That being said, there may well be specific instances where messages can
>> be improved, and we welcome input when you find specific messages that
>> are unclear.
>>
>> -- Jon
>>
>> On 12/04/2014 06:05 PM, cowwoc wrote:
>>
>> > Hi,
>> >
>> > With the addition of lambdas in Java8, I'm running into generics error
>> > messages more frequently than ever before and the messages have 
>> gotten less
>> > and less readable over time.
>> >
>> > I'll start by discussing a seemingly benign error message:
>> >
>> > incompatible types: bad return type in lambda expression
>> >      Promise<Optional&lt;GetPostalCode>> cannot be converted to 
>> Optional
>> >
>> > for this code:
>> >
>> > Promise<Optional&lt;GetPostalCode>> result = current.map(child ->
>> > {
>> > // do something
>> > return Optional.empty();
>> > }).orElseGet(() ->
>> > {
>> > return getPostalCode();
>> > });
>> > return result;
>> >
>> > The line triggering the error is: "return getPostalCode()"
>> >
>> > Here's my problem:
>> >
>> > 1. getPostalCode() returns "Promise<Optional&lt;GetPostalCode>>"
>> > 2. "result" is of the same type.
>> > 3. Looking at this code, it's not obvious why the compiler is 
>> trying to cast
>> > the output to "Optional"
>> >
>> > I've run across this kind of problem very often. The problem I am 
>> referring
>> > to is not the specific error message but rather the fact that 
>> you're forcing
>> > developers to reverse engineer the compiler in their head to figure 
>> out what
>> > is going wrong.
>> >
>> > Instead of forcing developers to do figure out why the compiler is
>> > attempting a seemingly wrong cast, couldn't the error message 
>> explain it
>> > explicitly? I don't mind passing extra command-line parameters into 
>> the
>> > compiler to get more verbose explanations, so long as this is 
>> possible.
>> >
>> > The second kind of error I am running into is:
>> >
>> > method thenApply in class Promise<T> cannot be applied to given types;
>> >    required: Function<? super PostProperty,? extends U>
>> >    found: this::addProperty
>> >    reason: cannot infer type-variable(s) U
>> >      (argument mismatch; bad return type in method reference
>> >        void cannot be converted to U)
>> >    where U,T are type-variables:
>> >      U extends Object declared in method <U>thenApply(Function<? 
>> super T,?
>> > extends U>)
>> >      T extends Object declared in class Promise
>> >
>> > I don't know about you, but (as a human being) I find this message 
>> very hard
>> > to read. It sounds as if the message was written for computers to 
>> parse, not
>> > people. What the compiler is actually trying to say is that
>> > "this::addProperty returns void but thenApply() expects it to 
>> return a type
>> > that extends Object".
>> >
>> > Is it possible for someone to investigate improving these messages?
>> >
>> > Thank you,
>> > Gili
>> >
>> >
>> >
>> > --
>> > View this message in context: 
>> http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424.html
>> > Sent from the OpenJDK Compiler Development mailing list archive at 
>> Nabble.com.
>>
>>
>>
>> ------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the 
>> discussion below:
>> http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209427.html 
>>
>> To unsubscribe from Improving readability of type/casting error 
>> messages, click here 
>> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=209424&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8MjA5NDI0fDE1NzQzMjEyNDc=>.
>> NAML 
>> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>>
>





--
View this message in context: http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209439.html
Sent from the OpenJDK Compiler Development mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141204/4dda9126/attachment.html>

From cowwoc at bbs.darktech.org  Fri Dec  5 05:09:16 2014
From: cowwoc at bbs.darktech.org (cowwoc)
Date: Thu, 4 Dec 2014 22:09:16 -0700 (MST)
Subject: Improving readability of type/casting error messages
In-Reply-To: <54811936.4040806@oracle.com>
References: <1417745133663-209424.post@n7.nabble.com>
	<54811936.4040806@oracle.com>
Message-ID: <54813FC3.1000800@bbs.darktech.org>

Sorry for the repeated follow-up emails but I just discovered something 
else. In the aforementioned compiler error what was really going on was 
that the lambda was returning Promise<Optional<Object>> instead of 
Optional<Object>. This is important to note because in actuality, we 
should be telling the user:

     Invoked thenApply(Function<A, B>) with B = Optional<GetPostalCode> 
but function returned Promise<Optional<GetPostalCode>>.

I think it is much more likely that the user will need to change a 
lambda's return type than to change the return type of the Function 
being implemented. As such, I think the above message is probably the 
clearest of all.

(Notice that it took me over 5 minutes to figure out what was actually 
going on in my own code, and I've been dealing with these error messages 
for months now)

Gili

On 05/12/2014 12:10 AM, cowwoc wrote:
> The "simplified" message I quoted below was technically incorrect, but 
> hopefully you still got my point. Instead of "expected B to extend 
> Object" it should have read "expected B to extend Promise<? extends 
> Object>"
>
> The point is, let's do all the variable substitution on behalf of the 
> user in the summary. Instead of Promise<U#2> the user should be seeing 
> Promise<? extends Object>.
>
> I would still keep the technical breakdown below (with all that 
> wonderful U#2 stuff) but the summary should do all the mental 
> gymnastics on behalf of the user.
>
> Gili
>
> On 05/12/2014 12:02 AM, cowwoc wrote:
>> Jon,
>>
>> There has to be a way to improve this. Look at this error:
>>
>> The type of <U>thenApply(Function<? super T,? extends U>) is erroneous
>>   where U,T are type-variables:
>>     U extends Object declared in method <U>thenApply(Function<? super 
>> T,? extends U>)
>>     T extends Object declared in class Promise
>>
>> incompatible types: inference variable U#1 has incompatible bounds
>>     equality constraints: Optional<GetPostalCode>
>>     lower bounds: Promise<U#2>
>>   where U#1,T,U#2 are type-variables:
>>     U#1 extends Object declared in method <U#1>thenApply(Function<? 
>> super T,? extends U#1>)
>>     T extends Object declared in class Promise
>>     U#2 extends Object declared in method <U#2>completed(Executor,U#2)
>>
>> The existing first line is kind of useless. All it says is "you used 
>> the wrong type in <method signature>. To find out more, read through 
>> the highly-technical breakdown below".
>>
>> Couldn't we replace it with this?
>>
>>     "Invoked thenApply(Function<A, B>) with B = 
>> Optional<GetPostalCode> but expected B to extend Object"
>>
>> I don't need you to tell me the method signature in the summary line 
>> (I can read through the technical breakdown for that). Instead, you 
>> should focus on describing the actual vs expected values using as 
>> simple wording as possible. Is that possible?
>>
>> Gili
>>
>> On 04/12/2014 9:24 PM, Jonathan Gibbons [via OpenJDK] wrote:
>>> Gili,
>>>
>>> I am sorry you feel the error messages have gotten less readable over
>>> time, because we have put a significant amount of effort into improving
>>> the messages.
>>>
>>> It is certainly the case that the type system has gotten a lot more
>>> complex over the past few releases, and in some of the more complex
>>> cases, it is indeed hard to create readable messages .  In particular,
>>> although you can interpret a series of phrases to mean
>>>
>>> "this::addProperty returns void but thenApply() expects it to return 
>>> a type
>>> that extends Object"
>>>
>>> that sort of transformation is almost impossible within javac,
>>> especially given that we need to be able to localize the message for 
>>> the
>>> supported non-English locales.
>>>
>>> The current design goal for the messages is to have the message begin
>>> with a short 1-line summary, followed by the code in question, to give
>>> some context, followed by any additional details the compiler is 
>>> able to
>>> provide.
>>>
>>> That being said, there may well be specific instances where messages 
>>> can
>>> be improved, and we welcome input when you find specific messages that
>>> are unclear.
>>>
>>> -- Jon
>>>
>>> On 12/04/2014 06:05 PM, cowwoc wrote:
>>>
>>> > Hi,
>>> >
>>> > With the addition of lambdas in Java8, I'm running into generics 
>>> error
>>> > messages more frequently than ever before and the messages have 
>>> gotten less
>>> > and less readable over time.
>>> >
>>> > I'll start by discussing a seemingly benign error message:
>>> >
>>> > incompatible types: bad return type in lambda expression
>>> >      Promise<Optional&lt;GetPostalCode>> cannot be converted to 
>>> Optional
>>> >
>>> > for this code:
>>> >
>>> > Promise<Optional&lt;GetPostalCode>> result = current.map(child ->
>>> > {
>>> > // do something
>>> > return Optional.empty();
>>> > }).orElseGet(() ->
>>> > {
>>> > return getPostalCode();
>>> > });
>>> > return result;
>>> >
>>> > The line triggering the error is: "return getPostalCode()"
>>> >
>>> > Here's my problem:
>>> >
>>> > 1. getPostalCode() returns "Promise<Optional&lt;GetPostalCode>>"
>>> > 2. "result" is of the same type.
>>> > 3. Looking at this code, it's not obvious why the compiler is 
>>> trying to cast
>>> > the output to "Optional"
>>> >
>>> > I've run across this kind of problem very often. The problem I am 
>>> referring
>>> > to is not the specific error message but rather the fact that 
>>> you're forcing
>>> > developers to reverse engineer the compiler in their head to 
>>> figure out what
>>> > is going wrong.
>>> >
>>> > Instead of forcing developers to do figure out why the compiler is
>>> > attempting a seemingly wrong cast, couldn't the error message 
>>> explain it
>>> > explicitly? I don't mind passing extra command-line parameters 
>>> into the
>>> > compiler to get more verbose explanations, so long as this is 
>>> possible.
>>> >
>>> > The second kind of error I am running into is:
>>> >
>>> > method thenApply in class Promise<T> cannot be applied to given 
>>> types;
>>> >    required: Function<? super PostProperty,? extends U>
>>> >    found: this::addProperty
>>> >    reason: cannot infer type-variable(s) U
>>> >      (argument mismatch; bad return type in method reference
>>> >        void cannot be converted to U)
>>> >    where U,T are type-variables:
>>> >      U extends Object declared in method <U>thenApply(Function<? 
>>> super T,?
>>> > extends U>)
>>> >      T extends Object declared in class Promise
>>> >
>>> > I don't know about you, but (as a human being) I find this message 
>>> very hard
>>> > to read. It sounds as if the message was written for computers to 
>>> parse, not
>>> > people. What the compiler is actually trying to say is that
>>> > "this::addProperty returns void but thenApply() expects it to 
>>> return a type
>>> > that extends Object".
>>> >
>>> > Is it possible for someone to investigate improving these messages?
>>> >
>>> > Thank you,
>>> > Gili
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context: 
>>> http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424.html
>>> > Sent from the OpenJDK Compiler Development mailing list archive at 
>>> Nabble.com.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> If you reply to this email, your message will be added to the 
>>> discussion below:
>>> http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209427.html 
>>>
>>> To unsubscribe from Improving readability of type/casting error 
>>> messages, click here 
>>> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=209424&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8MjA5NDI0fDE1NzQzMjEyNDc=>.
>>> NAML 
>>> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>>>
>>
>





--
View this message in context: http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209440.html
Sent from the OpenJDK Compiler Development mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141204/81a0550e/attachment-0001.html>

From pooja.chopra at oracle.com  Fri Dec  5 05:39:52 2014
From: pooja.chopra at oracle.com (pooja chopra)
Date: Fri, 05 Dec 2014 11:09:52 +0530
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <5460EF0C.6090501@oracle.com>
References: <5460EF0C.6090501@oracle.com>
Message-ID: <54814528.7020501@oracle.com>

Hi  All,
Gentle Reminder . Please review below fix .

8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails with 
exit code 1
Test bug fix.
https://bugs.openjdk.java.net/browse/JDK-8064454
The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/

Regards,
Pooja
On 11/10/2014 10:29 PM, pooja chopra wrote:
>
> Hello,
> Please review a fix for the issue:
> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
> with exit code 1
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8064454
> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>
> Thanks
> Pooja


From maurizio.cimadamore at oracle.com  Fri Dec  5 17:56:58 2014
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 05 Dec 2014 17:56:58 +0000
Subject: Improving readability of type/casting error messages
In-Reply-To: <1417745133663-209424.post@n7.nabble.com>
References: <1417745133663-209424.post@n7.nabble.com>
Message-ID: <5481F1EA.8090508@oracle.com>


On 05/12/14 02:05, cowwoc wrote:
> I'll start by discussing a seemingly benign error message:
>
> incompatible types: bad return type in lambda expression
>      Promise<Optional&lt;GetPostalCode>> cannot be converted to Optional
Hi Gili,
are you sure you are pasting the entire output? Or maybe something more 
subtle is going on? Look at this example:

import java.util.function.*;
import java.util.*;

class Test {
     void test() {
         m(ls -> ls);
     }

     void m(Function<List<String>, List<Integer>> l) { }
}


Which gives this:

Main.java:6: error: incompatible types: bad return type in lambda expression
         m(ls -> ls);
                 ^
     List<String> cannot be converted to List<Integer>

Note that both actual and expected type are shown after type 
substitution. I don't exactly get why you are getting a bare 'Option' in 
your example - is some unchecked conversion going on?

Maurizio

From jonathan.gibbons at oracle.com  Sat Dec  6 02:53:34 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 05 Dec 2014 18:53:34 -0800
Subject: RFR: 8066807: langtools/test/Makefile should use -agentvm not -samevm
Message-ID: <54826FAE.1070109@oracle.com>

Simple fix to have langtools/test/Makefile use agentvm mode instead of 
samevm mode as the default.  agentvm mode is generally recommended over 
samevm in a batch execution environment because of better recovery after 
test failures.

(Also fixed a couple of archaic default paths that are typically never 
used.)

-- Jon



From jonathan.gibbons at oracle.com  Sat Dec  6 02:57:43 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 05 Dec 2014 18:57:43 -0800
Subject: RFR: 8066808: langtools/test/Makefile should not use OS-specific
	jtreg binary
Message-ID: <548270A7.8060504@oracle.com>

For historical reasons, jtreg used to ship with three identical copies 
of the same launch script, in $JTREG_HOME/{win32,solaris,linux}/bin.

That is finally being phased out in favor of a single script in the 
$JTREG_HOME/bin directory.

This fix updates the langtools/test/Makefile accordingly.

http://cr.openjdk.java.net/~jjg/8066808/webrev.00/

-- Jon

From jonathan.gibbons at oracle.com  Sat Dec  6 02:58:16 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 05 Dec 2014 18:58:16 -0800
Subject: RFR: 8066807: langtools/test/Makefile should use -agentvm not
	-samevm
In-Reply-To: <54826FAE.1070109@oracle.com>
References: <54826FAE.1070109@oracle.com>
Message-ID: <548270C8.4010002@oracle.com>


On 12/05/2014 06:53 PM, Jonathan Gibbons wrote:
> Simple fix to have langtools/test/Makefile use agentvm mode instead of 
> samevm mode as the default.  agentvm mode is generally recommended 
> over samevm in a batch execution environment because of better 
> recovery after test failures.
>
> (Also fixed a couple of archaic default paths that are typically never 
> used.)
>
> -- Jon
>
>

Doh:
http://cr.openjdk.java.net/~jjg/8066807/webrev.00/

-- Jon

From peter.levart at gmail.com  Sat Dec  6 19:20:11 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 06 Dec 2014 20:20:11 +0100
Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK
Message-ID: <548356EB.7000601@gmail.com>

Hi,

I thought I might inform you that recent checkout of JDK9 (with modular 
RT images) fails to build with JDK8u25 as bootstrap JDK. With JDK8u20 it 
works correctly. Tried on Linux and Windows. The configuration on Linux is:

Configuration summary:
* Debug level:    release
* HS debug level: product
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:       java version "1.8.0_25" Java(TM) SE Runtime 
Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM 
(build 25.25-b02, mixed mode)  (at /home/peter/Apps64/jdk1.8.0)
* Toolchain:      gcc (GNU Compiler Collection)
* C Compiler:     Version 4.8.3 (at /usr/bin/gcc)
* C++ Compiler:   Version 4.8.3 (at /usr/bin/g++)

Build performance summary:
* Cores to use:   7
* Memory limit:   15757 MB


Here's the build session:

[peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release images
Building 'linux-x86_64-normal-server-release' (matching 
CONF=linux-x86_64-normal-server-release)
Building OpenJDK for target 'images' in configuration 
'linux-x86_64-normal-server-release'

Compiling 1 files for BUILD_TOOLS_LANGTOOLS
Compiling 20 properties into resource bundles for jdk.compiler
Compiling 10 properties into resource bundles for jdk.javadoc
Compiling 5 properties into resource bundles for jdk.dev
Compiling 818 files for BUILD_INTERIM_LANGTOOLS
warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
1 warning
1 warning
warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 warning
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Creating buildtools/interim_langtools.jar
Compiling 198 files for BUILD_INTERIM_RMIC
Compiling 23 files for BUILD_INTERIM_JIMAGE
Compiling 6 files for BUILD_TOOLS_CORBA
Compiling 141 files for BUILD_IDLJ
/home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: 
error: cannot find symbol
             LambdaForm form2 = mh.editor().filterArgumentForm(1+i, 
BasicType.basicType(newType));
                                  ^
   symbol:   method editor()
   location: variable mh of type BoundMethodHandle
/home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: 
error: cannot find symbol
             mh = mh.copyWithExtendL(midType, form2, fn);
                    ^
   symbol:   method copyWithExtendL(MethodType,LambdaForm,MethodHandle)
   location: variable mh of type BoundMethodHandle
/home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: 
error: cannot find symbol
                 LambdaForm form2 = 
mh.editor().filterReturnForm(BasicType.basicType(newType), false);
                                      ^
   symbol:   method editor()
   location: variable mh of type BoundMethodHandle

...etc...


It seems that something changed between JDK8u20 and JDK8u25 regarding 
bootclasspath handling of javac as the above errors suggest that JDK9 
sources are being compiled against JDK8 classes.


Regards, Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141206/d7594c44/attachment.html>

From Tobias.Werth at fau.de  Fri Dec  5 08:45:57 2014
From: Tobias.Werth at fau.de (Tobias Werth)
Date: Fri, 5 Dec 2014 09:45:57 +0100
Subject: [PATCH] Pretty printing for loops
Message-ID: <20141205084557.GC13527@faui20e.informatik.uni-erlangen.de>

Hi,

(if this is not the correct mailing list to submit those patches, please
tell me which one to use instead)

I stumbled upon a bug in the javac pretty printer. It misses a null
check while pretty printing for loops causing to produce invalid code.

The attached patch contains a fix including a test that fails before and
works after applying the patch.

Cheers,
Tobi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pp_forloop.patch
Type: text/x-patch
Size: 5543 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141205/dc259270/pp_forloop-0001.patch>

From stuart.marks at oracle.com  Sat Dec  6 21:03:13 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Sat, 06 Dec 2014 13:03:13 -0800
Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK
In-Reply-To: <548356EB.7000601@gmail.com>
References: <548356EB.7000601@gmail.com>
Message-ID: <54836F11.4020501@oracle.com>

[Adding build-dev to let them know others are seeing this. I'm not on jigsaw-dev 
though so this might not make it there.]

Hi Peter,

I ran into this myself the other day and had a wrestling match with it. There's 
a bug in the build system on this:

     https://bugs.openjdk.java.net/browse/JDK-8066761

My understanding is that this has to do with timestamps on the checked-out 
source files vs. the class files in the boot JDK. With 8u20 as boot, all the 
class files are out of date w.r.t. the source files so everything is rebuilt. 
With 8u25, some class files might be newer than the source files, if you've been 
using the same source tree for a long time (as many of us have).

The workaround is to touch all the source files in the jdk repo before doing a 
clean build:

     $ cd jdk; hg manifest | xargs touch

or do

     $ cd jdk; hg update null; hg update tip

to re-checkout all the files.

The root cause seems to be inadvertent dependency checks against classes in the 
boot JDK, which cause the build to mix in old class files from the boot JDK. 
Obviously if you do a fresh build, everything ought to be out of date, 
regardless of which boot JDK is in use.

s'marks

On 12/6/14 11:20 AM, Peter Levart wrote:
> Hi,
>
> I thought I might inform you that recent checkout of JDK9 (with modular RT 
> images) fails to build with JDK8u25 as bootstrap JDK. With JDK8u20 it works 
> correctly. Tried on Linux and Windows. The configuration on Linux is:
>
> Configuration summary:
> * Debug level:    release
> * HS debug level: product
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>
> Tools summary:
> * Boot JDK:       java version "1.8.0_25" Java(TM) SE Runtime Environment 
> (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed 
> mode)  (at /home/peter/Apps64/jdk1.8.0)
> * Toolchain:      gcc (GNU Compiler Collection)
> * C Compiler:     Version 4.8.3 (at /usr/bin/gcc)
> * C++ Compiler:   Version 4.8.3 (at /usr/bin/g++)
>
> Build performance summary:
> * Cores to use:   7
> * Memory limit:   15757 MB
>
>
> Here's the build session:
>
> [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release images
> Building 'linux-x86_64-normal-server-release' (matching 
> CONF=linux-x86_64-normal-server-release)
> Building OpenJDK for target 'images' in configuration 
> 'linux-x86_64-normal-server-release'
>
> Compiling 1 files for BUILD_TOOLS_LANGTOOLS
> Compiling 20 properties into resource bundles for jdk.compiler
> Compiling 10 properties into resource bundles for jdk.javadoc
> Compiling 5 properties into resource bundles for jdk.dev
> Compiling 818 files for BUILD_INTERIM_LANGTOOLS
> warning: [options] bootstrap class path not set in conjunction with -source 1.6
> warning: [options] bootstrap class path not set in conjunction with -source 1.6
> 1 warning
> 1 warning
> warning: [options] bootstrap class path not set in conjunction with -source 1.6
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
> Warning: generation and use of skeletons and static stubs for JRMP
> is deprecated. Skeletons are unnecessary, and static stubs have
> been superseded by dynamically generated stubs. Users are
> encouraged to migrate away from using rmic to generate skeletons and static
> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
> Creating buildtools/interim_langtools.jar
> Compiling 198 files for BUILD_INTERIM_RMIC
> Compiling 23 files for BUILD_INTERIM_JIMAGE
> Compiling 6 files for BUILD_TOOLS_CORBA
> Compiling 141 files for BUILD_IDLJ
> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: 
> error: cannot find symbol
>             LambdaForm form2 = mh.editor().filterArgumentForm(1+i, 
> BasicType.basicType(newType));
>                                  ^
>   symbol:   method editor()
>   location: variable mh of type BoundMethodHandle
> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: 
> error: cannot find symbol
>             mh = mh.copyWithExtendL(midType, form2, fn);
>                    ^
>   symbol:   method copyWithExtendL(MethodType,LambdaForm,MethodHandle)
>   location: variable mh of type BoundMethodHandle
> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: 
> error: cannot find symbol
>                 LambdaForm form2 = 
> mh.editor().filterReturnForm(BasicType.basicType(newType), false);
>                                      ^
>   symbol:   method editor()
>   location: variable mh of type BoundMethodHandle
>
> ...etc...
>
>
> It seems that something changed between JDK8u20 and JDK8u25 regarding 
> bootclasspath handling of javac as the above errors suggest that JDK9 sources 
> are being compiled against JDK8 classes.
>
>
> Regards, Peter
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141206/d7838244/attachment.html>

From philip.race at oracle.com  Sat Dec  6 21:22:56 2014
From: philip.race at oracle.com (Phil Race)
Date: Sat, 06 Dec 2014 13:22:56 -0800
Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK
In-Reply-To: <54836F11.4020501@oracle.com>
References: <548356EB.7000601@gmail.com> <54836F11.4020501@oracle.com>
Message-ID: <548373B0.90901@oracle.com>

yep lots of people have reported this/seen this

-phil.

On 12/6/14 1:03 PM, Stuart Marks wrote:
> [Adding build-dev to let them know others are seeing this. I'm not on 
> jigsaw-dev though so this might not make it there.]
>
> Hi Peter,
>
> I ran into this myself the other day and had a wrestling match with 
> it. There's a bug in the build system on this:
>
>     https://bugs.openjdk.java.net/browse/JDK-8066761
>
> My understanding is that this has to do with timestamps on the 
> checked-out source files vs. the class files in the boot JDK. With 
> 8u20 as boot, all the class files are out of date w.r.t. the source 
> files so everything is rebuilt. With 8u25, some class files might be 
> newer than the source files, if you've been using the same source tree 
> for a long time (as many of us have).
>
> The workaround is to touch all the source files in the jdk repo before 
> doing a clean build:
>
>     $ cd jdk; hg manifest | xargs touch
>
> or do
>
>     $ cd jdk; hg update null; hg update tip
>
> to re-checkout all the files.
>
> The root cause seems to be inadvertent dependency checks against 
> classes in the boot JDK, which cause the build to mix in old class 
> files from the boot JDK. Obviously if you do a fresh build, everything 
> ought to be out of date, regardless of which boot JDK is in use.
>
> s'marks
>
> On 12/6/14 11:20 AM, Peter Levart wrote:
>> Hi,
>>
>> I thought I might inform you that recent checkout of JDK9 (with 
>> modular RT images) fails to build with JDK8u25 as bootstrap JDK. With 
>> JDK8u20 it works correctly. Tried on Linux and Windows. The 
>> configuration on Linux is:
>>
>> Configuration summary:
>> * Debug level:    release
>> * HS debug level: product
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>>
>> Tools summary:
>> * Boot JDK:       java version "1.8.0_25" Java(TM) SE Runtime 
>> Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM 
>> (build 25.25-b02, mixed mode)  (at /home/peter/Apps64/jdk1.8.0)
>> * Toolchain:      gcc (GNU Compiler Collection)
>> * C Compiler:     Version 4.8.3 (at /usr/bin/gcc)
>> * C++ Compiler:   Version 4.8.3 (at /usr/bin/g++)
>>
>> Build performance summary:
>> * Cores to use:   7
>> * Memory limit:   15757 MB
>>
>>
>> Here's the build session:
>>
>> [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release 
>> images
>> Building 'linux-x86_64-normal-server-release' (matching 
>> CONF=linux-x86_64-normal-server-release)
>> Building OpenJDK for target 'images' in configuration 
>> 'linux-x86_64-normal-server-release'
>>
>> Compiling 1 files for BUILD_TOOLS_LANGTOOLS
>> Compiling 20 properties into resource bundles for jdk.compiler
>> Compiling 10 properties into resource bundles for jdk.javadoc
>> Compiling 5 properties into resource bundles for jdk.dev
>> Compiling 818 files for BUILD_INTERIM_LANGTOOLS
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> 1 warning
>> 1 warning
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> 1 warning
>> Warning: generation and use of skeletons and static stubs for JRMP
>> is deprecated. Skeletons are unnecessary, and static stubs have
>> been superseded by dynamically generated stubs. Users are
>> encouraged to migrate away from using rmic to generate skeletons and 
>> static
>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
>> Creating buildtools/interim_langtools.jar
>> Compiling 198 files for BUILD_INTERIM_RMIC
>> Compiling 23 files for BUILD_INTERIM_JIMAGE
>> Compiling 6 files for BUILD_TOOLS_CORBA
>> Compiling 141 files for BUILD_IDLJ
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: 
>> error: cannot find symbol
>>             LambdaForm form2 = mh.editor().filterArgumentForm(1+i, 
>> BasicType.basicType(newType));
>>                                  ^
>>   symbol:   method editor()
>>   location: variable mh of type BoundMethodHandle
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: 
>> error: cannot find symbol
>>             mh = mh.copyWithExtendL(midType, form2, fn);
>>                    ^
>>   symbol:   method copyWithExtendL(MethodType,LambdaForm,MethodHandle)
>>   location: variable mh of type BoundMethodHandle
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: 
>> error: cannot find symbol
>>                 LambdaForm form2 = 
>> mh.editor().filterReturnForm(BasicType.basicType(newType), false);
>>                                      ^
>>   symbol:   method editor()
>>   location: variable mh of type BoundMethodHandle
>>
>> ...etc...
>>
>>
>> It seems that something changed between JDK8u20 and JDK8u25 regarding 
>> bootclasspath handling of javac as the above errors suggest that JDK9 
>> sources are being compiled against JDK8 classes.
>>
>>
>> Regards, Peter
>>
>>
>


From tim.bell at oracle.com  Sat Dec  6 22:17:58 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Sat, 06 Dec 2014 14:17:58 -0800
Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK
In-Reply-To: <548356EB.7000601@gmail.com>
References: <548356EB.7000601@gmail.com>
Message-ID: <54838096.30204@oracle.com>

Hi Peter:

I believe this is being discussed under bug #JDK-8066761 
<https://bugs.openjdk.java.net/browse/JDK-8066761>
*Investigate -sourcepath usage in when compiling java* 
<https://bugs.openjdk.java.net/browse/JDK-8066761>

HTH-

Tim

> I thought I might inform you that recent checkout of JDK9 (with 
> modular RT images) fails to build with JDK8u25 as bootstrap JDK. With 
> JDK8u20 it works correctly. Tried on Linux and Windows. The 
> configuration on Linux is:
>
> Configuration summary:
> * Debug level:    release
> * HS debug level: product
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>
> Tools summary:
> * Boot JDK:       java version "1.8.0_25" Java(TM) SE Runtime 
> Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM 
> (build 25.25-b02, mixed mode)  (at /home/peter/Apps64/jdk1.8.0)
> * Toolchain:      gcc (GNU Compiler Collection)
> * C Compiler:     Version 4.8.3 (at /usr/bin/gcc)
> * C++ Compiler:   Version 4.8.3 (at /usr/bin/g++)
>
> Build performance summary:
> * Cores to use:   7
> * Memory limit:   15757 MB
>
>
> Here's the build session:
>
> [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release 
> images
> Building 'linux-x86_64-normal-server-release' (matching 
> CONF=linux-x86_64-normal-server-release)
> Building OpenJDK for target 'images' in configuration 
> 'linux-x86_64-normal-server-release'
>
> Compiling 1 files for BUILD_TOOLS_LANGTOOLS
> Compiling 20 properties into resource bundles for jdk.compiler
> Compiling 10 properties into resource bundles for jdk.javadoc
> Compiling 5 properties into resource bundles for jdk.dev
> Compiling 818 files for BUILD_INTERIM_LANGTOOLS
> warning: [options] bootstrap class path not set in conjunction with 
> -source 1.6
> warning: [options] bootstrap class path not set in conjunction with 
> -source 1.6
> 1 warning
> 1 warning
> warning: [options] bootstrap class path not set in conjunction with 
> -source 1.6
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> 1 warning
> Warning: generation and use of skeletons and static stubs for JRMP
> is deprecated. Skeletons are unnecessary, and static stubs have
> been superseded by dynamically generated stubs. Users are
> encouraged to migrate away from using rmic to generate skeletons and 
> static
> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
> Creating buildtools/interim_langtools.jar
> Compiling 198 files for BUILD_INTERIM_RMIC
> Compiling 23 files for BUILD_INTERIM_JIMAGE
> Compiling 6 files for BUILD_TOOLS_CORBA
> Compiling 141 files for BUILD_IDLJ
> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: 
> error: cannot find symbol
>             LambdaForm form2 = mh.editor().filterArgumentForm(1+i, 
> BasicType.basicType(newType));
>                                  ^
>   symbol:   method editor()
>   location: variable mh of type BoundMethodHandle
> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: 
> error: cannot find symbol
>             mh = mh.copyWithExtendL(midType, form2, fn);
>                    ^
>   symbol:   method copyWithExtendL(MethodType,LambdaForm,MethodHandle)
>   location: variable mh of type BoundMethodHandle
> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: 
> error: cannot find symbol
>                 LambdaForm form2 = 
> mh.editor().filterReturnForm(BasicType.basicType(newType), false);
>                                      ^
>   symbol:   method editor()
>   location: variable mh of type BoundMethodHandle
>
> ...etc...
>
>
> It seems that something changed between JDK8u20 and JDK8u25 regarding 
> bootclasspath handling of javac as the above errors suggest that JDK9 
> sources are being compiled against JDK8 classes.
>
>
> Regards, Peter
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141206/f298e571/attachment-0001.html>

From peter.levart at gmail.com  Sun Dec  7 00:02:30 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 07 Dec 2014 01:02:30 +0100
Subject: Modular Run-Time Images build fails with JDK8u25 as bootstrap JDK
In-Reply-To: <54836F11.4020501@oracle.com>
References: <548356EB.7000601@gmail.com> <54836F11.4020501@oracle.com>
Message-ID: <54839916.3070306@gmail.com>

Hi Stuart and Phil and Tim,

Thanks for explanation. This must be it, yes. I'll try upgrading to 
JDK8u25 again (just downgraded to u20) and see if touching sources helps.

Regards, Peter

On 12/06/2014 10:03 PM, Stuart Marks wrote:
> [Adding build-dev to let them know others are seeing this. I'm not on 
> jigsaw-dev though so this might not make it there.]
>
> Hi Peter,
>
> I ran into this myself the other day and had a wrestling match with 
> it. There's a bug in the build system on this:
>
> https://bugs.openjdk.java.net/browse/JDK-8066761
>
> My understanding is that this has to do with timestamps on the 
> checked-out source files vs. the class files in the boot JDK. With 
> 8u20 as boot, all the class files are out of date w.r.t. the source 
> files so everything is rebuilt. With 8u25, some class files might be 
> newer than the source files, if you've been using the same source tree 
> for a long time (as many of us have).
>
> The workaround is to touch all the source files in the jdk repo before 
> doing a clean build:
>
>     $ cd jdk; hg manifest | xargs touch
>
> or do
>
>     $ cd jdk; hg update null; hg update tip
>
> to re-checkout all the files.
>
> The root cause seems to be inadvertent dependency checks against 
> classes in the boot JDK, which cause the build to mix in old class 
> files from the boot JDK. Obviously if you do a fresh build, everything 
> ought to be out of date, regardless of which boot JDK is in use.
>
> s'marks
>
> On 12/6/14 11:20 AM, Peter Levart wrote:
>> Hi,
>>
>> I thought I might inform you that recent checkout of JDK9 (with 
>> modular RT images) fails to build with JDK8u25 as bootstrap JDK. With 
>> JDK8u20 it works correctly. Tried on Linux and Windows. The 
>> configuration on Linux is:
>>
>> Configuration summary:
>> * Debug level:    release
>> * HS debug level: product
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>>
>> Tools summary:
>> * Boot JDK:       java version "1.8.0_25" Java(TM) SE Runtime 
>> Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM 
>> (build 25.25-b02, mixed mode)  (at /home/peter/Apps64/jdk1.8.0)
>> * Toolchain:      gcc (GNU Compiler Collection)
>> * C Compiler:     Version 4.8.3 (at /usr/bin/gcc)
>> * C++ Compiler:   Version 4.8.3 (at /usr/bin/g++)
>>
>> Build performance summary:
>> * Cores to use:   7
>> * Memory limit:   15757 MB
>>
>>
>> Here's the build session:
>>
>> [peter at cube jdk9-dev]$ make CONF=linux-x86_64-normal-server-release 
>> images
>> Building 'linux-x86_64-normal-server-release' (matching 
>> CONF=linux-x86_64-normal-server-release)
>> Building OpenJDK for target 'images' in configuration 
>> 'linux-x86_64-normal-server-release'
>>
>> Compiling 1 files for BUILD_TOOLS_LANGTOOLS
>> Compiling 20 properties into resource bundles for jdk.compiler
>> Compiling 10 properties into resource bundles for jdk.javadoc
>> Compiling 5 properties into resource bundles for jdk.dev
>> Compiling 818 files for BUILD_INTERIM_LANGTOOLS
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> 1 warning
>> 1 warning
>> warning: [options] bootstrap class path not set in conjunction with 
>> -source 1.6
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> 1 warning
>> Warning: generation and use of skeletons and static stubs for JRMP
>> is deprecated. Skeletons are unnecessary, and static stubs have
>> been superseded by dynamically generated stubs. Users are
>> encouraged to migrate away from using rmic to generate skeletons and 
>> static
>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
>> Creating buildtools/interim_langtools.jar
>> Compiling 198 files for BUILD_INTERIM_RMIC
>> Compiling 23 files for BUILD_INTERIM_JIMAGE
>> Compiling 6 files for BUILD_TOOLS_CORBA
>> Compiling 141 files for BUILD_IDLJ
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:230: 
>> error: cannot find symbol
>>             LambdaForm form2 = mh.editor().filterArgumentForm(1+i, 
>> BasicType.basicType(newType));
>>                                  ^
>>   symbol:   method editor()
>>   location: variable mh of type BoundMethodHandle
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:231: 
>> error: cannot find symbol
>>             mh = mh.copyWithExtendL(midType, form2, fn);
>>                    ^
>>   symbol:   method copyWithExtendL(MethodType,LambdaForm,MethodHandle)
>>   location: variable mh of type BoundMethodHandle
>> /home/peter/work/hg/jdk9-dev/jdk/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java:250: 
>> error: cannot find symbol
>>                 LambdaForm form2 = 
>> mh.editor().filterReturnForm(BasicType.basicType(newType), false);
>>                                      ^
>>   symbol:   method editor()
>>   location: variable mh of type BoundMethodHandle
>>
>> ...etc...
>>
>>
>> It seems that something changed between JDK8u20 and JDK8u25 regarding 
>> bootclasspath handling of javac as the above errors suggest that JDK9 
>> sources are being compiled against JDK8 classes.
>>
>>
>> Regards, Peter
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141207/58933fa4/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Dec  8 17:30:03 2014
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 08 Dec 2014 17:30:03 +0000
Subject: RFR: 8066807: langtools/test/Makefile should use -agentvm not
	-samevm
In-Reply-To: <548270C8.4010002@oracle.com>
References: <54826FAE.1070109@oracle.com> <548270C8.4010002@oracle.com>
Message-ID: <5485E01B.1010701@oracle.com>

Looks good.

Maurizio

On 06/12/14 02:58, Jonathan Gibbons wrote:
>
> On 12/05/2014 06:53 PM, Jonathan Gibbons wrote:
>> Simple fix to have langtools/test/Makefile use agentvm mode instead 
>> of samevm mode as the default.  agentvm mode is generally recommended 
>> over samevm in a batch execution environment because of better 
>> recovery after test failures.
>>
>> (Also fixed a couple of archaic default paths that are typically 
>> never used.)
>>
>> -- Jon
>>
>>
>
> Doh:
> http://cr.openjdk.java.net/~jjg/8066807/webrev.00/
>
> -- Jon


From maurizio.cimadamore at oracle.com  Mon Dec  8 17:30:16 2014
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 08 Dec 2014 17:30:16 +0000
Subject: RFR: 8066808: langtools/test/Makefile should not use OS-specific
	jtreg binary
In-Reply-To: <548270A7.8060504@oracle.com>
References: <548270A7.8060504@oracle.com>
Message-ID: <5485E028.5010407@oracle.com>

Approved.

Maurizio

On 06/12/14 02:57, Jonathan Gibbons wrote:
> For historical reasons, jtreg used to ship with three identical copies 
> of the same launch script, in $JTREG_HOME/{win32,solaris,linux}/bin.
>
> That is finally being phased out in favor of a single script in the 
> $JTREG_HOME/bin directory.
>
> This fix updates the langtools/test/Makefile accordingly.
>
> http://cr.openjdk.java.net/~jjg/8066808/webrev.00/
>
> -- Jon


From openjdk at duigou.org  Tue Dec  9 22:55:04 2014
From: openjdk at duigou.org (Mike Duigou)
Date: Tue, 09 Dec 2014 14:55:04 -0800
Subject: line number of bridge method
Message-ID: <b1a472931fbbbbe9cfceea5f98213c9f@sonic.net>

Would it be possible to have the debug line number of a bridge method be 
the line number of the method it is a bridge for rather than the first 
line of the class?

java.lang.ClassCastException: java.lang.Byte cannot be cast to 
java.lang.String
at com.foo.bar.MyHashMap.put(MyHashMap.java:18)

MyHashMap is declared as "extends HashMap<String,Object>" so there is a 
put(String, Object) bridge method in addition to the put(Object, Object) 
method.

Understandably if MyHashMap were to not override put(Object, Object) and 
just use HashMap's implementation it would probably be necessary to use 
the current "first line of the class" solution for the put(String, 
Object) bridge method.

Cheers,

Mike


From robert.field at oracle.com  Tue Dec  9 23:28:31 2014
From: robert.field at oracle.com (Robert Field)
Date: Tue, 09 Dec 2014 15:28:31 -0800
Subject: line number of bridge method
In-Reply-To: <b1a472931fbbbbe9cfceea5f98213c9f@sonic.net>
References: <b1a472931fbbbbe9cfceea5f98213c9f@sonic.net>
Message-ID: <5487859F.9050903@oracle.com>

I believe the downside of having line numbers is you then would, in a 
debugger, step into the bridge.

-Robert


On 12/09/14 14:55, Mike Duigou wrote:
> Would it be possible to have the debug line number of a bridge method 
> be the line number of the method it is a bridge for rather than the 
> first line of the class?
>
> java.lang.ClassCastException: java.lang.Byte cannot be cast to 
> java.lang.String
> at com.foo.bar.MyHashMap.put(MyHashMap.java:18)
>
> MyHashMap is declared as "extends HashMap<String,Object>" so there is 
> a put(String, Object) bridge method in addition to the put(Object, 
> Object) method.
>
> Understandably if MyHashMap were to not override put(Object, Object) 
> and just use HashMap's implementation it would probably be necessary 
> to use the current "first line of the class" solution for the 
> put(String, Object) bridge method.
>
> Cheers,
>
> Mike
>


From eric.mccorkle at oracle.com  Wed Dec 10 17:28:42 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 10 Dec 2014 12:28:42 -0500
Subject: Review request for 8067039: Revert changes to annotation attribute
	generation
Message-ID: <548882CA.5030601@oracle.com>

Hello,

Please review this patch which reverts JDK-8029012 and JDK-8065132 in
8u.  This is necessary due to an issue with generic signatures related
to JDK-8067039, which prevents previous versions of javac in 8 from
being able to load classfiles generated by the current (8u40) version.

The bug is here:
https://bugs.openjdk.java.net/browse/JDK-8067039

The webrev is here:
http://cr.openjdk.java.net/~emc/8067039/

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: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141210/8dc61814/eric_mccorkle-0001.vcf>

From andreas.lundblad at oracle.com  Thu Dec 11 10:45:28 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Thu, 11 Dec 2014 11:45:28 +0100
Subject: RFR: 8054717: SJavac should track changes in the public apis of
	classpath classes!
In-Reply-To: <20141204155932.GC28610@e6430>
References: <20141127012617.GA17122@e6430>
 <20141204155932.GC28610@e6430>
Message-ID: <20141211104528.GA18525@e6430>

On Thu, Dec 04, 2014 at 04:59:33PM +0100, Andreas Lundblad wrote:
> On Thu, Nov 27, 2014 at 02:26:18AM +0100, Andreas Lundblad wrote:
> > [...]
> > 
> > Link to web review:
> > http://cr.openjdk.java.net/~alundblad/8054717
> > 
> > Link to bug report:
> > http://bugs.openjdk.java.net/browse/JDK-8054717
> > 
> > -- Andreas Lundblad

Another revision up for review.

This fixes a bug where sjavac erroneously compiled too many files after just touching a source file.

-- Andreas

From erik.joelsson at oracle.com  Thu Dec 11 11:43:07 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 11 Dec 2014 12:43:07 +0100
Subject: RFR: 8054717: SJavac should track changes in the public apis
	of classpath classes!
In-Reply-To: <20141211104528.GA18525@e6430>
References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430>
	<20141211104528.GA18525@e6430>
Message-ID: <5489834B.8040102@oracle.com>

Hello,

This version seems to be working quite well for me at least. Only thing 
I've noticed is a confusing log message. After a full build:

$ touch jdk/src/java.base/share/classes/java/lang/Object.java
$ make LOG=info
...
Compiling java.base
Starting server. Command: /localhome/java/default/bin/java -d64 -Xms512M 
-Xmx2048M 
-Xbootclasspath/p:/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar 
-cp 
/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar 
com.sun.tools.sjavac.Main 
--startserver:portfile=/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/javacservers/server.port,logfile=/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/javacservers/server.port.javaclog,stdouterrfile=/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/javacservers/server.port.stdouterr,poolsize=32,keepalive=120
Trying to connect. Attempt 1 of 3
Connected
Compiling java.lang(118) (with 1 dependents)
Trying to connect. Attempt 1 of 3
Connected
The pubapi of java.lang.Character has changed!
...

I'm pretty sure java.lang.Character didn't change and sjavac seems to be 
behaving correctly by not acting like it has. I'm also wondering why the 
messages about connect are printed twice. I'm fine with fixing this in a 
followup bug.

/Erik

On 2014-12-11 11:45, Andreas Lundblad wrote:
> On Thu, Dec 04, 2014 at 04:59:33PM +0100, Andreas Lundblad wrote:
>> On Thu, Nov 27, 2014 at 02:26:18AM +0100, Andreas Lundblad wrote:
>>> [...]
>>>
>>> Link to web review:
>>> http://cr.openjdk.java.net/~alundblad/8054717
>>>
>>> Link to bug report:
>>> http://bugs.openjdk.java.net/browse/JDK-8054717
>>>
>>> -- Andreas Lundblad
> Another revision up for review.
>
> This fixes a bug where sjavac erroneously compiled too many files after just touching a source file.
>
> -- Andreas


From andreas.lundblad at oracle.com  Thu Dec 11 14:35:35 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Thu, 11 Dec 2014 15:35:35 +0100
Subject: RFR: 8054717: SJavac should track changes in the public apis of
	classpath classes!
In-Reply-To: <5489834B.8040102@oracle.com>
References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430>
	<20141211104528.GA18525@e6430> <5489834B.8040102@oracle.com>
Message-ID: <20141211143535.GB18525@e6430>

On Thu, Dec 11, 2014 at 12:43:07PM +0100, Erik Joelsson wrote:
> Hello,
> 
> This version seems to be working quite well for me at least. Only
> thing I've noticed is a confusing log message. After a full build:
> 
> $ touch jdk/src/java.base/share/classes/java/lang/Object.java
> $ make LOG=info
> ...
> Compiling java.base
> Starting server. Command: /localhome/java/default/bin/java -d64
> -Xms512M -Xmx2048M -Xbootclasspath/p:/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar
> -cp /localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar
> com.sun.tools.sjavac.Main --startserver:portfile=/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/javacservers/server.port,logfile=/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/javacservers/server.port.javaclog,stdouterrfile=/localhome/hg/jdk9-dev-sjavacpatch/build/linux-x86_64-normal-server-release/javacservers/server.port.stdouterr,poolsize=32,keepalive=120
> Trying to connect. Attempt 1 of 3
> Connected
> Compiling java.lang(118) (with 1 dependents)
> Trying to connect. Attempt 1 of 3
> Connected
> The pubapi of java.lang.Character has changed!
> ...
> 
> I'm pretty sure java.lang.Character didn't change and sjavac seems
> to be behaving correctly by not acting like it has. I'm also
> wondering why the messages about connect are printed twice. I'm fine
> with fixing this in a followup bug.


Sjavac treated java.lang.Character as a package because it contained an public inner class. New revision is up addressing this issue. Thanks for catching this.

The fact that two connections are made is because there are two calls involved: query server for memory constraints and the actual compile. I expect this to go away when sjavac is refactored to a thin client.

-- Andreas

From andreas.lundblad at oracle.com  Thu Dec 11 15:11:40 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Thu, 11 Dec 2014 16:11:40 +0100
Subject: Appending strings in Assert.check
Message-ID: <20141211151139.GC18525@e6430>

I recently discovered that the RunCodingRules test chokes on statements such as

    Assert.check(isFound, "Value not found: " + value);

due to the string concatenation in the second argument. I understand the purpose of this rule, but people (at least I) really want to be able to compose strings in error messages, and I bet the rule will lead to things like

    Assert.check(isFound, String.format("Value not found: %s", value));

or

   Assert.check(isFound, new StringBuilder("Value not found: " + value));

which obviously defeats the purpose of the rule.

I suggest we add a vararg check-method which accepts a format string + arguments, so we can write

    Assert.check(isFound, "Value not found: %s", value);

(and carry out the formatting if assertions are enabled and the condition is false)?

-- Andreas

From andreas.lundblad at oracle.com  Mon Dec 15 22:49:06 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Mon, 15 Dec 2014 23:49:06 +0100
Subject: RFR: 8054717: SJavac should track changes in the public apis of
	classpath classes!
In-Reply-To: <20141211104528.GA18525@e6430>
References: <20141127012617.GA17122@e6430> <20141204155932.GC28610@e6430>
	<20141211104528.GA18525@e6430>
Message-ID: <20141215224906.GB6858@e6430>

> > > [...]
> > > 
> > > Link to web review:
> > > http://cr.openjdk.java.net/~alundblad/8054717
> > > 
> > > Link to bug report:
> > > http://bugs.openjdk.java.net/browse/JDK-8054717
> > > 
> > > -- Andreas Lundblad

Another revision up for review.

This fixes a bug where sjavac erroneously recompiled files containing inner classes during incremental builds.

-- Andreas

From joel.franck at oracle.com  Wed Dec 17 17:18:28 2014
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Wed, 17 Dec 2014 18:18:28 +0100
Subject: RFR: 8061472 String.format in DeferredAttr.DeferredTypeMap
	constructor leads to excessive object creation
Message-ID: <0DE212AE-027B-4CE5-83B8-B36A0CA27E75@oracle.com>

Hi,

Claes in the performance team noticed that we spend a lot of time in String.format() in the constructor in DeferredTypeMap. For an sjavac compile of the jdk a profile could show as high as 2% time spent in that method, excluding the cost of garbage collection.

This simple fix results in up to a 5% performance enhancement compiling the Jdk in a micro benchmark setup.

Bug: https://bugs.openjdk.java.net/browse/JDK-8061472

Patch is really small:

cheers
/Joel

diff -r 46105e2a56c7 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Wed Dec 17 16:47:56 2014 +0000
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Wed Dec 17 17:58:33 2014 +0100
@@ -352,11 +352,26 @@
          * type are reversed after the speculative round finishes. This means the
          * expression tree will be left in a blank state.
          */
-        SPECULATIVE,
+        SPECULATIVE {
+             @Override
+             public String getDescriptiveName() {
+                 return "deferredTypeMap[SPECULATIVE]";
+             }
+         },
         /**
          * This is the plain type-checking mode. Produces side-effects on the underlying AST node
          */
-        CHECK
+        CHECK {
+             @Override
+             public String getDescriptiveName() {
+                 return "deferredTypeMap[CHECK]";
+             }
+         };
+
+         /**
+          * @return a descriptive name of this mode
+          */
+         public abstract String getDescriptiveName();
     }

     /**
@@ -849,7 +864,7 @@
         DeferredAttrContext deferredAttrContext;

         protected DeferredTypeMap(AttrMode mode, Symbol msym, MethodResolutionPhase phase) {
-            super(String.format("deferredTypeMap[%s]", mode));
+            super(mode.getDescriptiveName());
             this.deferredAttrContext = new DeferredAttrContext(mode, msym, phase,
                     infer.emptyContext, emptyDeferredAttrContext, types.noWarnings);
         }

From joel.franck at oracle.com  Thu Dec 18 13:41:32 2014
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Thu, 18 Dec 2014 14:41:32 +0100
Subject: RFR: 8061472 String.format in DeferredAttr.DeferredTypeMap
	constructor leads to excessive object creation
In-Reply-To: <0DE212AE-027B-4CE5-83B8-B36A0CA27E75@oracle.com>
References: <0DE212AE-027B-4CE5-83B8-B36A0CA27E75@oracle.com>
Message-ID: <4719CE01-9A31-4979-A6B5-062183B3B042@oracle.com>

Hi,

Jan suggested supplying the descriptive name with the enum constructor, which I agree reads better. New patch inline.

cheers
/Joel

diff -r 47926c290355 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Wed Dec 17 12:48:04 2014 -0800
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Thu Dec 18 14:28:34 2014 +0100
@@ -352,11 +352,24 @@
          * type are reversed after the speculative round finishes. This means the
          * expression tree will be left in a blank state.
          */
-        SPECULATIVE,
+        SPECULATIVE("deferredTypeMap[SPECULATIVE]"),
         /**
          * This is the plain type-checking mode. Produces side-effects on the underlying AST node
          */
-        CHECK
+        CHECK("deferredTypeMap[CHECK]");
+
+        /**
+         * Returns a descriptive name of this mode.
+         */
+        public String getDescriptiveName() {
+            return descriptiveName;
+        }
+
+        private final String descriptiveName;
+
+        private AttrMode(String descriptiveName) {
+            this.descriptiveName = descriptiveName;
+        }
     }

     /**
@@ -849,7 +862,7 @@
         DeferredAttrContext deferredAttrContext;

         protected DeferredTypeMap(AttrMode mode, Symbol msym, MethodResolutionPhase phase) {
-            super(String.format("deferredTypeMap[%s]", mode));
+            super(mode.getDescriptiveName());
             this.deferredAttrContext = new DeferredAttrContext(mode, msym, phase,
                     infer.emptyContext, emptyDeferredAttrContext, types.noWarnings);
         }

From vicente.romero at oracle.com  Thu Dec 18 19:03:30 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 18 Dec 2014 11:03:30 -0800
Subject: RFR: 8061472 String.format in DeferredAttr.DeferredTypeMap
	constructor leads to excessive object creation
In-Reply-To: <4719CE01-9A31-4979-A6B5-062183B3B042@oracle.com>
References: <0DE212AE-027B-4CE5-83B8-B36A0CA27E75@oracle.com>
	<4719CE01-9A31-4979-A6B5-062183B3B042@oracle.com>
Message-ID: <54932502.601@oracle.com>

Hi Joel,

Thanks for fixing this issue. I wrote a patch, actually a dirty hack :), 
like a year back to fix the same issue, while we were working on the 
performance rush. For several reasons that patch was never applied and 
was forgotten. So thank you very much for proposing a solution to the 
problem.

Approved with pleasure!
Vicente

On 12/18/2014 05:41 AM, Joel Borggr?n-Franck wrote:
> Hi,
>
> Jan suggested supplying the descriptive name with the enum constructor, which I agree reads better. New patch inline.
>
> cheers
> /Joel
>
> diff -r 47926c290355 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Wed Dec 17 12:48:04 2014 -0800
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Thu Dec 18 14:28:34 2014 +0100
> @@ -352,11 +352,24 @@
>            * type are reversed after the speculative round finishes. This means the
>            * expression tree will be left in a blank state.
>            */
> -        SPECULATIVE,
> +        SPECULATIVE("deferredTypeMap[SPECULATIVE]"),
>           /**
>            * This is the plain type-checking mode. Produces side-effects on the underlying AST node
>            */
> -        CHECK
> +        CHECK("deferredTypeMap[CHECK]");
> +
> +        /**
> +         * Returns a descriptive name of this mode.
> +         */
> +        public String getDescriptiveName() {
> +            return descriptiveName;
> +        }
> +
> +        private final String descriptiveName;
> +
> +        private AttrMode(String descriptiveName) {
> +            this.descriptiveName = descriptiveName;
> +        }
>       }
>
>       /**
> @@ -849,7 +862,7 @@
>           DeferredAttrContext deferredAttrContext;
>
>           protected DeferredTypeMap(AttrMode mode, Symbol msym, MethodResolutionPhase phase) {
> -            super(String.format("deferredTypeMap[%s]", mode));
> +            super(mode.getDescriptiveName());
>               this.deferredAttrContext = new DeferredAttrContext(mode, msym, phase,
>                       infer.emptyContext, emptyDeferredAttrContext, types.noWarnings);
>           }


From maurizio.cimadamore at oracle.com  Thu Dec 18 22:08:53 2014
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 18 Dec 2014 22:08:53 +0000
Subject: RFR: 8061472 String.format in DeferredAttr.DeferredTypeMap
	constructor leads to excessive object creation
In-Reply-To: <54932502.601@oracle.com>
References: <0DE212AE-027B-4CE5-83B8-B36A0CA27E75@oracle.com>	<4719CE01-9A31-4979-A6B5-062183B3B042@oracle.com>
	<54932502.601@oracle.com>
Message-ID: <54935075.1070301@oracle.com>

The fix looks ok - but it feels a bit odd for the AttrMode (which is a 
general enum) to be returning the name including the 'deferredTypeMap' 
string - as that's another class. Maybe a static 'EnumMap<AttrMode, 
String>' inside the DeferredAttrMap class would more encapsulated?

Maurizio

On 18/12/14 19:03, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Joel,
>
> Thanks for fixing this issue. I wrote a patch, actually a dirty hack 
> :), like a year back to fix the same issue, while we were working on 
> the performance rush. For several reasons that patch was never applied 
> and was forgotten. So thank you very much for proposing a solution to 
> the problem.
>
> Approved with pleasure!
> Vicente
>
> On 12/18/2014 05:41 AM, Joel Borggr?n-Franck wrote:
>> Hi,
>>
>> Jan suggested supplying the descriptive name with the enum 
>> constructor, which I agree reads better. New patch inline.
>>
>> cheers
>> /Joel
>>
>> diff -r 47926c290355 
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
>> --- 
>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java 
>> Wed Dec 17 12:48:04 2014 -0800
>> +++ 
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java 
>> Thu Dec 18 14:28:34 2014 +0100
>> @@ -352,11 +352,24 @@
>>            * type are reversed after the speculative round finishes. 
>> This means the
>>            * expression tree will be left in a blank state.
>>            */
>> -        SPECULATIVE,
>> +        SPECULATIVE("deferredTypeMap[SPECULATIVE]"),
>>           /**
>>            * This is the plain type-checking mode. Produces 
>> side-effects on the underlying AST node
>>            */
>> -        CHECK
>> +        CHECK("deferredTypeMap[CHECK]");
>> +
>> +        /**
>> +         * Returns a descriptive name of this mode.
>> +         */
>> +        public String getDescriptiveName() {
>> +            return descriptiveName;
>> +        }
>> +
>> +        private final String descriptiveName;
>> +
>> +        private AttrMode(String descriptiveName) {
>> +            this.descriptiveName = descriptiveName;
>> +        }
>>       }
>>
>>       /**
>> @@ -849,7 +862,7 @@
>>           DeferredAttrContext deferredAttrContext;
>>
>>           protected DeferredTypeMap(AttrMode mode, Symbol msym, 
>> MethodResolutionPhase phase) {
>> -            super(String.format("deferredTypeMap[%s]", mode));
>> +            super(mode.getDescriptiveName());
>>               this.deferredAttrContext = new 
>> DeferredAttrContext(mode, msym, phase,
>>                       infer.emptyContext, emptyDeferredAttrContext, 
>> types.noWarnings);
>>           }
>


From joel.franck at oracle.com  Fri Dec 19 14:52:49 2014
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 19 Dec 2014 15:52:49 +0100
Subject: RFR: 8061472 String.format in DeferredAttr.DeferredTypeMap
	constructor leads to excessive object creation
In-Reply-To: <54935075.1070301@oracle.com>
References: <0DE212AE-027B-4CE5-83B8-B36A0CA27E75@oracle.com>
	<4719CE01-9A31-4979-A6B5-062183B3B042@oracle.com>
	<54932502.601@oracle.com> <54935075.1070301@oracle.com>
Message-ID: <5E1EE1CD-2DE3-4AF0-90AF-15869C01573A@oracle.com>

Hi Maurizio,

> On 18 dec 2014, at 23:08, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> The fix looks ok - but it feels a bit odd for the AttrMode (which is a general enum) to be returning the name including the 'deferredTypeMap' string - as that's another class. Maybe a static 'EnumMap<AttrMode, String>' inside the DeferredAttrMap class would more encapsulated?
> 

You are right, new patch inline.

cheers
/Joel

diff -r 47926c290355 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Wed Dec 17 12:48:04 2014 -0800
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Fri Dec 19 12:11:56 2014 +0100
@@ -41,6 +41,7 @@

 import java.util.ArrayList;
 import java.util.Collections;
+import java.util.EnumMap;
 import java.util.EnumSet;
 import java.util.LinkedHashMap;
 import java.util.LinkedHashSet;
@@ -838,6 +839,14 @@
     /** an empty deferred attribution context - all methods throw exceptions */
     final DeferredAttrContext emptyDeferredAttrContext;

+    /** The AttrMode to descriptive name mapping */
+    private static final EnumMap<AttrMode, String> deferredTypeMapDescriptions;
+    static {
+        deferredTypeMapDescriptions = new EnumMap<>(AttrMode.class);
+        deferredTypeMapDescriptions.put(AttrMode.CHECK, "deferredTypeMap[CHECK]");
+        deferredTypeMapDescriptions.put(AttrMode.SPECULATIVE, "deferredTypeMap[SPECULATIVE]");
+    }
+
     /**
      * Map a list of types possibly containing one or more deferred types
      * into a list of ordinary types. Each deferred type D is mapped into a type T,
@@ -845,11 +854,10 @@
      * computed for D during a previous deferred attribution round of the given kind.
      */
     class DeferredTypeMap extends Type.Mapping {
-
         DeferredAttrContext deferredAttrContext;

         protected DeferredTypeMap(AttrMode mode, Symbol msym, MethodResolutionPhase phase) {
-            super(String.format("deferredTypeMap[%s]", mode));
+            super(deferredTypeMapDescriptions.get(mode));
             this.deferredAttrContext = new DeferredAttrContext(mode, msym, phase,
                     infer.emptyContext, emptyDeferredAttrContext, types.noWarnings);
         }

From maurizio.cimadamore at oracle.com  Fri Dec 19 16:10:40 2014
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 19 Dec 2014 16:10:40 +0000
Subject: RFR: 8061472 String.format in DeferredAttr.DeferredTypeMap
	constructor leads to excessive object creation
In-Reply-To: <5E1EE1CD-2DE3-4AF0-90AF-15869C01573A@oracle.com>
References: <0DE212AE-027B-4CE5-83B8-B36A0CA27E75@oracle.com>
	<4719CE01-9A31-4979-A6B5-062183B3B042@oracle.com>
	<54932502.601@oracle.com> <54935075.1070301@oracle.com>
	<5E1EE1CD-2DE3-4AF0-90AF-15869C01573A@oracle.com>
Message-ID: <54944E00.2070204@oracle.com>

Looks good to me!

Thanks
Maurizio

On 19/12/14 14:52, Joel Borggr?n-Franck wrote:
> Hi Maurizio,
>
>> On 18 dec 2014, at 23:08, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> The fix looks ok - but it feels a bit odd for the AttrMode (which is a general enum) to be returning the name including the 'deferredTypeMap' string - as that's another class. Maybe a static 'EnumMap<AttrMode, String>' inside the DeferredAttrMap class would more encapsulated?
>>
> You are right, new patch inline.
>
> cheers
> /Joel
>
> diff -r 47926c290355 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Wed Dec 17 12:48:04 2014 -0800
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java	Fri Dec 19 12:11:56 2014 +0100
> @@ -41,6 +41,7 @@
>
>   import java.util.ArrayList;
>   import java.util.Collections;
> +import java.util.EnumMap;
>   import java.util.EnumSet;
>   import java.util.LinkedHashMap;
>   import java.util.LinkedHashSet;
> @@ -838,6 +839,14 @@
>       /** an empty deferred attribution context - all methods throw exceptions */
>       final DeferredAttrContext emptyDeferredAttrContext;
>
> +    /** The AttrMode to descriptive name mapping */
> +    private static final EnumMap<AttrMode, String> deferredTypeMapDescriptions;
> +    static {
> +        deferredTypeMapDescriptions = new EnumMap<>(AttrMode.class);
> +        deferredTypeMapDescriptions.put(AttrMode.CHECK, "deferredTypeMap[CHECK]");
> +        deferredTypeMapDescriptions.put(AttrMode.SPECULATIVE, "deferredTypeMap[SPECULATIVE]");
> +    }
> +
>       /**
>        * Map a list of types possibly containing one or more deferred types
>        * into a list of ordinary types. Each deferred type D is mapped into a type T,
> @@ -845,11 +854,10 @@
>        * computed for D during a previous deferred attribution round of the given kind.
>        */
>       class DeferredTypeMap extends Type.Mapping {
> -
>           DeferredAttrContext deferredAttrContext;
>
>           protected DeferredTypeMap(AttrMode mode, Symbol msym, MethodResolutionPhase phase) {
> -            super(String.format("deferredTypeMap[%s]", mode));
> +            super(deferredTypeMapDescriptions.get(mode));
>               this.deferredAttrContext = new DeferredAttrContext(mode, msym, phase,
>                       infer.emptyContext, emptyDeferredAttrContext, types.noWarnings);
>           }