From vicente.romero at oracle.com  Mon Feb  3 04:34:39 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 03 Feb 2014 12:34:39 +0000
Subject: inconsistent generic types behaviour when compiling together
	vs. separate
In-Reply-To: <52E9175A.1090306@gmail.com>
References: <52E9175A.1090306@gmail.com>
Message-ID: <52EF8CDF.8030700@oracle.com>

Hi Peter,

Thanks for the report. I have created: 
https://bugs.openjdk.java.net/browse/JDK-8033437 to track this issue.

Vicente

On 29/01/14 14:59, Peter Levart wrote:
> Here's an example:
>
> Create an empty directory and copy into it the following two sources:
>
> Ref.java:
>
>     public class Ref<T> {
>         final RefQueue<? super T> queue = new RefQueue<>();
>
>         public static void main(String[] args) {
>             Ref<Object> r = new Ref<>();
>             RefQueue<Object> q = r.queue;
>         }
>     }
>
> RefQueue.java:
>
>     public class RefQueue<T> {
>     }
>
> Then execute:
>
>     mkdir out
>     javac -d out Ref.java
>
> This compiles fine and produces two class files in out directory:
>
>     Ref.class
>     RefQueue.class
>
> Now do the following:
>
>     rm RefQueue.java
>     mkdir out2
>     javac -cp out -d out2 Ref.java
>
> Which produces compile-time error:
>
> Ref.java:6: error: incompatible types: RefQueue<CAP#1> cannot be 
> converted to RefQueue<Object>
>         RefQueue<Object> q = r.queue;
>                               ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: Object from capture of ? super Object
> 1 error
>
>
> It seems that the behaviour is inconsistent. There's also a question 
> whether the compile-time error is a correct behaviour or not. I tried 
> this with JDK 7u51, JDK 8 ea-b121 and recent JDK 9 from dev forest. 
> They all behave the same.
>
>
> Regards, Peter
>


From joe.darcy at oracle.com  Wed Feb  5 12:20:01 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 05 Feb 2014 12:20:01 -0800
Subject: Draft JEP: Elide deprecation warnings on import statements
Message-ID: <52F29CF1.3090602@oracle.com>

Hello,

Below is the text of a draft JEP we are considering submitting for JDK 9.

Cheers,

-Joe


Summary
-------

As of Java SE 8, java compilers are required by reasonable
interpretations of the Java Language Specification to issue
deprecation warnings when a deprecated type is imported by name or
when a deprecated member (method, field, nested type) is imported
statically. These warnings are uninformative and should not be
required. Deprecation warnings at actual uses of deprecated members
should remain.

Goals
-----

The goal of this JEP is to facilitate making large code bases clean of
lint warnings. The deprecation warnings on imports cannot be
suppressed using the @SuppressWarnings annotation, unlike uses of
deprecated members in code. In large code bases like that of the JDK,
deprecated functionality must often be supported for some time and
merely importing a deprecated construct does not justify a warning
message if all the uses of the deprecated construct are intentional
and suppressed.

Non-Goals
---------

It is not a goal of this JEP to actually resolve all the deprecation
warnings in the JDK code case. However, that might occur as part of a
separate maintenance effort in JDK 9.

Description
-----------

 From a specification perspective, the needed change is small. In JLS 7
(text in JLS 8 will be similar), the section on @Deprecated states:

"A Java compiler must produce a deprecation warning when a type,
method, field, or constructor whose declaration is annotated with the
annotation @Deprecated is used (i.e. overridden, invoked, or
referenced by name), unless:

     * The use is within an entity that is itself annotated with the
       annotation @Deprecated; or

     * The use is within an entity that is annotated to suppress the
       warning with the annotation @SuppressWarnings("deprecation"); or

     * The use and declaration are both within the same outermost class."

The specification change would be something like adding another bullet
stating the additional exclusion:

     * The use is within an import statement.

In the javac reference implementation, there would be a simple check
to skip over import statements when looking for deprecation warnings.

Testing
-------

Normal unit tests should suffice to test this feature. A handful of
JCK tests may need to be updated for the changed specification.

Impact
------

   - Other JDK components: The change would ease getting and keeping
      the JDK code base free of deprecations warnings.
   - Compatibility: Since warning will be issued in fewer cases, there 
is negligible compatibility impact.
   - User experience: Fewer uninformative warnings will be issued by the 
compiler.
   - TCK: As noted earlier, a handful of JCK test may need updating.


From scolebourne at joda.org  Wed Feb  5 14:50:16 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 5 Feb 2014 22:50:16 +0000
Subject: Draft JEP: Elide deprecation warnings on import statements
In-Reply-To: <52F29CF1.3090602@oracle.com>
References: <52F29CF1.3090602@oracle.com>
Message-ID: <CACzrW9AvwS65LVEcROFqb2oE4HK1KhbuRpSrN3BAC5R3myS5OA@mail.gmail.com>

This happens in pretty much all large codebases over time and would be
a welcome change IMO.
Stephen

On 5 February 2014 20:20, Joe Darcy <joe.darcy at oracle.com> wrote:
> Hello,
>
> Below is the text of a draft JEP we are considering submitting for JDK 9.
>
> Cheers,
>
> -Joe
>
>
> Summary
> -------
>
> As of Java SE 8, java compilers are required by reasonable
> interpretations of the Java Language Specification to issue
> deprecation warnings when a deprecated type is imported by name or
> when a deprecated member (method, field, nested type) is imported
> statically. These warnings are uninformative and should not be
> required. Deprecation warnings at actual uses of deprecated members
> should remain.
>
> Goals
> -----
>
> The goal of this JEP is to facilitate making large code bases clean of
> lint warnings. The deprecation warnings on imports cannot be
> suppressed using the @SuppressWarnings annotation, unlike uses of
> deprecated members in code. In large code bases like that of the JDK,
> deprecated functionality must often be supported for some time and
> merely importing a deprecated construct does not justify a warning
> message if all the uses of the deprecated construct are intentional
> and suppressed.
>
> Non-Goals
> ---------
>
> It is not a goal of this JEP to actually resolve all the deprecation
> warnings in the JDK code case. However, that might occur as part of a
> separate maintenance effort in JDK 9.
>
> Description
> -----------
>
> From a specification perspective, the needed change is small. In JLS 7
> (text in JLS 8 will be similar), the section on @Deprecated states:
>
> "A Java compiler must produce a deprecation warning when a type,
> method, field, or constructor whose declaration is annotated with the
> annotation @Deprecated is used (i.e. overridden, invoked, or
> referenced by name), unless:
>
>     * The use is within an entity that is itself annotated with the
>       annotation @Deprecated; or
>
>     * The use is within an entity that is annotated to suppress the
>       warning with the annotation @SuppressWarnings("deprecation"); or
>
>     * The use and declaration are both within the same outermost class."
>
> The specification change would be something like adding another bullet
> stating the additional exclusion:
>
>     * The use is within an import statement.
>
> In the javac reference implementation, there would be a simple check
> to skip over import statements when looking for deprecation warnings.
>
> Testing
> -------
>
> Normal unit tests should suffice to test this feature. A handful of
> JCK tests may need to be updated for the changed specification.
>
> Impact
> ------
>
>   - Other JDK components: The change would ease getting and keeping
>      the JDK code base free of deprecations warnings.
>   - Compatibility: Since warning will be issued in fewer cases, there is
> negligible compatibility impact.
>   - User experience: Fewer uninformative warnings will be issued by the
> compiler.
>   - TCK: As noted earlier, a handful of JCK test may need updating.
>

From jeremymanson at google.com  Wed Feb  5 22:26:56 2014
From: jeremymanson at google.com (Jeremy Manson)
Date: Wed, 5 Feb 2014 22:26:56 -0800
Subject: Draft JEP: Elide deprecation warnings on import statements
In-Reply-To: <CACzrW9AvwS65LVEcROFqb2oE4HK1KhbuRpSrN3BAC5R3myS5OA@mail.gmail.com>
References: <52F29CF1.3090602@oracle.com>
	<CACzrW9AvwS65LVEcROFqb2oE4HK1KhbuRpSrN3BAC5R3myS5OA@mail.gmail.com>
Message-ID: <CAPYFHW1j3F5bQqP-kSzGHXgZonVxp16PW6FFp768uC42Q+deqQ@mail.gmail.com>

Agree with Stephen.  At Google, we've recently made the decision to stop
issuing warnings about these in our internal builds.

Jeremy


On Wed, Feb 5, 2014 at 2:50 PM, Stephen Colebourne <scolebourne at joda.org>wrote:

> This happens in pretty much all large codebases over time and would be
> a welcome change IMO.
> Stephen
>
> On 5 February 2014 20:20, Joe Darcy <joe.darcy at oracle.com> wrote:
> > Hello,
> >
> > Below is the text of a draft JEP we are considering submitting for JDK 9.
> >
> > Cheers,
> >
> > -Joe
> >
> >
> > Summary
> > -------
> >
> > As of Java SE 8, java compilers are required by reasonable
> > interpretations of the Java Language Specification to issue
> > deprecation warnings when a deprecated type is imported by name or
> > when a deprecated member (method, field, nested type) is imported
> > statically. These warnings are uninformative and should not be
> > required. Deprecation warnings at actual uses of deprecated members
> > should remain.
> >
> > Goals
> > -----
> >
> > The goal of this JEP is to facilitate making large code bases clean of
> > lint warnings. The deprecation warnings on imports cannot be
> > suppressed using the @SuppressWarnings annotation, unlike uses of
> > deprecated members in code. In large code bases like that of the JDK,
> > deprecated functionality must often be supported for some time and
> > merely importing a deprecated construct does not justify a warning
> > message if all the uses of the deprecated construct are intentional
> > and suppressed.
> >
> > Non-Goals
> > ---------
> >
> > It is not a goal of this JEP to actually resolve all the deprecation
> > warnings in the JDK code case. However, that might occur as part of a
> > separate maintenance effort in JDK 9.
> >
> > Description
> > -----------
> >
> > From a specification perspective, the needed change is small. In JLS 7
> > (text in JLS 8 will be similar), the section on @Deprecated states:
> >
> > "A Java compiler must produce a deprecation warning when a type,
> > method, field, or constructor whose declaration is annotated with the
> > annotation @Deprecated is used (i.e. overridden, invoked, or
> > referenced by name), unless:
> >
> >     * The use is within an entity that is itself annotated with the
> >       annotation @Deprecated; or
> >
> >     * The use is within an entity that is annotated to suppress the
> >       warning with the annotation @SuppressWarnings("deprecation"); or
> >
> >     * The use and declaration are both within the same outermost class."
> >
> > The specification change would be something like adding another bullet
> > stating the additional exclusion:
> >
> >     * The use is within an import statement.
> >
> > In the javac reference implementation, there would be a simple check
> > to skip over import statements when looking for deprecation warnings.
> >
> > Testing
> > -------
> >
> > Normal unit tests should suffice to test this feature. A handful of
> > JCK tests may need to be updated for the changed specification.
> >
> > Impact
> > ------
> >
> >   - Other JDK components: The change would ease getting and keeping
> >      the JDK code base free of deprecations warnings.
> >   - Compatibility: Since warning will be issued in fewer cases, there is
> > negligible compatibility impact.
> >   - User experience: Fewer uninformative warnings will be issued by the
> > compiler.
> >   - TCK: As noted earlier, a handful of JCK test may need updating.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140205/d0910d2e/attachment.html 

From henry.jen at oracle.com  Thu Feb  6 10:34:09 2014
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Thu, 06 Feb 2014 18:34:09 +0000
Subject: hg: jdk8/tl/jdk: 8033590: java.util.Comparator::thenComparing has
	unnecessary type restriction
Message-ID: <20140206183432.A898562A7F@hg.openjdk.java.net>

Changeset: 7534523b4174
Author:    henryjen
Date:      2014-02-06 10:30 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7534523b4174

8033590: java.util.Comparator::thenComparing has unnecessary type restriction
Reviewed-by: psandoz

! src/share/classes/java/util/Comparator.java
! test/java/util/Comparator/TypeTest.java


From eric.mccorkle at oracle.com  Thu Feb  6 11:59:43 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 06 Feb 2014 14:59:43 -0500
Subject: Rethinking TypeAnnotation vs Annotation
Message-ID: <52F3E9AF.9050908@oracle.com>

In the process of working on the next roadmap step for type annotations,
I've realized something.

The current implementation, and I think most of everyone's thinking on
annotations treats type annotations as a special case of regular
annotations.  Indeed, this is sort of the intuitive first thought.

But looking at the actual implementation details, I think the reverse is
actually true.  Any given annotation is potentially a type annotation,
especially earlier in the javac pipeline (where I'm presently generating
TypeAnnotationPositions in my new patch).  So, on the implementation
front, it makes perfect sense to do things like store
TypeAnnotationPositions in Attribute.Compound, as opposed to
Attribute.TypeCompound.

I think this would also go a long way towards creating the single
codepath for attaching annotations that I want to create.

Comments?
-------------- 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/20140206/0a1f2c73/eric_mccorkle.vcf 

From alex.buckley at oracle.com  Thu Feb  6 12:15:03 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 12:15:03 -0800
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <52F3E9AF.9050908@oracle.com>
References: <52F3E9AF.9050908@oracle.com>
Message-ID: <52F3ED47.6020005@oracle.com>

Hi Eric,

"Any given annotation is potentially a type annotation" doesn't smell 
right to me. For example, an annotation on a package declaration cannot 
reasonably be considered as a "type annotation".

In fact, we can be real precise about this: there are eight declaration 
contexts defined in JLS 9.6.4.1, and only five of them are called out in 
9.7.4 as being a syntactic opportunity to annotate a type. The three 
that aren't - package declarations, type declarations, and type 
parameter declarations - are where you "cannot" have a type annotation, 
by definition.

It may be helpful to review 9.7.4:

- A declaration annotation is an annotation that applies to a 
declaration, and whose own type is applicable in the declaration context 
(?9.6.4.1) represented by that declaration.

- A type annotation is an annotation that applies to a type (or any part 
of a type), and whose own type is applicable in type contexts (?4.11).

- Whether an annotation applies to a declaration or to the type of the 
declared entity - and thus, whether the annotation is a declaration 
annotation or a type annotation - depends on the applicability of the 
annotation's type: ...

Alex

On 2/6/2014 11:59 AM, Eric McCorkle wrote:
> In the process of working on the next roadmap step for type annotations,
> I've realized something.
>
> The current implementation, and I think most of everyone's thinking on
> annotations treats type annotations as a special case of regular
> annotations.  Indeed, this is sort of the intuitive first thought.
>
> But looking at the actual implementation details, I think the reverse is
> actually true.  Any given annotation is potentially a type annotation,
> especially earlier in the javac pipeline (where I'm presently generating
> TypeAnnotationPositions in my new patch).  So, on the implementation
> front, it makes perfect sense to do things like store
> TypeAnnotationPositions in Attribute.Compound, as opposed to
> Attribute.TypeCompound.
>
> I think this would also go a long way towards creating the single
> codepath for attaching annotations that I want to create.
>
> Comments?
>

From joel.franck at oracle.com  Thu Feb  6 13:26:10 2014
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 6 Feb 2014 22:26:10 +0100
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <52F3E9AF.9050908@oracle.com>
References: <52F3E9AF.9050908@oracle.com>
Message-ID: <8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>

Hi Eric,

On 06 Feb 2014, at 20:59, Eric McCorkle <eric.mccorkle at oracle.com> wrote:

> In the process of working on the next roadmap step for type annotations,
> I've realized something.
> 
> The current implementation, and I think most of everyone's thinking on
> annotations treats type annotations as a special case of regular
> annotations.  Indeed, this is sort of the intuitive first thought.
> 
> But looking at the actual implementation details, I think the reverse is
> actually true.  Any given annotation is potentially a type annotation,
> especially earlier in the javac pipeline (where I'm presently generating
> TypeAnnotationPositions in my new patch).  So, on the implementation
> front, it makes perfect sense to do things like store
> TypeAnnotationPositions in Attribute.Compound, as opposed to
> Attribute.TypeCompound.
> 
> I think this would also go a long way towards creating the single
> codepath for attaching annotations that I want to create.
> 
> Comments?

I have never been a big fan of the TypeCompound class at all. Also reading some more in 9.7.4 it looks like annotation can be both a type anno and a declaration anno. So, from my perspective, dumping TypeCompound and moving its data up to Compound seems like something to try out.

cheers
/Joel

From wdietl at gmail.com  Thu Feb  6 13:48:41 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Thu, 6 Feb 2014 16:48:41 -0500
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>
References: <52F3E9AF.9050908@oracle.com>
	<8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>
Message-ID: <CAJYRO=5WmMuLdhd=38L8kip=ZiGpa75ey6Nzqdtoz1_iszB2jg@mail.gmail.com>

Hi all,

an alternative would be to keep Compound only while it is unclear
whether an annotation is a type or declaration annotation and
introduce a new DeclarationCompound class that can be used when only
declaration annotations are expected.
Why not have the type system help us keep things straight?

cu, WMD.




On Thu, Feb 6, 2014 at 4:26 PM, Joel Borggr?n-Franck
<joel.franck at oracle.com> wrote:
> Hi Eric,
>
> On 06 Feb 2014, at 20:59, Eric McCorkle <eric.mccorkle at oracle.com> wrote:
>
>> In the process of working on the next roadmap step for type annotations,
>> I've realized something.
>>
>> The current implementation, and I think most of everyone's thinking on
>> annotations treats type annotations as a special case of regular
>> annotations.  Indeed, this is sort of the intuitive first thought.
>>
>> But looking at the actual implementation details, I think the reverse is
>> actually true.  Any given annotation is potentially a type annotation,
>> especially earlier in the javac pipeline (where I'm presently generating
>> TypeAnnotationPositions in my new patch).  So, on the implementation
>> front, it makes perfect sense to do things like store
>> TypeAnnotationPositions in Attribute.Compound, as opposed to
>> Attribute.TypeCompound.
>>
>> I think this would also go a long way towards creating the single
>> codepath for attaching annotations that I want to create.
>>
>> Comments?
>
> I have never been a big fan of the TypeCompound class at all. Also reading some more in 9.7.4 it looks like annotation can be both a type anno and a declaration anno. So, from my perspective, dumping TypeCompound and moving its data up to Compound seems like something to try out.
>
> cheers
> /Joel



-- 
http://www.google.com/profiles/wdietl

From jonathan.gibbons at oracle.com  Thu Feb  6 14:00:00 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 06 Feb 2014 14:00:00 -0800
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <CAJYRO=5WmMuLdhd=38L8kip=ZiGpa75ey6Nzqdtoz1_iszB2jg@mail.gmail.com>
References: <52F3E9AF.9050908@oracle.com>	<8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>
	<CAJYRO=5WmMuLdhd=38L8kip=ZiGpa75ey6Nzqdtoz1_iszB2jg@mail.gmail.com>
Message-ID: <52F405E0.3030603@oracle.com>

Right now, Compound is used for two things, it is the representation of 
an annotation as an arg value of an enclosing annotation and it is used 
for "top level" annotation values.  I suspect it is time to split those 
uses.

-- Jon

On 02/06/2014 01:48 PM, Werner Dietl wrote:
> Hi all,
>
> an alternative would be to keep Compound only while it is unclear
> whether an annotation is a type or declaration annotation and
> introduce a new DeclarationCompound class that can be used when only
> declaration annotations are expected.
> Why not have the type system help us keep things straight?
>
> cu, WMD.


From eric.mccorkle at oracle.com  Thu Feb  6 16:11:54 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 06 Feb 2014 19:11:54 -0500
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <52F3ED47.6020005@oracle.com>
References: <52F3E9AF.9050908@oracle.com> <52F3ED47.6020005@oracle.com>
Message-ID: <52F424CA.6090308@oracle.com>

Alex,

I am talking in terms of javac compiler internals, not the JLS spec.  To
be clear, I'm proposing changes to the way we model data inside javac,
not any changes to the JLS.

At many stages in the pipeline, the applicability of an annotation is
not yet known.  So the annotation might potentially need a
TypeAnnotationPosition, because there is the potential that further down
the pipeline it will be discovered that it is actually a type annotation.

On 02/06/14 15:15, Alex Buckley wrote:
> Hi Eric,
> 
> "Any given annotation is potentially a type annotation" doesn't smell
> right to me. For example, an annotation on a package declaration cannot
> reasonably be considered as a "type annotation".
> 
> In fact, we can be real precise about this: there are eight declaration
> contexts defined in JLS 9.6.4.1, and only five of them are called out in
> 9.7.4 as being a syntactic opportunity to annotate a type. The three
> that aren't - package declarations, type declarations, and type
> parameter declarations - are where you "cannot" have a type annotation,
> by definition.
> 
> It may be helpful to review 9.7.4:
> 
> - A declaration annotation is an annotation that applies to a
> declaration, and whose own type is applicable in the declaration context
> (?9.6.4.1) represented by that declaration.
> 
> - A type annotation is an annotation that applies to a type (or any part
> of a type), and whose own type is applicable in type contexts (?4.11).
> 
> - Whether an annotation applies to a declaration or to the type of the
> declared entity - and thus, whether the annotation is a declaration
> annotation or a type annotation - depends on the applicability of the
> annotation's type: ...
> 
> Alex
> 
> On 2/6/2014 11:59 AM, Eric McCorkle wrote:
>> In the process of working on the next roadmap step for type annotations,
>> I've realized something.
>>
>> The current implementation, and I think most of everyone's thinking on
>> annotations treats type annotations as a special case of regular
>> annotations.  Indeed, this is sort of the intuitive first thought.
>>
>> But looking at the actual implementation details, I think the reverse is
>> actually true.  Any given annotation is potentially a type annotation,
>> especially earlier in the javac pipeline (where I'm presently generating
>> TypeAnnotationPositions in my new patch).  So, on the implementation
>> front, it makes perfect sense to do things like store
>> TypeAnnotationPositions in Attribute.Compound, as opposed to
>> Attribute.TypeCompound.
>>
>> I think this would also go a long way towards creating the single
>> codepath for attaching annotations that I want to create.
>>
>> Comments?
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140206/07dc4746/eric_mccorkle.vcf 

From eric.mccorkle at oracle.com  Thu Feb  6 16:14:42 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 06 Feb 2014 19:14:42 -0500
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>
References: <52F3E9AF.9050908@oracle.com>
	<8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>
Message-ID: <52F42572.5080602@oracle.com>

On 02/06/14 16:26, Joel Borggr?n-Franck wrote:

> I have never been a big fan of the TypeCompound class at all. Also reading some more in 9.7.4 it looks like annotation can be both a type anno and a declaration anno. So, from my perspective, dumping TypeCompound and moving its data up to Compound seems like something to try out.
> 

I had not thought of dumping TypeCompound, but it sounds like a good
idea.  It would certainly eliminate a lot of code path duplication.  I
would like to do that maybe one patch from now, though.  Figuring out
TypeAnnotationPositions in MemberEnter is enough for one patch.
-------------- 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/20140206/3fea00ba/eric_mccorkle.vcf 

From eric.mccorkle at oracle.com  Thu Feb  6 16:16:17 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 06 Feb 2014 19:16:17 -0500
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <52F405E0.3030603@oracle.com>
References: <52F3E9AF.9050908@oracle.com>	<8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>	<CAJYRO=5WmMuLdhd=38L8kip=ZiGpa75ey6Nzqdtoz1_iszB2jg@mail.gmail.com>
	<52F405E0.3030603@oracle.com>
Message-ID: <52F425D1.8030405@oracle.com>

Could this be done as part of the more general annotations work?

I'm liking Joel's idea of dropping TypeCompound altogether.  Maybe that
merge should be done now, and we can do the split later?  I think it
would be a lot easier once the type annotations work is done.

On 02/06/14 17:00, Jonathan Gibbons wrote:
> Right now, Compound is used for two things, it is the representation of
> an annotation as an arg value of an enclosing annotation and it is used
> for "top level" annotation values.  I suspect it is time to split those
> uses.
> 
> -- Jon
> 
> On 02/06/2014 01:48 PM, Werner Dietl wrote:
>> Hi all,
>>
>> an alternative would be to keep Compound only while it is unclear
>> whether an annotation is a type or declaration annotation and
>> introduce a new DeclarationCompound class that can be used when only
>> declaration annotations are expected.
>> Why not have the type system help us keep things straight?
>>
>> cu, WMD.
> 
-------------- 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/20140206/6de8759a/eric_mccorkle.vcf 

From jonathan.gibbons at oracle.com  Thu Feb  6 16:28:43 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 06 Feb 2014 16:28:43 -0800
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <52F425D1.8030405@oracle.com>
References: <52F3E9AF.9050908@oracle.com>	<8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>	<CAJYRO=5WmMuLdhd=38L8kip=ZiGpa75ey6Nzqdtoz1_iszB2jg@mail.gmail.com>	<52F405E0.3030603@oracle.com>
	<52F425D1.8030405@oracle.com>
Message-ID: <52F428BB.3030809@oracle.com>

I am OK with seeing this idea explored at some point in the anno cleanup 
pipeline.

My expectation is that if you merge TypeCompound and Compound, then we 
will start getting a better feeling of the overall usages of the class, 
and can refactor appropriately.

-- Jon

On 02/06/2014 04:16 PM, Eric McCorkle wrote:
> Could this be done as part of the more general annotations work?
>
> I'm liking Joel's idea of dropping TypeCompound altogether.  Maybe that
> merge should be done now, and we can do the split later?  I think it
> would be a lot easier once the type annotations work is done.
>
> On 02/06/14 17:00, Jonathan Gibbons wrote:
>> Right now, Compound is used for two things, it is the representation of
>> an annotation as an arg value of an enclosing annotation and it is used
>> for "top level" annotation values.  I suspect it is time to split those
>> uses.
>>
>> -- Jon
>>
>> On 02/06/2014 01:48 PM, Werner Dietl wrote:
>>> Hi all,
>>>
>>> an alternative would be to keep Compound only while it is unclear
>>> whether an annotation is a type or declaration annotation and
>>> introduce a new DeclarationCompound class that can be used when only
>>> declaration annotations are expected.
>>> Why not have the type system help us keep things straight?
>>>
>>> cu, WMD.


From alex.buckley at oracle.com  Thu Feb  6 18:36:34 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 06 Feb 2014 18:36:34 -0800
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <52F424CA.6090308@oracle.com>
References: <52F3E9AF.9050908@oracle.com> <52F3ED47.6020005@oracle.com>
	<52F424CA.6090308@oracle.com>
Message-ID: <52F446B2.3080505@oracle.com>

My point was that the javac data model ought to use JLS concepts as a 
starting point, if appropriate and practical.

Alex

On 2/6/2014 4:11 PM, Eric McCorkle wrote:
> Alex,
>
> I am talking in terms of javac compiler internals, not the JLS spec.  To
> be clear, I'm proposing changes to the way we model data inside javac,
> not any changes to the JLS.
>
> At many stages in the pipeline, the applicability of an annotation is
> not yet known.  So the annotation might potentially need a
> TypeAnnotationPosition, because there is the potential that further down
> the pipeline it will be discovered that it is actually a type annotation.
>
> On 02/06/14 15:15, Alex Buckley wrote:
>> Hi Eric,
>>
>> "Any given annotation is potentially a type annotation" doesn't smell
>> right to me. For example, an annotation on a package declaration cannot
>> reasonably be considered as a "type annotation".
>>
>> In fact, we can be real precise about this: there are eight declaration
>> contexts defined in JLS 9.6.4.1, and only five of them are called out in
>> 9.7.4 as being a syntactic opportunity to annotate a type. The three
>> that aren't - package declarations, type declarations, and type
>> parameter declarations - are where you "cannot" have a type annotation,
>> by definition.
>>
>> It may be helpful to review 9.7.4:
>>
>> - A declaration annotation is an annotation that applies to a
>> declaration, and whose own type is applicable in the declaration context
>> (?9.6.4.1) represented by that declaration.
>>
>> - A type annotation is an annotation that applies to a type (or any part
>> of a type), and whose own type is applicable in type contexts (?4.11).
>>
>> - Whether an annotation applies to a declaration or to the type of the
>> declared entity - and thus, whether the annotation is a declaration
>> annotation or a type annotation - depends on the applicability of the
>> annotation's type: ...
>>
>> Alex
>>
>> On 2/6/2014 11:59 AM, Eric McCorkle wrote:
>>> In the process of working on the next roadmap step for type annotations,
>>> I've realized something.
>>>
>>> The current implementation, and I think most of everyone's thinking on
>>> annotations treats type annotations as a special case of regular
>>> annotations.  Indeed, this is sort of the intuitive first thought.
>>>
>>> But looking at the actual implementation details, I think the reverse is
>>> actually true.  Any given annotation is potentially a type annotation,
>>> especially earlier in the javac pipeline (where I'm presently generating
>>> TypeAnnotationPositions in my new patch).  So, on the implementation
>>> front, it makes perfect sense to do things like store
>>> TypeAnnotationPositions in Attribute.Compound, as opposed to
>>> Attribute.TypeCompound.
>>>
>>> I think this would also go a long way towards creating the single
>>> codepath for attaching annotations that I want to create.
>>>
>>> Comments?
>>>

From dl at cs.oswego.edu  Fri Feb  7 10:38:39 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 07 Feb 2014 13:38:39 -0500
Subject: Draft JEP on enhanced volatiles
Message-ID: <52F5282F.1010808@cs.oswego.edu>


[To core-libs-dev; separately cross-posted to hotspot-dev and compiler-dev.]

Now that the JMM update project is live
(see http://openjdk.java.net/projects/jmm/),
it would be helpful to get some preliminary feedback on
one of its sure-to-be-needed counterparts: finally supporting
a reasonable way to express atomic and/or ordered access
operations beyond volatile-read/write. Some of you might
know that the lack of these has often been discusses as a
source of frustration and problems. One reason for nopt
dealing with it sooner is the lack of a basis for even
specifying such things, to be fixed with JMM update.
But we also need some way for people to express them. The only
good means for doing so appear to require a small amount of syntax
support. Most people who have seen it seem to agree that the
".volatile" proposal below is the approach most likely to
succeed. (We've considered a lot of others.) I'm hoping that
members of libs, hotspot, and compiler groups can give it a
sanity check before submitting (hopefully in a week or so).
Thanks!

Draft JEP proposal
Title: Enhanced Volatiles
Author: Doug Lea
[...other metadata elided for now...]


Summary
-------

This JEP results in a means for programmers to invoke the equivalents
of java.util.concurrent.atomic methods on volatile fields.

Motivation
----------

As concurrent and parallel programming in Java continue to expand,
programmers are increasingly frustrated by not being able to use Java
constructions for arranging atomic operations for the fields of
individual classes; for example atomically incrementing a "count"
field. Until now the only ways to achieve these effects were to use a
stand-alone AtomicInteger (adding both space overhead and additional
concurrency issues to manage indirection) or, in some situations, to
use atomic FieldUpdates (often encountering more overhead than the
operation itself), or to use JVM Unsafe intrinsics. Because intrinsics
are preferable on performance grounds, their use has been increasingly
common, to the detriment of safety and portability. Without this JEP,
these problems are expected to become worse as atomic APIs expand to
cover additional access consistency policies (aligned with the recent
C++11 memory model) as part of Java Memory Model revisions.

Description
-----------

The target solution requires a syntax enhancement, a few
library enhancements, and compiler support.

We model the extended operations on volatile integers via an interface
VolatileInt, that also captures the functionality of AtomicInteger
(which will also be updated to reflect Java Memory Model revisions as
part of this JEP). A tentative version is below. Similar interfaces
are needed for other primitive and reference types.

We then enable access to corresponding methods for (typically
volatile) fields using the ".volatile" prefix. For example:

     class Usage {
         volatile int count;
         int incrementCount() {
             return count.volatile.incrementAndGet();
         }
     }

The ".volatile" syntax is slightly unusual, but we are confident that
it is syntactically unambiguous and semantically specifiable.  New
syntax is required to avoid ambiguities with existing usages,
especially for volatile references -- invocations of methods on the
reference versus the referent would be indistinguishable.  The
".volatile" prefix introduces a scope for operations on these
"L-values", not their retrieved contents.  However, just using the
prefix itself without a method invocation (as in "count.volatile;")
would be meaningless and illegal.  We also expect to allow volatile
operations on array elements in addition to fields.

The main task is to translate these calls into corresponding JVM
intrinsics. The most likely option is for the source compiler to use
method handles. This and other techniques are known to suffice, but
are subject to further exploration. Minor enhancements to intrinsics
and a few additional JDK library methods may also be needed.

Here is a tentative VolatileInt interface.  Those for other types are
similar.  The final released versions will surely differ in small
ways.

     interface VolatileInt {
         int get();
         int getRelaxed();
         int getAcquire();
         int getSequential();

         void set(int x);
         void setRelaxed(int x);
         void setRelease(int x);
         void setSequential(int x);

         int getAndSet(int x);
         boolean compareAndSet(int e, int x);
         boolean compareAndSetAcquire(int e, int x);
         boolean compareAndSetRelease(int e, int x);
         boolean weakCompareAndSet(int e, int x);
         boolean weakCompareAndSetAcquire(int e, int x);
         boolean weakCompareAndSetRelease(int e, int x);

         int getAndAdd(int x);
         int addAndGet(int x);
         int getAndIncrement();
         int incrementAndGet();
         int getAndDecrement();
         int decrementAndGet();
     }


Alternatives
------------

We considered instead introducing new forms of "value type" that
support volatile operations. However, this would be inconsistent with
properties of other types, and would also require more effort for
programmers to use. We also considered expanding reliance on
java.util.concurrent.atomic FieldUpdaters, but their dynamic overhead
and usage limitations make them unsuitable. Several other alternatives
(including those based on field references) have been raised and
dismissed as unworkable on syntactic, efficiency, and/or usability
grounds over the many years that these issues has been discussed.


Risks and Assumptions
---------------------

We are confident of feasibility.  However, we expect that it will
require more experimentation to arrive at compilation techniques that
result in efficient enough implementation for routine use in the
performance-critical contexts where these constructs are most often
needed. The use of method handles may be impacted by and may impact
JVM method handle support.

Impact
------

A large number of usages in java.util.concurrent (and a few elsewhere
in JDK) could be simplified and updated to use this support.

From Sergey.Bylokhov at oracle.com  Fri Feb  7 13:28:12 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 08 Feb 2014 01:28:12 +0400
Subject: JLS string concatenation clarification
In-Reply-To: <52E81A5D.5090409@oracle.com>
References: <CAGB9EW9OnHjTFU9scLYteBgPAsZouVKSzJ7pq5+1v-qLq9Ea_Q@mail.gmail.com>	<CA+kOe08XHMR+Vk6zKdLVf1XkF9_-t40TtV3Y1bcuj2KE8XJM4w@mail.gmail.com>	<52DF14C0.1000601@oracle.com>	<52E042C2.6020708@oracle.com>	<52E6987C.5070104@oracle.com>
	<52E6B383.5090904@oracle.com> <52E81A5D.5090409@oracle.com>
Message-ID: <52F54FEC.9040203@oracle.com>

Hi, Vicente.
For a long time I ask a question related to the implementation of 
concatenations of the string in javac:
1 Why "" + expression is compiled to
         new StringBuilder()).append("").append(expression).toString()
         instead of String.valueOf(expression)? see JDK-4947460
2 Why expression1 + expression2 is compiled to
         new 
StringBuilder()).append(expression1).append(expression2).toString()
         instead of new 
StringBuilder(expression1)).append(expression2).toString()?  see JDK-4059189
3 Why JDK-6709423 is closed as not a defect, it could at least save a 
few bytes in the class files. Generated code currently is not perfect:
         s += a;
         s += b;
         is compiled to:
         s = new StringBuilder()).append(s).append(a).toString();
         s = new StringBuilder()).append(s).append(b).toString();
         instead of new StringBuilder(s).append(a).append(b).toString();

I suppose, these optimizations will not affect a JIT (will not make 
result worse) and will save the size of class file.

On 29.01.2014 1:00, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Alex,
>
> On 27/01/14 19:29, Alex Buckley wrote:
>> Hi Vicente,
>>
>> Generated code. Also, I realize that s+"" may generate different code 
>> than ""+s - please indicate if that's the case.
>
> Yes the generated code is slightly different. But at the end javac 
> only indicates what should be done. A string concatenation implies the 
> creation of a StringBuilder with calls to it's append() method. Later 
> the VM should these instructions only as indications.
>
> Vicente
>
>>
>> Alex
>>
>> On 1/27/2014 9:33 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>> Hi Alex,
>>>
>>> Are you interested in the generated code or in the compiler's internal
>>> representation?
>>>
>>> Thanks,
>>> Vicente
>>>
>>> On 22/01/14 22:14, Alex Buckley wrote:
>>>> To compiler-dev and others,
>>>>
>>>> Since the original question asked when the JLS allows compilers to
>>>> deviate from "always" creating a new String object, I would like to
>>>> know more about the following case:
>>>>
>>>> On 1/21/2014 4:45 PM, Alex Buckley wrote:
>>>>> - "Semi" constant expressions like s+"". Concatenating the empty 
>>>>> string
>>>>> literal "" with a String expression is mentioned in
>>>>> https://bugs.openjdk.java.net/browse/JDK-4036535. The expectation 
>>>>> (per
>>>>> JLS1) that a new String object is always created in this case is
>>>>> misplaced (per the JDK's actual behavior). But, the JLS never 
>>>>> clarified
>>>>> this.
>>>>
>>>> If compiler authors can confirm (on-list or privately) that indeed
>>>> "concatenation with empty string does not create the new instance of
>>>> String", then I will clarify the JLS.
>>>>
>>>> Alex
>>>
>


-- 
Best regards, Sergey.


From rob.mckenna at oracle.com  Mon Feb 10 06:50:15 2014
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Mon, 10 Feb 2014 14:50:15 +0000
Subject: hg: jdk8/tl/jdk: 7152892: some jtreg tests fail with permission denied
Message-ID: <20140210145247.DD74462B24@hg.openjdk.java.net>

Changeset: da4b0962ad11
Author:    robm
Date:      2014-02-10 14:35 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11

7152892: some jtreg tests fail with permission denied
Reviewed-by: coffeys

! test/java/lang/ClassLoader/Assert.sh
! test/java/rmi/registry/readTest/readTest.sh
! test/java/util/zip/ZipFile/ReadZip.java
! test/sun/net/www/protocol/jar/jarbug/run.sh


From joel.franck at oracle.com  Mon Feb 10 07:41:04 2014
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Mon, 10 Feb 2014 16:41:04 +0100
Subject: Rethinking TypeAnnotation vs Annotation
In-Reply-To: <CAJYRO=5WmMuLdhd=38L8kip=ZiGpa75ey6Nzqdtoz1_iszB2jg@mail.gmail.com>
References: <52F3E9AF.9050908@oracle.com>
	<8A00C6A4-EFAF-4B61-82E8-55EADA9AD2D7@oracle.com>
	<CAJYRO=5WmMuLdhd=38L8kip=ZiGpa75ey6Nzqdtoz1_iszB2jg@mail.gmail.com>
Message-ID: <B2C2CC3B-6BF4-4914-BD13-003F3ED775B4@oracle.com>

Hi,

On 06 Feb 2014, at 22:48, Werner Dietl <wdietl at gmail.com> wrote:

> Hi all,
> 
> an alternative would be to keep Compound only while it is unclear
> whether an annotation is a type or declaration annotation and
> introduce a new DeclarationCompound class that can be used when only
> declaration annotations are expected.
> Why not have the type system help us keep things straight?
> 

I?m not sure this will help us. After re-reading the spec I think a Compound (for lack of a better name) can be applicable to types, declarations, or both. That doesn?t seem like anything the type system will help us with today. Applicability to me seem more lika a ?has-a? thing than ?is-a?.  Instead we are doing manual code duplication (and I suspect duplication of bugs).

There might be a way the type system can help us further down, but I think that will be more clear after we do some refactoring and unification.

cheers
/Joel

From martijnverburg at gmail.com  Mon Feb 10 10:52:46 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 10 Feb 2014 18:52:46 +0000
Subject: Draft JEP: Elide deprecation warnings on import statements
In-Reply-To: <CAPYFHW1j3F5bQqP-kSzGHXgZonVxp16PW6FFp768uC42Q+deqQ@mail.gmail.com>
References: <52F29CF1.3090602@oracle.com>
	<CACzrW9AvwS65LVEcROFqb2oE4HK1KhbuRpSrN3BAC5R3myS5OA@mail.gmail.com>
	<CAPYFHW1j3F5bQqP-kSzGHXgZonVxp16PW6FFp768uC42Q+deqQ@mail.gmail.com>
Message-ID: <CAP7YuAS8+P_kO=EGawugb+=txcCxrH7YQa8cHjFQSCTXGA-77g@mail.gmail.com>

+1 - would be nice to eliminate false positives in large code bases (like
PCGen)

Cheers,
Martijn


On 6 February 2014 06:26, Jeremy Manson <jeremymanson at google.com> wrote:

> Agree with Stephen.  At Google, we've recently made the decision to stop
> issuing warnings about these in our internal builds.
>
> Jeremy
>
>
> On Wed, Feb 5, 2014 at 2:50 PM, Stephen Colebourne <scolebourne at joda.org>wrote:
>
>> This happens in pretty much all large codebases over time and would be
>> a welcome change IMO.
>> Stephen
>>
>> On 5 February 2014 20:20, Joe Darcy <joe.darcy at oracle.com> wrote:
>> > Hello,
>> >
>> > Below is the text of a draft JEP we are considering submitting for JDK
>> 9.
>> >
>> > Cheers,
>> >
>> > -Joe
>> >
>> >
>> > Summary
>> > -------
>> >
>> > As of Java SE 8, java compilers are required by reasonable
>> > interpretations of the Java Language Specification to issue
>> > deprecation warnings when a deprecated type is imported by name or
>> > when a deprecated member (method, field, nested type) is imported
>> > statically. These warnings are uninformative and should not be
>> > required. Deprecation warnings at actual uses of deprecated members
>> > should remain.
>> >
>> > Goals
>> > -----
>> >
>> > The goal of this JEP is to facilitate making large code bases clean of
>> > lint warnings. The deprecation warnings on imports cannot be
>> > suppressed using the @SuppressWarnings annotation, unlike uses of
>> > deprecated members in code. In large code bases like that of the JDK,
>> > deprecated functionality must often be supported for some time and
>> > merely importing a deprecated construct does not justify a warning
>> > message if all the uses of the deprecated construct are intentional
>> > and suppressed.
>> >
>> > Non-Goals
>> > ---------
>> >
>> > It is not a goal of this JEP to actually resolve all the deprecation
>> > warnings in the JDK code case. However, that might occur as part of a
>> > separate maintenance effort in JDK 9.
>> >
>> > Description
>> > -----------
>> >
>> > From a specification perspective, the needed change is small. In JLS 7
>> > (text in JLS 8 will be similar), the section on @Deprecated states:
>> >
>> > "A Java compiler must produce a deprecation warning when a type,
>> > method, field, or constructor whose declaration is annotated with the
>> > annotation @Deprecated is used (i.e. overridden, invoked, or
>> > referenced by name), unless:
>> >
>> >     * The use is within an entity that is itself annotated with the
>> >       annotation @Deprecated; or
>> >
>> >     * The use is within an entity that is annotated to suppress the
>> >       warning with the annotation @SuppressWarnings("deprecation"); or
>> >
>> >     * The use and declaration are both within the same outermost class."
>> >
>> > The specification change would be something like adding another bullet
>> > stating the additional exclusion:
>> >
>> >     * The use is within an import statement.
>> >
>> > In the javac reference implementation, there would be a simple check
>> > to skip over import statements when looking for deprecation warnings.
>> >
>> > Testing
>> > -------
>> >
>> > Normal unit tests should suffice to test this feature. A handful of
>> > JCK tests may need to be updated for the changed specification.
>> >
>> > Impact
>> > ------
>> >
>> >   - Other JDK components: The change would ease getting and keeping
>> >      the JDK code base free of deprecations warnings.
>> >   - Compatibility: Since warning will be issued in fewer cases, there is
>> > negligible compatibility impact.
>> >   - User experience: Fewer uninformative warnings will be issued by the
>> > compiler.
>> >   - TCK: As noted earlier, a handful of JCK test may need updating.
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140210/33bc7d3a/attachment.html 

From alex.buckley at oracle.com  Mon Feb 10 20:12:19 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 10 Feb 2014 20:12:19 -0800
Subject: Draft JEP on enhanced volatiles
In-Reply-To: <52F5282F.1010808@cs.oswego.edu>
References: <52F5282F.1010808@cs.oswego.edu>
Message-ID: <52F9A323.5080800@oracle.com>

Hi Doug,

On 2/7/2014 10:38 AM, Doug Lea wrote:
> We model the extended operations on volatile integers via an interface
> VolatileInt, that also captures the functionality of AtomicInteger
> (which will also be updated to reflect Java Memory Model revisions as
> part of this JEP). A tentative version is below. Similar interfaces
> are needed for other primitive and reference types.
>
> We then enable access to corresponding methods for (typically
> volatile) fields using the ".volatile" prefix. For example:

Only "typically" volatile? Surely, "necessarily" volatile.

>      class Usage {
>          volatile int count;
>          int incrementCount() {
>              return count.volatile.incrementAndGet();
>          }
>      }
>
> The ".volatile" syntax is slightly unusual, but we are confident that
> it is syntactically unambiguous and semantically specifiable.  New
> syntax is required to avoid ambiguities with existing usages,
> especially for volatile references -- invocations of methods on the
> reference versus the referent would be indistinguishable.  The
> ".volatile" prefix introduces a scope for operations on these
> "L-values", not their retrieved contents.  However, just using the
> prefix itself without a method invocation (as in "count.volatile;")
> would be meaningless and illegal.

I presume the term before '.volatile' is not limited to an expression 
name ('count', 'this.count', 'x.f.count'); it could also be a field 
access expression ('new Outer().new Usage().count').

Note there is one field in the language which cannot be the term before 
'.volatile': the length field of an array object. Being final, it is 
necessarily not volatile, and '.volatile' only works for volatile 
fields, right?

> We also expect to allow volatile operations on array elements in
> addition to fields.

Only array elements, or array components in general? Given:

   volatile int[][] x = ...

is it meaningful to say:

   return x[0].volatile.setAllToNull();

or somesuch? In other words, is there an interface VolatileArray? (So 
Jeremy would have to update 
http://jeremymanson.blogspot.com/2009/06/volatile-arrays-in-java.html...)

> The main task is to translate these calls into corresponding JVM
> intrinsics. The most likely option is for the source compiler to use
> method handles. This and other techniques are known to suffice, but
> are subject to further exploration. Minor enhancements to intrinsics
> and a few additional JDK library methods may also be needed.

The JLS doesn't know what a JVM intrinsic is (and nor does the JVMS), so 
the meaning of count.volatile.X() must be specified by appeal to ("as if 
by ...") an invocation of the X() method on some synthesized receiver.

Alex

From vicente.romero at oracle.com  Tue Feb 11 08:46:26 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 11 Feb 2014 16:46:26 +0000
Subject: JLS string concatenation clarification
In-Reply-To: <52F54FEC.9040203@oracle.com>
References: <CAGB9EW9OnHjTFU9scLYteBgPAsZouVKSzJ7pq5+1v-qLq9Ea_Q@mail.gmail.com>	<CA+kOe08XHMR+Vk6zKdLVf1XkF9_-t40TtV3Y1bcuj2KE8XJM4w@mail.gmail.com>	<52DF14C0.1000601@oracle.com>	<52E042C2.6020708@oracle.com>	<52E6987C.5070104@oracle.com>
	<52E6B383.5090904@oracle.com> <52E81A5D.5090409@oracle.com>
	<52F54FEC.9040203@oracle.com>
Message-ID: <52FA53E2.2000304@oracle.com>

Hi Sergey,

It's hard to make sure that any change to the current "pattern" 
generated by javac will be beneficial or not in terms of performance.

I have assigned those bugs to myself but as they are not high priority I 
can't make any promise.

Thanks,
Vicente


On 07/02/14 21:28, Sergey Bylokhov wrote:
> Hi, Vicente.
> For a long time I ask a question related to the implementation of 
> concatenations of the string in javac:
> 1 Why "" + expression is compiled to
>         new StringBuilder()).append("").append(expression).toString()
>         instead of String.valueOf(expression)? see JDK-4947460

I have assigned it to myself.

> 2 Why expression1 + expression2 is compiled to
>         new 
> StringBuilder()).append(expression1).append(expression2).toString()
>         instead of new 
> StringBuilder(expression1)).append(expression2).toString()?  see 
> JDK-4059189

Same.

> 3 Why JDK-6709423 is closed as not a defect, it could at least save a 
> few bytes in the class files. Generated code currently is not perfect:
>         s += a;
>         s += b;
>         is compiled to:
>         s = new StringBuilder()).append(s).append(a).toString();
>         s = new StringBuilder()).append(s).append(b).toString();
>         instead of new StringBuilder(s).append(a).append(b).toString();

I have reopened it.

>
> I suppose, these optimizations will not affect a JIT (will not make 
> result worse) and will save the size of class file.
>
> On 29.01.2014 1:00, Vicente-Arturo Romero-Zaldivar wrote:
>> Hi Alex,
>>
>> On 27/01/14 19:29, Alex Buckley wrote:
>>> Hi Vicente,
>>>
>>> Generated code. Also, I realize that s+"" may generate different 
>>> code than ""+s - please indicate if that's the case.
>>
>> Yes the generated code is slightly different. But at the end javac 
>> only indicates what should be done. A string concatenation implies 
>> the creation of a StringBuilder with calls to it's append() method. 
>> Later the VM should these instructions only as indications.
>>
>> Vicente
>>
>>>
>>> Alex
>>>
>>> On 1/27/2014 9:33 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>>> Hi Alex,
>>>>
>>>> Are you interested in the generated code or in the compiler's internal
>>>> representation?
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> On 22/01/14 22:14, Alex Buckley wrote:
>>>>> To compiler-dev and others,
>>>>>
>>>>> Since the original question asked when the JLS allows compilers to
>>>>> deviate from "always" creating a new String object, I would like to
>>>>> know more about the following case:
>>>>>
>>>>> On 1/21/2014 4:45 PM, Alex Buckley wrote:
>>>>>> - "Semi" constant expressions like s+"". Concatenating the empty 
>>>>>> string
>>>>>> literal "" with a String expression is mentioned in
>>>>>> https://bugs.openjdk.java.net/browse/JDK-4036535. The expectation 
>>>>>> (per
>>>>>> JLS1) that a new String object is always created in this case is
>>>>>> misplaced (per the JDK's actual behavior). But, the JLS never 
>>>>>> clarified
>>>>>> this.
>>>>>
>>>>> If compiler authors can confirm (on-list or privately) that indeed
>>>>> "concatenation with empty string does not create the new instance of
>>>>> String", then I will clarify the JLS.
>>>>>
>>>>> Alex
>>>>
>>
>
>


From mark.reinhold at oracle.com  Tue Feb 11 09:42:40 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 11 Feb 2014 09:42:40 -0800
Subject: Changeset rolled back: jdk8/tl/jdk: 7152892: some jtreg tests fail
	with permission denied
Message-ID: <20140211094240.954088@eggemoggin.niobe.net>

This changeset was erroneously pushed to jdk8/tl/jdk:

  Changeset: da4b0962ad11
  Author:    robm
  Date:      2014-02-10 14:35 +0000
  URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11

  7152892: some jtreg tests fail with permission denied
  Reviewed-by: coffeys

  ! test/java/lang/ClassLoader/Assert.sh
  ! test/java/rmi/registry/readTest/readTest.sh
  ! test/java/util/zip/ZipFile/ReadZip.java
  ! test/sun/net/www/protocol/jar/jarbug/run.sh

It has been rolled back on the server and blacklisted in jcheck.

If you have a clone of this repository then either strip this
changeset or destroy the repository and re-clone it.

- Mark

From dl at cs.oswego.edu  Tue Feb 11 12:37:11 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 11 Feb 2014 15:37:11 -0500
Subject: Draft JEP on enhanced volatiles
In-Reply-To: <52F9A323.5080800@oracle.com>
References: <52F5282F.1010808@cs.oswego.edu> <52F9A323.5080800@oracle.com>
Message-ID: <52FA89F7.20702@cs.oswego.edu>

Thanks Alex for looking this over!

On 02/10/2014 11:12 PM, Alex Buckley wrote:
>>
>> We then enable access to corresponding methods for (typically
>> volatile) fields using the ".volatile" prefix. For example:
>
> Only "typically" volatile? Surely, "necessarily" volatile.

This is a TBD issue. There are good rationales and
popular demand for applying uniformly to any field (or array
element). We hope but don't know that we can provide a
reasonable memory semantics for all cases. For present purposes,
nothing much depends on this though --  either some usages of .volatile
will be caught as illegal by static semantics, or they will be
translated in the same way as other cases.

>
> I presume the term before '.volatile' is not limited to an expression name
> ('count', 'this.count', 'x.f.count'); it could also be a field access expression
> ('new Outer().new Usage().count').

Yes, the intent is any field (or array) access expression.
I haven't checked against Java8 BNF (because I haven't seen
Java8 BNF), but in older versions, it seems that adding this
to the rhs of "Selector" production should work?

>
> Note there is one field in the language which cannot be the term before
> '.volatile': the length field of an array object. Being final, it is necessarily
> not volatile, and '.volatile' only works for volatile fields, right?

Yes, thanks.

>
>> We also expect to allow volatile operations on array elements in
>> addition to fields.
>
> Only array elements, or array components in general? Given:
>
>    volatile int[][] x = ...
>
> is it meaningful to say:
>
>    return x[0].volatile.setAllToNull();

Definitely not that. x[0] here is a ref to an int[].
So you'd allow, for example,
   x[0].volatile.setRelaxed(new int[1]);
in the same cases that you'd allow:
   x[0] = new int[1];


> The JLS doesn't know what a JVM intrinsic is (and nor does the JVMS), so the
> meaning of count.volatile.X() must be specified by appeal to ("as if by ...") an
> invocation of the X() method on some synthesized receiver.
>

Yes. The form of semantics spec should be similar to that for
for-each expressions in terms of Iterable API, but with some
extra "as if" caginess.

-Doug


From alex.buckley at oracle.com  Tue Feb 11 12:53:55 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 11 Feb 2014 12:53:55 -0800
Subject: Draft JEP on enhanced volatiles
In-Reply-To: <52FA89F7.20702@cs.oswego.edu>
References: <52F5282F.1010808@cs.oswego.edu> <52F9A323.5080800@oracle.com>
	<52FA89F7.20702@cs.oswego.edu>
Message-ID: <52FA8DE3.3000002@oracle.com>

On 2/11/2014 12:37 PM, Doug Lea wrote:
> On 02/10/2014 11:12 PM, Alex Buckley wrote:
>> I presume the term before '.volatile' is not limited to an expression
>> name
>> ('count', 'this.count', 'x.f.count'); it could also be a field access
>> expression
>> ('new Outer().new Usage().count').
>
> Yes, the intent is any field (or array) access expression.
> I haven't checked against Java8 BNF (because I haven't seen
> Java8 BNF), but in older versions, it seems that adding this
> to the rhs of "Selector" production should work?

Per JDK-8020782, I reworked the grammar chapter in JLS8, so Selector is 
no more. See the JSR 337 Spec, Annex 3, JLS8, ch.19:

http://mail.openjdk.java.net/pipermail/java-se-8-spec-experts/2014-January/000049.html

I recommend modifying MethodInvocation to allow:

ExpressionName . volatile . [TypeArguments] Identifier ( ... )
FieldAccess . volatile . [TypeArguments] Identifier ( ... )
ArrayAccess . volatile . [TypeArguments] Identifier ( ... )

Alex

From lana.steuck at oracle.com  Tue Feb 11 13:40:10 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:10 +0000
Subject: hg: jdk8/tl/corba: 7 new changesets
Message-ID: <20140211214024.5EA1E62B9A@hg.openjdk.java.net>

Changeset: 18c4d03cf516
Author:    katleman
Date:      2014-01-22 12:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/18c4d03cf516

Added tag jdk8-b125 for changeset 7b45151c7a05

! .hgtags

Changeset: 8ceb68fd9e10
Author:    katleman
Date:      2014-01-22 14:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/8ceb68fd9e10

Merge

! .hgtags

Changeset: cfa04e69b115
Author:    katleman
Date:      2014-01-24 15:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/cfa04e69b115

Added tag jdk8-b126 for changeset 8ceb68fd9e10

! .hgtags

Changeset: b8c71dae0557
Author:    lana
Date:      2014-01-29 11:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/b8c71dae0557

Merge


Changeset: 113e7569b49b
Author:    katleman
Date:      2014-01-30 12:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/113e7569b49b

Added tag jdk8-b127 for changeset b8c71dae0557

! .hgtags

Changeset: 5c72d74c6805
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/5c72d74c6805

Added tag jdk8-b128 for changeset 113e7569b49b

! .hgtags

Changeset: eea0d7dfcbe2
Author:    katleman
Date:      2014-02-06 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/eea0d7dfcbe2

Added tag jdk8-b129 for changeset 5c72d74c6805

! .hgtags


From lana.steuck at oracle.com  Tue Feb 11 13:40:17 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:17 +0000
Subject: hg: jdk8/tl/langtools: 7 new changesets
Message-ID: <20140211214140.425E862B9E@hg.openjdk.java.net>

Changeset: 9a4dbfe11ed1
Author:    katleman
Date:      2014-01-22 12:54 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9a4dbfe11ed1

Added tag jdk8-b125 for changeset 436176151e85

! .hgtags

Changeset: ba24b6304362
Author:    katleman
Date:      2014-01-22 14:09 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ba24b6304362

Merge

! .hgtags

Changeset: 305b97f4651b
Author:    katleman
Date:      2014-01-24 15:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/305b97f4651b

Added tag jdk8-b126 for changeset ba24b6304362

! .hgtags

Changeset: bb69217ed812
Author:    lana
Date:      2014-01-29 11:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb69217ed812

Merge


Changeset: 09cdd3b493c0
Author:    katleman
Date:      2014-01-30 12:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09cdd3b493c0

Added tag jdk8-b127 for changeset bb69217ed812

! .hgtags

Changeset: 8fe7202d3c38
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8fe7202d3c38

Added tag jdk8-b128 for changeset 09cdd3b493c0

! .hgtags

Changeset: 9d81ae1c417a
Author:    katleman
Date:      2014-02-06 17:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d81ae1c417a

Added tag jdk8-b129 for changeset 8fe7202d3c38

! .hgtags


From lana.steuck at oracle.com  Tue Feb 11 13:40:13 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:13 +0000
Subject: hg: jdk8/tl/jaxws: 7 new changesets
Message-ID: <20140211214119.DF23C62B9C@hg.openjdk.java.net>

Changeset: c0040f0b75e2
Author:    katleman
Date:      2014-01-22 12:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c0040f0b75e2

Added tag jdk8-b125 for changeset ef71ecbcd7bc

! .hgtags

Changeset: 7193a007a159
Author:    katleman
Date:      2014-01-22 14:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7193a007a159

Merge

! .hgtags

Changeset: 3f682f2ea376
Author:    katleman
Date:      2014-01-24 15:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3f682f2ea376

Added tag jdk8-b126 for changeset 7193a007a159

! .hgtags

Changeset: 8e46fe36e175
Author:    lana
Date:      2014-01-29 11:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8e46fe36e175

Merge


Changeset: de172acc095b
Author:    katleman
Date:      2014-01-30 12:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/de172acc095b

Added tag jdk8-b127 for changeset 8e46fe36e175

! .hgtags

Changeset: aabc90596123
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/aabc90596123

Added tag jdk8-b128 for changeset de172acc095b

! .hgtags

Changeset: 4195c0956930
Author:    katleman
Date:      2014-02-06 17:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/4195c0956930

Added tag jdk8-b129 for changeset aabc90596123

! .hgtags


From lana.steuck at oracle.com  Tue Feb 11 13:40:17 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:17 +0000
Subject: hg: jdk8/tl/jaxp: 7 new changesets
Message-ID: <20140211214123.063DA62B9D@hg.openjdk.java.net>

Changeset: 6a5af8a36aaf
Author:    katleman
Date:      2014-01-22 12:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6a5af8a36aaf

Added tag jdk8-b125 for changeset 83bb924238f8

! .hgtags

Changeset: 390cc275c04c
Author:    katleman
Date:      2014-01-22 14:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/390cc275c04c

Merge

! .hgtags

Changeset: 573c261a2025
Author:    katleman
Date:      2014-01-24 15:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/573c261a2025

Added tag jdk8-b126 for changeset 390cc275c04c

! .hgtags

Changeset: b68cdb63a70b
Author:    lana
Date:      2014-01-29 11:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b68cdb63a70b

Merge


Changeset: b1839922f10c
Author:    katleman
Date:      2014-01-30 12:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b1839922f10c

Added tag jdk8-b127 for changeset b68cdb63a70b

! .hgtags

Changeset: b7752cea7c81
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b7752cea7c81

Added tag jdk8-b128 for changeset b1839922f10c

! .hgtags

Changeset: 0cb0cd015218
Author:    katleman
Date:      2014-02-06 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0cb0cd015218

Added tag jdk8-b129 for changeset b7752cea7c81

! .hgtags


From lana.steuck at oracle.com  Tue Feb 11 13:40:24 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:24 +0000
Subject: hg: jdk8/tl/nashorn: 8 new changesets
Message-ID: <20140211214101.632E862B9B@hg.openjdk.java.net>

Changeset: d336209a0e45
Author:    katleman
Date:      2014-01-22 12:54 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d336209a0e45

Added tag jdk8-b125 for changeset 7346abe2ea03

! .hgtags

Changeset: 095263db862d
Author:    katleman
Date:      2014-01-22 14:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/095263db862d

Merge

! .hgtags

Changeset: e2522604c7c9
Author:    katleman
Date:      2014-01-24 15:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e2522604c7c9

Added tag jdk8-b126 for changeset 095263db862d

! .hgtags

Changeset: fdfbb745caf0
Author:    lana
Date:      2014-01-29 11:12 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fdfbb745caf0

Merge


Changeset: 7dfde83426d1
Author:    katleman
Date:      2014-01-30 12:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7dfde83426d1

Added tag jdk8-b127 for changeset fdfbb745caf0

! .hgtags

Changeset: 73cbad0c5d28
Author:    lana
Date:      2014-01-31 13:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/73cbad0c5d28

Merge


Changeset: 9cc3fd32fbab
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9cc3fd32fbab

Added tag jdk8-b128 for changeset 73cbad0c5d28

! .hgtags

Changeset: f87eba70e9ee
Author:    katleman
Date:      2014-02-06 17:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f87eba70e9ee

Added tag jdk8-b129 for changeset 9cc3fd32fbab

! .hgtags


From lana.steuck at oracle.com  Tue Feb 11 13:40:17 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:17 +0000
Subject: hg: jdk8/tl/hotspot: 23 new changesets
Message-ID: <20140211214227.12C4F62B9F@hg.openjdk.java.net>

Changeset: 16e0c6c84a91
Author:    amurillo
Date:      2014-01-13 16:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16e0c6c84a91

8031553: new hotspot build - hs25-b67
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 12ad8db39f76
Author:    roland
Date:      2014-01-14 09:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12ad8db39f76

8028764: dtrace/hotspot_jni/ALL/ALL001 crashes the vm on Solaris-amd64, SIGSEGV in MarkSweep::follow_stack()+0x8a
Summary: C1 generates code to encode compressed oop into tmp register before runtime call for patching where GC may happen
Reviewed-by: iveresov, twisti, kvn
Contributed-by: mgerdin <mikael.gerdin at oracle.com>

! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 8b81451dc7f7
Author:    twisti
Date:      2014-01-16 16:18 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b81451dc7f7

8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests
Reviewed-by: kvn, iveresov

! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp

Changeset: 3585183c191a
Author:    amurillo
Date:      2014-01-17 20:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3585183c191a

Merge


Changeset: 5df2666e4573
Author:    amurillo
Date:      2014-01-17 20:24 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5df2666e4573

Added tag hs25-b67 for changeset 3585183c191a

! .hgtags

Changeset: 55ff9170e27d
Author:    katleman
Date:      2014-01-22 12:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55ff9170e27d

Added tag jdk8-b125 for changeset df333ee12bba

! .hgtags

Changeset: c8218f1072a0
Author:    katleman
Date:      2014-01-22 14:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8218f1072a0

Merge

! .hgtags

Changeset: 9a11d5e679cf
Author:    katleman
Date:      2014-01-24 15:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a11d5e679cf

Added tag jdk8-b126 for changeset c8218f1072a0

! .hgtags

Changeset: c2106608358b
Author:    amurillo
Date:      2014-01-17 20:30 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c2106608358b

8032015: new hotspot build - hs25-b68
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 709018897c81
Author:    vlivanov
Date:      2014-01-23 01:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/709018897c81

8031695: CHA ignores default methods during analysis leading to incorrect code generation
Reviewed-by: jrose, acorn, hseigel, lfoltan

! src/share/vm/code/dependencies.cpp
+ test/compiler/inlining/DefaultAndConcreteMethodsCHA.java

Changeset: f970454708b8
Author:    iveresov
Date:      2014-01-17 18:09 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f970454708b8

8032207: C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size
Summary: Fix the sizing of loadUS2L_immI16 and loadI2L_immI
Reviewed-by: kvn, azeemj

! src/cpu/sparc/vm/sparc.ad
+ test/compiler/codegen/LoadWithMask.java

Changeset: 984401824c5e
Author:    iveresov
Date:      2014-01-21 20:05 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/984401824c5e

8031743: C2: loadI2L_immI broken for negative memory values
Summary: Restrict loadI2L_imm optimizations to positive values of mask
Reviewed-by: kvn, dlong

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
+ test/compiler/codegen/LoadWithMask2.java

Changeset: d45454002494
Author:    amurillo
Date:      2014-01-23 13:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d45454002494

Merge


Changeset: 2c564e329c87
Author:    amurillo
Date:      2014-01-23 13:37 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c564e329c87

Added tag hs25-b68 for changeset d45454002494

! .hgtags

Changeset: 58879cd9f8df
Author:    amurillo
Date:      2014-01-28 09:51 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58879cd9f8df

Merge

! .hgtags

Changeset: 7e412f95e310
Author:    amurillo
Date:      2014-01-23 13:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e412f95e310

8032608: new hotspot build - hs25-b69
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 2185d483f5f8
Author:    kvn
Date:      2014-01-27 10:20 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2185d483f5f8

8032566: Crash in JIT when running Scala compiler (and compiling Scala std lib)
Summary: Switch off EliminateAutoBox flag by default in jdk8 release.
Reviewed-by: iveresov

! src/share/vm/opto/c2_globals.hpp

Changeset: 32f017489ba5
Author:    amurillo
Date:      2014-01-28 15:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32f017489ba5

Merge


Changeset: 1d8728efc05f
Author:    amurillo
Date:      2014-01-28 15:00 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d8728efc05f

Added tag hs25-b69 for changeset 32f017489ba5

! .hgtags

Changeset: 35038da7bb9d
Author:    lana
Date:      2014-01-29 11:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35038da7bb9d

Merge


Changeset: 874c0b4a946c
Author:    katleman
Date:      2014-01-30 12:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/874c0b4a946c

Added tag jdk8-b127 for changeset 35038da7bb9d

! .hgtags

Changeset: cb39165c4a65
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb39165c4a65

Added tag jdk8-b128 for changeset 874c0b4a946c

! .hgtags

Changeset: 1dbaf664a611
Author:    katleman
Date:      2014-02-06 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1dbaf664a611

Added tag jdk8-b129 for changeset cb39165c4a65

! .hgtags


From lana.steuck at oracle.com  Tue Feb 11 13:40:47 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:47 +0000
Subject: hg: jdk8/tl/jdk: 14 new changesets
Message-ID: <20140211214445.3A9FE62BA0@hg.openjdk.java.net>

Changeset: 75cf17ceb6d1
Author:    katleman
Date:      2014-01-22 12:54 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75cf17ceb6d1

Added tag jdk8-b125 for changeset ae303640bc1c

! .hgtags

Changeset: 95410515ba5f
Author:    katleman
Date:      2014-01-22 14:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95410515ba5f

Merge

! .hgtags

Changeset: 91bce40d0347
Author:    alexsch
Date:      2014-01-23 20:36 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91bce40d0347

8032063: javax.swing.plaf.metal.MetalFileChooserUI$FilterComboBoxModel extends non-standard API
Reviewed-by: pchelko, serb

! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java
! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java
- src/share/classes/sun/swing/AbstractFilterComboBoxModel.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java

Changeset: 6935e7a3a7c9
Author:    amurillo
Date:      2014-01-23 14:46 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6935e7a3a7c9

Merge


Changeset: a9088d517f2f
Author:    amurillo
Date:      2014-01-23 14:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9088d517f2f

Merge


Changeset: a635c394328c
Author:    katleman
Date:      2014-01-24 15:08 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a635c394328c

Added tag jdk8-b126 for changeset a9088d517f2f

! .hgtags

Changeset: fbf251b8ef8a
Author:    lana
Date:      2014-01-29 11:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbf251b8ef8a

Merge


Changeset: f777d83e0433
Author:    katleman
Date:      2014-01-30 12:17 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f777d83e0433

Added tag jdk8-b127 for changeset fbf251b8ef8a

! .hgtags

Changeset: f644211c59fd
Author:    lana
Date:      2014-01-31 13:47 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f644211c59fd

Merge


Changeset: 3c9473004f38
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c9473004f38

Added tag jdk8-b128 for changeset f644211c59fd

! .hgtags

Changeset: ab6e7bb8ff9f
Author:    pchelko
Date:      2014-01-22 16:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab6e7bb8ff9f

7155984: Security problems in regression test java/awt/PrintJob/Security/SecurityDialogTest.java
Reviewed-by: anthony, serb

! src/macosx/classes/apple/laf/JRSUIUtils.java

Changeset: eef10feca8ca
Author:    lana
Date:      2014-02-06 13:28 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eef10feca8ca

Merge


Changeset: 80568a19aab7
Author:    lana
Date:      2014-02-06 13:29 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80568a19aab7

Merge


Changeset: 43386cc9a017
Author:    katleman
Date:      2014-02-06 17:35 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43386cc9a017

Added tag jdk8-b129 for changeset 80568a19aab7

! .hgtags


From lana.steuck at oracle.com  Tue Feb 11 13:40:08 2014
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Tue, 11 Feb 2014 21:40:08 +0000
Subject: hg: jdk8/tl: 8 new changesets
Message-ID: <20140211214010.B63CD62B98@hg.openjdk.java.net>

Changeset: 950921234b10
Author:    katleman
Date:      2014-01-22 12:53 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/950921234b10

Added tag jdk8-b125 for changeset 790bbd46b201

! .hgtags

Changeset: 1b5d578f93ef
Author:    katleman
Date:      2014-01-22 14:06 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/1b5d578f93ef

Merge

! .hgtags

Changeset: 9ccce5bf1b0e
Author:    katleman
Date:      2014-01-24 04:45 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/9ccce5bf1b0e

Merge


Changeset: 4f8fa4724c14
Author:    katleman
Date:      2014-01-24 15:07 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4f8fa4724c14

Added tag jdk8-b126 for changeset 9ccce5bf1b0e

! .hgtags

Changeset: 2e2ffb9e4b69
Author:    lana
Date:      2014-01-29 11:11 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/2e2ffb9e4b69

Merge


Changeset: 101e42de4686
Author:    katleman
Date:      2014-01-30 12:16 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/101e42de4686

Added tag jdk8-b127 for changeset 2e2ffb9e4b69

! .hgtags

Changeset: 1e5fe8654913
Author:    katleman
Date:      2014-02-01 18:21 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/1e5fe8654913

Added tag jdk8-b128 for changeset 101e42de4686

! .hgtags

Changeset: 839546caab12
Author:    katleman
Date:      2014-02-06 17:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/839546caab12

Added tag jdk8-b129 for changeset 1e5fe8654913

! .hgtags


From alex.buckley at oracle.com  Tue Feb 11 20:28:15 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 11 Feb 2014 20:28:15 -0800
Subject: JLS string concatenation clarification
In-Reply-To: <52E042C2.6020708@oracle.com>
References: <CAGB9EW9OnHjTFU9scLYteBgPAsZouVKSzJ7pq5+1v-qLq9Ea_Q@mail.gmail.com>	<CA+kOe08XHMR+Vk6zKdLVf1XkF9_-t40TtV3Y1bcuj2KE8XJM4w@mail.gmail.com>	<52DF14C0.1000601@oracle.com>
	<52E042C2.6020708@oracle.com>
Message-ID: <52FAF85F.4020409@oracle.com>

On 1/22/2014 2:14 PM, Alex Buckley wrote:
> On 1/21/2014 4:45 PM, Alex Buckley wrote:
>> - "Semi" constant expressions like s+"". Concatenating the empty string
>> literal "" with a String expression is mentioned in
>> https://bugs.openjdk.java.net/browse/JDK-4036535. The expectation (per
>> JLS1) that a new String object is always created in this case is
>> misplaced (per the JDK's actual behavior). But, the JLS never clarified
>> this.
>
> If compiler authors can confirm (on-list or privately) that indeed
> "concatenation with empty string does not create the new instance of
> String", then I will clarify the JLS.

On reflection, I wonder if the "sometimes" in JLS1 12.5 was written at a 
point in history when the JDK didn't always create a new String for +, 
at least when "" was an operand. After all, JDK-4036535 has evidence 
that a JDK once arranged for ""+s1 == s1.

(An alternate theory is that "sometimes" refers to the creation of some 
other String object, such as an intermediate result of string 
conversion. But that's very subtle.)

Nowadays, javac and ecj both use a StringBuilder method chain, 
culminating in a toString() call that ensures a new String object every 
time. The "sometimes" is wrong and I have filed spec bug JDK-8034259.

Alex


From Sergey.Bylokhov at oracle.com  Wed Feb 12 09:47:25 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 12 Feb 2014 21:47:25 +0400
Subject: JLS string concatenation clarification
In-Reply-To: <52FAF85F.4020409@oracle.com>
References: <CAGB9EW9OnHjTFU9scLYteBgPAsZouVKSzJ7pq5+1v-qLq9Ea_Q@mail.gmail.com>	<CA+kOe08XHMR+Vk6zKdLVf1XkF9_-t40TtV3Y1bcuj2KE8XJM4w@mail.gmail.com>	<52DF14C0.1000601@oracle.com>	<52E042C2.6020708@oracle.com>
	<52FAF85F.4020409@oracle.com>
Message-ID: <52FBB3AD.1070102@oracle.com>

Hi, Alex.
Just to clarify " a new String is always created for a + ". How many 
String objects should be created in such code from specification point 
of view:
String a,b,c; // locals variables
1) String s = a + b +c;  // One line
or
2) String s=a; s+=b; s+=c; // One line


On 2/12/14 8:28 AM, Alex Buckley wrote:
> On 1/22/2014 2:14 PM, Alex Buckley wrote:
>> On 1/21/2014 4:45 PM, Alex Buckley wrote:
>>> - "Semi" constant expressions like s+"". Concatenating the empty string
>>> literal "" with a String expression is mentioned in
>>> https://bugs.openjdk.java.net/browse/JDK-4036535. The expectation (per
>>> JLS1) that a new String object is always created in this case is
>>> misplaced (per the JDK's actual behavior). But, the JLS never clarified
>>> this.
>>
>> If compiler authors can confirm (on-list or privately) that indeed
>> "concatenation with empty string does not create the new instance of
>> String", then I will clarify the JLS.
>
> On reflection, I wonder if the "sometimes" in JLS1 12.5 was written at 
> a point in history when the JDK didn't always create a new String for 
> +, at least when "" was an operand. After all, JDK-4036535 has 
> evidence that a JDK once arranged for ""+s1 == s1.
>
> (An alternate theory is that "sometimes" refers to the creation of 
> some other String object, such as an intermediate result of string 
> conversion. But that's very subtle.)
>
> Nowadays, javac and ecj both use a StringBuilder method chain, 
> culminating in a toString() call that ensures a new String object 
> every time. The "sometimes" is wrong and I have filed spec bug 
> JDK-8034259.
>
> Alex
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140212/732a0c6c/attachment.html 

From alex.buckley at oracle.com  Wed Feb 12 10:49:48 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 12 Feb 2014 10:49:48 -0800
Subject: JLS string concatenation clarification
In-Reply-To: <52FBB3AD.1070102@oracle.com>
References: <CAGB9EW9OnHjTFU9scLYteBgPAsZouVKSzJ7pq5+1v-qLq9Ea_Q@mail.gmail.com>	<CA+kOe08XHMR+Vk6zKdLVf1XkF9_-t40TtV3Y1bcuj2KE8XJM4w@mail.gmail.com>	<52DF14C0.1000601@oracle.com>	<52E042C2.6020708@oracle.com>
	<52FAF85F.4020409@oracle.com> <52FBB3AD.1070102@oracle.com>
Message-ID: <52FBC24C.6020500@oracle.com>

+ is left-associative, so a+b+c means (a+b)+c. Neither a nor b nor c is 
a constant variable, so there are no constant expressions here. The 
evaluation of a+b should create a new String object, and the evaluation 
of its reference + c should create another.

s+=b means s=(String)(s+b), so one new String object should be created; 
similarly for s=(String)(s+c). The number of lines of source code is 
irrelevant.

Are you writing JCK tests in this area?

Alex

On 2/12/2014 9:47 AM, Sergey Bylokhov wrote:
> Hi, Alex.
> Just to clarify " a new String is always created for a + ". How many
> String objects should be created in such code from specification point
> of view:
> String a,b,c; // locals variables
> 1) String s = a + b +c;  // One line
> or
> 2) String s=a; s+=b; s+=c; // One line
>
>
> On 2/12/14 8:28 AM, Alex Buckley wrote:
>> On 1/22/2014 2:14 PM, Alex Buckley wrote:
>>> On 1/21/2014 4:45 PM, Alex Buckley wrote:
>>>> - "Semi" constant expressions like s+"". Concatenating the empty string
>>>> literal "" with a String expression is mentioned in
>>>> https://bugs.openjdk.java.net/browse/JDK-4036535. The expectation (per
>>>> JLS1) that a new String object is always created in this case is
>>>> misplaced (per the JDK's actual behavior). But, the JLS never clarified
>>>> this.
>>>
>>> If compiler authors can confirm (on-list or privately) that indeed
>>> "concatenation with empty string does not create the new instance of
>>> String", then I will clarify the JLS.
>>
>> On reflection, I wonder if the "sometimes" in JLS1 12.5 was written at
>> a point in history when the JDK didn't always create a new String for
>> +, at least when "" was an operand. After all, JDK-4036535 has
>> evidence that a JDK once arranged for ""+s1 == s1.
>>
>> (An alternate theory is that "sometimes" refers to the creation of
>> some other String object, such as an intermediate result of string
>> conversion. But that's very subtle.)
>>
>> Nowadays, javac and ecj both use a StringBuilder method chain,
>> culminating in a toString() call that ensures a new String object
>> every time. The "sometimes" is wrong and I have filed spec bug
>> JDK-8034259.
>>
>> Alex
>>
>
>
> --
> Best regards, Sergey.
>

From cushon at google.com  Wed Feb 12 17:49:31 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 12 Feb 2014 17:49:31 -0800
Subject: compilation fails with 'no enclosing instance' error
Message-ID: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>

Hi,

I discovered a JDK8-b128 compilation error that does not occur with JDK7:

=== base/BaseImpl.java ===
package base;

public class BaseImpl {
  static void foo(Object o) {}
}
===

=== Test.java ===
class Impl extends base.BaseImpl {
  public void foo(Object o) {}
}

class MyImpl extends Impl {
  public void m(Object o) {
    foo(o);
  }
}
===

$ javac base/BaseImpl.java Test.java
Test.java:7: error: no enclosing instance of type Impl is in scope
    foo(o);
    ^

Is this a deliberate change, or a regression? If it's deliberate, the error
message is not very clear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140212/9d4e8582/attachment.html 

From alex.buckley at oracle.com  Wed Feb 12 18:20:21 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 12 Feb 2014 18:20:21 -0800
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
Message-ID: <52FC2BE5.9010903@oracle.com>

Regression. MyImpl inherits the instance method foo(Object) from Impl, 
and foo(o) should invoke the inherited method. At least javac is 
recognizing that the type Impl is an important source of truth.

The foo(Object) method in base.BaseImpl is irrelevant because, having 
package access, it's not inherited by Impl.

Alex

On 2/12/2014 5:49 PM, Liam Miller-Cushon wrote:
> Hi,
>
> I discovered a JDK8-b128 compilation error that does not occur with JDK7:
>
> === base/BaseImpl.java ===
> package base;
>
> public class BaseImpl {
>    static void foo(Object o) {}
> }
> ===
>
> === Test.java ===
> class Impl extends base.BaseImpl {
>    public void foo(Object o) {}
> }
>
> class MyImpl extends Impl {
>    public void m(Object o) {
>      foo(o);
>    }
> }
> ===
>
> $ javac base/BaseImpl.java Test.java
> Test.java:7: error: no enclosing instance of type Impl is in scope
>      foo(o);
>      ^
>
> Is this a deliberate change, or a regression? If it's deliberate, the
> error message is not very clear.

From Sergey.Bylokhov at oracle.com  Thu Feb 13 01:52:32 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 13 Feb 2014 13:52:32 +0400
Subject: JLS string concatenation clarification
In-Reply-To: <52FBC24C.6020500@oracle.com>
References: <CAGB9EW9OnHjTFU9scLYteBgPAsZouVKSzJ7pq5+1v-qLq9Ea_Q@mail.gmail.com>	<CA+kOe08XHMR+Vk6zKdLVf1XkF9_-t40TtV3Y1bcuj2KE8XJM4w@mail.gmail.com>	<52DF14C0.1000601@oracle.com>	<52E042C2.6020708@oracle.com>
	<52FAF85F.4020409@oracle.com> <52FBB3AD.1070102@oracle.com>
	<52FBC24C.6020500@oracle.com>
Message-ID: <52FC95E0.8030506@oracle.com>

On 12.02.2014 22:49, Alex Buckley wrote:
> + is left-associative, so a+b+c means (a+b)+c. Neither a nor b nor c 
> is a constant variable, so there are no constant expressions here. The 
> evaluation of a+b should create a new String object, and the 
> evaluation of its reference + c should create another.
So how we follow the specification here if it is compiled to:
s =  a + b + c ==>> s = 
StringBuilder().append(s).append(a).append(b).append(c).toString();
>
> s+=b means s=(String)(s+b), so one new String object should be 
> created; similarly for s=(String)(s+c). The number of lines of source 
> code is irrelevant.
>
> Are you writing JCK tests in this area?
no, I try to understand this area
>
> Alex
>
> On 2/12/2014 9:47 AM, Sergey Bylokhov wrote:
>> Hi, Alex.
>> Just to clarify " a new String is always created for a + ". How many
>> String objects should be created in such code from specification point
>> of view:
>> String a,b,c; // locals variables
>> 1) String s = a + b +c;  // One line
>> or
>> 2) String s=a; s+=b; s+=c; // One line
>>
>>
>> On 2/12/14 8:28 AM, Alex Buckley wrote:
>>> On 1/22/2014 2:14 PM, Alex Buckley wrote:
>>>> On 1/21/2014 4:45 PM, Alex Buckley wrote:
>>>>> - "Semi" constant expressions like s+"". Concatenating the empty 
>>>>> string
>>>>> literal "" with a String expression is mentioned in
>>>>> https://bugs.openjdk.java.net/browse/JDK-4036535. The expectation 
>>>>> (per
>>>>> JLS1) that a new String object is always created in this case is
>>>>> misplaced (per the JDK's actual behavior). But, the JLS never 
>>>>> clarified
>>>>> this.
>>>>
>>>> If compiler authors can confirm (on-list or privately) that indeed
>>>> "concatenation with empty string does not create the new instance of
>>>> String", then I will clarify the JLS.
>>>
>>> On reflection, I wonder if the "sometimes" in JLS1 12.5 was written at
>>> a point in history when the JDK didn't always create a new String for
>>> +, at least when "" was an operand. After all, JDK-4036535 has
>>> evidence that a JDK once arranged for ""+s1 == s1.
>>>
>>> (An alternate theory is that "sometimes" refers to the creation of
>>> some other String object, such as an intermediate result of string
>>> conversion. But that's very subtle.)
>>>
>>> Nowadays, javac and ecj both use a StringBuilder method chain,
>>> culminating in a toString() call that ensures a new String object
>>> every time. The "sometimes" is wrong and I have filed spec bug
>>> JDK-8034259.
>>>
>>> Alex
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>


-- 
Best regards, Sergey.


From cushon at google.com  Thu Feb 13 14:51:30 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 13 Feb 2014 14:51:30 -0800
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <52FC2BE5.9010903@oracle.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
Message-ID: <CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>

Thanks for confirming.

Would someone with access to the bug tracker mind filing this? Or should I
submit a report to http://bugreport.java.com? It would be helpful to have a
bug ID to refer to.


On Wed, Feb 12, 2014 at 6:20 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

> Regression. MyImpl inherits the instance method foo(Object) from Impl, and
> foo(o) should invoke the inherited method. At least javac is recognizing
> that the type Impl is an important source of truth.
>
> The foo(Object) method in base.BaseImpl is irrelevant because, having
> package access, it's not inherited by Impl.
>
> Alex
>
>
> On 2/12/2014 5:49 PM, Liam Miller-Cushon wrote:
>
>> Hi,
>>
>> I discovered a JDK8-b128 compilation error that does not occur with JDK7:
>>
>> === base/BaseImpl.java ===
>> package base;
>>
>> public class BaseImpl {
>>    static void foo(Object o) {}
>> }
>> ===
>>
>> === Test.java ===
>> class Impl extends base.BaseImpl {
>>    public void foo(Object o) {}
>> }
>>
>> class MyImpl extends Impl {
>>    public void m(Object o) {
>>      foo(o);
>>    }
>> }
>> ===
>>
>> $ javac base/BaseImpl.java Test.java
>> Test.java:7: error: no enclosing instance of type Impl is in scope
>>      foo(o);
>>      ^
>>
>> Is this a deliberate change, or a regression? If it's deliberate, the
>> error message is not very clear.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140213/b28f57c3/attachment.html 

From cushon at google.com  Thu Feb 13 15:28:28 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 13 Feb 2014 15:28:28 -0800
Subject: Bug with simple name lookup inside extends clause?
Message-ID: <CAL4QsguxeAmBvQh4+spq_HqAVemXDcHQg1oeUaL8bLZCWa4dSw@mail.gmail.com>

The following snippet compiles with javac7, but not javac8-b128.

Shouldn't the type parameter T be shadowing the inner class Test.T?

===
class Test {
  class T<E> {}
  abstract class One<E> {
    abstract E foo();
  }
  abstract class Two<T> extends One<T> {
    abstract T foo();
  }
}
===

error: foo() in Test.Two cannot override foo() in Test.One
    abstract T foo();
               ^
  return type T is not compatible with Test.T
  where T,E are type-variables:
    T extends Object declared in class Test.Two
    E extends Object declared in class Test.One
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140213/4f3ad8fd/attachment.html 

From alex.buckley at oracle.com  Thu Feb 13 16:02:37 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 13 Feb 2014 16:02:37 -0800
Subject: Bug with simple name lookup inside extends clause?
In-Reply-To: <CAL4QsguxeAmBvQh4+spq_HqAVemXDcHQg1oeUaL8bLZCWa4dSw@mail.gmail.com>
References: <CAL4QsguxeAmBvQh4+spq_HqAVemXDcHQg1oeUaL8bLZCWa4dSw@mail.gmail.com>
Message-ID: <52FD5D1D.1040407@oracle.com>

Regression. The scope of class T's declaration is the body of class 
Test, including the 'extends' clause of class Two and the body of class 
Two. However, the type parameter T declared for class Two should shadow 
class T's declaration throughout the 'extends' clause and body of class Two.

Related bug: https://bugs.openjdk.java.net/browse/JDK-7118412.

Alex

On 2/13/2014 3:28 PM, Liam Miller-Cushon wrote:
> The following snippet compiles with javac7, but not javac8-b128.
>
> Shouldn't the type parameter T be shadowing the inner class Test.T?
>
> ===
> class Test {
>    class T<E> {}
>    abstract class One<E> {
>      abstract E foo();
>    }
>    abstract class Two<T> extends One<T> {
>      abstract T foo();
>    }
> }
> ===
>
> error: foo() in Test.Two cannot override foo() in Test.One
>      abstract T foo();
>                 ^
>    return type T is not compatible with Test.T
>    where T,E are type-variables:
>      T extends Object declared in class Test.Two
>      E extends Object declared in class Test.One

From alex.buckley at oracle.com  Thu Feb 13 16:26:45 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 13 Feb 2014 16:26:45 -0800
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
Message-ID: <52FD62C5.7020006@oracle.com>

Filed https://bugs.openjdk.java.net/browse/JDK-8034924.

Some observations:

- The compile-time error appears (incorrectly) whether the static method 
in base.BaseImpl is package access or private. But if the static method 
is public, then everything works fine: Impl.foo(Object) attempts to 
override base.BaseImpl.foo(Object), and a compile-time error occurs 
because an instance method cannot override a static method.

- In MyImpl.m, if you replace foo(o) with this.foo(o), then the program 
compiles correctly.

Alex

On 2/13/2014 2:51 PM, Liam Miller-Cushon wrote:
> Thanks for confirming.
>
> Would someone with access to the bug tracker mind filing this? Or should
> I submit a report to http://bugreport.java.com? It would be helpful to
> have a bug ID to refer to.
>
>
> On Wed, Feb 12, 2014 at 6:20 PM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     Regression. MyImpl inherits the instance method foo(Object) from
>     Impl, and foo(o) should invoke the inherited method. At least javac
>     is recognizing that the type Impl is an important source of truth.
>
>     The foo(Object) method in base.BaseImpl is irrelevant because,
>     having package access, it's not inherited by Impl.
>
>     Alex
>
>
>     On 2/12/2014 5:49 PM, Liam Miller-Cushon wrote:
>
>         Hi,
>
>         I discovered a JDK8-b128 compilation error that does not occur
>         with JDK7:
>
>         === base/BaseImpl.java ===
>         package base;
>
>         public class BaseImpl {
>             static void foo(Object o) {}
>         }
>         ===
>
>         === Test.java ===
>         class Impl extends base.BaseImpl {
>             public void foo(Object o) {}
>         }
>
>         class MyImpl extends Impl {
>             public void m(Object o) {
>               foo(o);
>             }
>         }
>         ===
>
>         $ javac base/BaseImpl.java Test.java
>         Test.java:7: error: no enclosing instance of type Impl is in scope
>               foo(o);
>               ^
>
>         Is this a deliberate change, or a regression? If it's
>         deliberate, the
>         error message is not very clear.
>
>

From cushon at google.com  Thu Feb 13 16:57:07 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 13 Feb 2014 16:57:07 -0800
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <52FD62C5.7020006@oracle.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
	<52FD62C5.7020006@oracle.com>
Message-ID: <CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>

>
> Filed https://bugs.openjdk.java.net/browse/JDK-8034924.
>

Thanks!


> - The compile-time error appears (incorrectly) whether the static method
> in base.BaseImpl is package access or private. But if the static method is
> public, then everything works fine: Impl.foo(Object) attempts to override
> base.BaseImpl.foo(Object), and a compile-time error occurs because an
> instance method cannot override a static method.
>

I think the culprit is that Symbol.hiddenIn(...) doesn't consider
visibility. It's incorrectly reporting Impl.foo() as being hidden by
base.BaseImpl.foo(), which causes an error during lowering when a qualified
base class reference is being synthesized for the invocation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140213/daa01211/attachment.html 

From cushon at google.com  Fri Feb 14 17:07:44 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 14 Feb 2014 17:07:44 -0800
Subject: Inference of recursive types
Message-ID: <CAL4Qsgv1_eHHfv_VOTgEE3iqCF7hv2wrOJ-b7RyiyN=Wesjabw@mail.gmail.com>

Hi -

Sorry if this has already been discussed, but I ran into a difference in
behaviour between javac8 -source 7/-target 7 and both javac7 and javac8
-source 8/-target 8.

The following program compiles with everything except javac8 -source
7/-target 7.

Is this an intentional change? Having to make g's type parameter explicit
feels like a regression.

===
class Test {
  static class One<T> {}
  static class Two extends One<Two> {}

  <T extends One<T>> T f(T a, String s) {
    T t = g(s);
    return t;
  }
  static <U extends One<U>> U g(String s) {
    throw new RuntimeException();
  }
}
===

Test.java:6: error: incompatible types: inference variable U#1 has
incompatible upper bounds One<U#2>,T
    T t = g(s);
           ^
  where U#1,U#2,T are type-variables:
    U#1 extends One<U#1> declared in method <U#1>g(String)
    U#2 extends T
    T extends One<T> declared in method <T>f(T,String)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140214/5361e27f/attachment.html 

From vicente.romero at oracle.com  Tue Feb 18 11:49:12 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 18 Feb 2014 19:49:12 +0000
Subject: Bug with simple name lookup inside extends clause?
In-Reply-To: <52FD5D1D.1040407@oracle.com>
References: <CAL4QsguxeAmBvQh4+spq_HqAVemXDcHQg1oeUaL8bLZCWa4dSw@mail.gmail.com>
	<52FD5D1D.1040407@oracle.com>
Message-ID: <5303B938.9000602@oracle.com>

Hi,

I have filed this bug entry: 
https://bugs.openjdk.java.net/browse/JDK-8035259, to track this issue.

Thanks,
Vicente

On 14/02/14 00:02, Alex Buckley wrote:
> Regression. The scope of class T's declaration is the body of class 
> Test, including the 'extends' clause of class Two and the body of 
> class Two. However, the type parameter T declared for class Two should 
> shadow class T's declaration throughout the 'extends' clause and body 
> of class Two.
>
> Related bug: https://bugs.openjdk.java.net/browse/JDK-7118412.
>
> Alex
>
> On 2/13/2014 3:28 PM, Liam Miller-Cushon wrote:
>> The following snippet compiles with javac7, but not javac8-b128.
>>
>> Shouldn't the type parameter T be shadowing the inner class Test.T?
>>
>> ===
>> class Test {
>>    class T<E> {}
>>    abstract class One<E> {
>>      abstract E foo();
>>    }
>>    abstract class Two<T> extends One<T> {
>>      abstract T foo();
>>    }
>> }
>> ===
>>
>> error: foo() in Test.Two cannot override foo() in Test.One
>>      abstract T foo();
>>                 ^
>>    return type T is not compatible with Test.T
>>    where T,E are type-variables:
>>      T extends Object declared in class Test.Two
>>      E extends Object declared in class Test.One


From neil.toda at oracle.com  Tue Feb 18 13:10:01 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Tue, 18 Feb 2014 13:10:01 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option from
	javadoc tests
Message-ID: <5303CC29.8090909@oracle.com>


A small set of javadoc tests contain the -source parameter.  In most 
cases, the parameter is
not required for the test.  In several cases, the -source parameter is 
being explicitly tested,
but relies on a JDK version that will be removed from JDK9.

This changeset removes unnecessary -source specification when not 
needed, or changes the
test/source-version requested to one that will work in JDK9.

http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/

Thanks

-neil




From michel.trudeau at oracle.com  Tue Feb 18 21:02:14 2014
From: michel.trudeau at oracle.com (Michel Trudeau)
Date: Tue, 18 Feb 2014 21:02:14 -0800
Subject: Bug with simple name lookup inside extends clause?
In-Reply-To: <5303B938.9000602@oracle.com>
References: <CAL4QsguxeAmBvQh4+spq_HqAVemXDcHQg1oeUaL8bLZCWa4dSw@mail.gmail.com>
	<52FD5D1D.1040407@oracle.com> <5303B938.9000602@oracle.com>
Message-ID: <53043AD6.70609@oracle.com>

Vicente.

We need a 8-defer-request label and justification.

Michel

Vicente-Arturo Romero-Zaldivar wrote:
> Hi,
>
> I have filed this bug entry: 
> https://bugs.openjdk.java.net/browse/JDK-8035259, to track this issue.
>
> Thanks,
> Vicente
>
> On 14/02/14 00:02, Alex Buckley wrote:
>> Regression. The scope of class T's declaration is the body of class 
>> Test, including the 'extends' clause of class Two and the body of 
>> class Two. However, the type parameter T declared for class Two 
>> should shadow class T's declaration throughout the 'extends' clause 
>> and body of class Two.
>>
>> Related bug: https://bugs.openjdk.java.net/browse/JDK-7118412.
>>
>> Alex
>>
>> On 2/13/2014 3:28 PM, Liam Miller-Cushon wrote:
>>> The following snippet compiles with javac7, but not javac8-b128.
>>>
>>> Shouldn't the type parameter T be shadowing the inner class Test.T?
>>>
>>> ===
>>> class Test {
>>>    class T<E> {}
>>>    abstract class One<E> {
>>>      abstract E foo();
>>>    }
>>>    abstract class Two<T> extends One<T> {
>>>      abstract T foo();
>>>    }
>>> }
>>> ===
>>>
>>> error: foo() in Test.Two cannot override foo() in Test.One
>>>      abstract T foo();
>>>                 ^
>>>    return type T is not compatible with Test.T
>>>    where T,E are type-variables:
>>>      T extends Object declared in class Test.Two
>>>      E extends Object declared in class Test.One
>

From jan.lahoda at oracle.com  Wed Feb 19 04:34:11 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 19 Feb 2014 13:34:11 +0100
Subject: Queries and patch for JDK-8034854: outer_class_info_index of synthetic
	class is not zero
Message-ID: <5304A4C3.3070202@oracle.com>

Hello,

I have a few questions about JDK-8034854 and a possible patch/fix for 
it. The bug URL:
https://bugs.openjdk.java.net/browse/JDK-8034854

The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute) 
mandates that:
  If a class file has a version number that is greater than or equal to
  51.0, and has an InnerClasses attribute in its attributes table, then
  for all entries in the classes array of the InnerClasses attribute,
  the value of the outer_class_info_index item must be zero if the value
  of the inner_name_index item is zero.
javac in some cases produces non-zero "outer_class_info_index" even if 
"inner_name_index" is zero. This happens for synthetically generated 
auxiliary classes. These classes are generated for a number of reasons, 
for example to be used as tags when accessing private constructors. The 
synthetic classes internally have an empty name, so the generated 
"inner_name_index" is zero, but their owner is a class, so they get the 
non-zero "outer_class_info_index".

I've sketched out a simple fix for this problem, which ensures that 
"outer_class_info_index" is zero for classes that have empty name:
http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/

After this change, the generated synthetic classes look a lot like 
anonymous classes defined in an initializer of the given class (based on 
the InnerClasses attribute and the EnclosingMethod attribute). That 
seems reasonable to me.

My questions are:
-does the fix above make sense?
-the change affects all target levels. It seems to me that the new 
behavior makes sense even for pre-7 classfiles, but I'll gladly limit 
the new behavior to only some minimal target level if desired.

Any comments welcome.

Thanks,
    Jan

From vicente.romero at oracle.com  Wed Feb 19 07:37:28 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Wed, 19 Feb 2014 15:37:28 +0000
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5303CC29.8090909@oracle.com>
References: <5303CC29.8090909@oracle.com>
Message-ID: <5304CFB8.3000703@oracle.com>

Hi Neil,

there is a typo at test/tools/javadoc/6964914/JavacWarning.java:

"It *amy* be deprecated in JDK8"

at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:

I would add the note as an independent comment after the

* @test
* @bug      8004893 8022738

section not as part of it.

Vicente

On 18/02/14 21:10, Neil Toda wrote:
>
> A small set of javadoc tests contain the -source parameter.  In most 
> cases, the parameter is
> not required for the test.  In several cases, the -source parameter is 
> being explicitly tested,
> but relies on a JDK version that will be removed from JDK9.
>
> This changeset removes unnecessary -source specification when not 
> needed, or changes the
> test/source-version requested to one that will work in JDK9.
>
> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>
> Thanks
>
> -neil
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140219/b861ece4/attachment.html 

From alex.buckley at oracle.com  Wed Feb 19 11:13:09 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 19 Feb 2014 11:13:09 -0800
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <5304A4C3.3070202@oracle.com>
References: <5304A4C3.3070202@oracle.com>
Message-ID: <53050245.7090006@oracle.com>

Hi Jan,

The requirement that outer_class_info_index must agree with 
inner_name_index w.r.t. an anonymous class was added in JVMS7 because we 
saw class files where they disagreed and it simply made no sense. The 
requirement was conditioned on 51.0 class files because we didn't want 
to break pre-7 class files with insensible InnerClasses.

The auxiliary classes generated by javac appear to have a meaningful 
"owner" - your word - so it would seem appropriate to have a non-zero 
outer_class_info_index. Just generate a random name for 
inner_name_index. (The 4.7.6 text assumes the "original simple name" can 
be derived from source code, but that's not applicable for synthetic 
classes.) This change could reasonably affect all target levels, since 
no-one should be relying on the value of inner_name_index for these 
auxiliary classes.

OTOH, your proposal to represent the auxiliary classes as true anonymous 
classes in InnerClasses is attractive because it exposes even less 
information than at present. This change could reasonably affect all 
target levels too, since no-one should be relying on the value of 
outer_class_info_index for these auxiliary classes.

Alex

On 2/19/2014 4:34 AM, Jan Lahoda wrote:
> Hello,
>
> I have a few questions about JDK-8034854 and a possible patch/fix for
> it. The bug URL:
> https://bugs.openjdk.java.net/browse/JDK-8034854
>
> The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute)
> mandates that:
>   If a class file has a version number that is greater than or equal to
>   51.0, and has an InnerClasses attribute in its attributes table, then
>   for all entries in the classes array of the InnerClasses attribute,
>   the value of the outer_class_info_index item must be zero if the value
>   of the inner_name_index item is zero.
> javac in some cases produces non-zero "outer_class_info_index" even if
> "inner_name_index" is zero. This happens for synthetically generated
> auxiliary classes. These classes are generated for a number of reasons,
> for example to be used as tags when accessing private constructors. The
> synthetic classes internally have an empty name, so the generated
> "inner_name_index" is zero, but their owner is a class, so they get the
> non-zero "outer_class_info_index".
>
> I've sketched out a simple fix for this problem, which ensures that
> "outer_class_info_index" is zero for classes that have empty name:
> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>
> After this change, the generated synthetic classes look a lot like
> anonymous classes defined in an initializer of the given class (based on
> the InnerClasses attribute and the EnclosingMethod attribute). That
> seems reasonable to me.
>
> My questions are:
> -does the fix above make sense?
> -the change affects all target levels. It seems to me that the new
> behavior makes sense even for pre-7 classfiles, but I'll gladly limit
> the new behavior to only some minimal target level if desired.
>
> Any comments welcome.
>
> Thanks,
>     Jan

From neil.toda at oracle.com  Wed Feb 19 14:53:41 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Wed, 19 Feb 2014 14:53:41 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5304CFB8.3000703@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
Message-ID: <530535F5.20500@oracle.com>


Thanks Vicente.  I've done both.. -neil

On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Neil,
>
> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>
> "It *amy* be deprecated in JDK8"
>
> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>
> I would add the note as an independent comment after the
>
> * @test
> * @bug      8004893 8022738
> section not as part of it.
>
> Vicente
>
> On 18/02/14 21:10, Neil Toda wrote:
>>
>> A small set of javadoc tests contain the -source parameter.  In most 
>> cases, the parameter is
>> not required for the test.  In several cases, the -source parameter 
>> is being explicitly tested,
>> but relies on a JDK version that will be removed from JDK9.
>>
>> This changeset removes unnecessary -source specification when not 
>> needed, or changes the
>> test/source-version requested to one that will work in JDK9.
>>
>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>
>> Thanks
>>
>> -neil
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140219/81d4c1e2/attachment.html 

From joe.darcy at oracle.com  Wed Feb 19 15:42:29 2014
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Wed, 19 Feb 2014 15:42:29 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5304CFB8.3000703@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
Message-ID: <53054165.8080502@oracle.com>

Hi Neil,

On the removal of

     test/tools/javadoc/sourceOption/SourceOption.java

after your patch is there some remaining javadoc test which uses the 
-source option? We probably want to keep one test which uses to the 
option to make sure it is supported. If there is no such remaining test, 
SourceOption.java could be resurrected and make to check that a JDK 8 
feature is rejected under source 7, etc.

Otherwise, the removal of the other -source uses looks fine.

Thanks,

-Joe

On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Neil,
>
> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>
> "It *amy* be deprecated in JDK8"
>
> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>
> I would add the note as an independent comment after the
>
> * @test
> * @bug      8004893 8022738
> section not as part of it.
>
> Vicente
>
> On 18/02/14 21:10, Neil Toda wrote:
>>
>> A small set of javadoc tests contain the -source parameter.  In most 
>> cases, the parameter is
>> not required for the test.  In several cases, the -source parameter 
>> is being explicitly tested,
>> but relies on a JDK version that will be removed from JDK9.
>>
>> This changeset removes unnecessary -source specification when not 
>> needed, or changes the
>> test/source-version requested to one that will work in JDK9.
>>
>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>
>> Thanks
>>
>> -neil
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140219/f27ef68b/attachment.html 

From jan.lahoda at oracle.com  Thu Feb 20 03:11:20 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 20 Feb 2014 12:11:20 +0100
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <53050245.7090006@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
Message-ID: <5305E2D8.9040207@oracle.com>

Hi Alex,

Thanks for the comments.

I was briefly considering filling some inner_name for the synthetic 
classes, but using zeroing outer_class_info_index seemed somewhat 
cleaner, safer (no risk of name clashes or misinterpretation of the 
name) and simpler. But if generating an inner_name for the synthetic 
classes would be (strongly) preferred, I can investigate it.

Jan

On 02/19/2014 08:13 PM, Alex Buckley wrote:
> Hi Jan,
>
> The requirement that outer_class_info_index must agree with
> inner_name_index w.r.t. an anonymous class was added in JVMS7 because we
> saw class files where they disagreed and it simply made no sense. The
> requirement was conditioned on 51.0 class files because we didn't want
> to break pre-7 class files with insensible InnerClasses.
>
> The auxiliary classes generated by javac appear to have a meaningful
> "owner" - your word - so it would seem appropriate to have a non-zero
> outer_class_info_index. Just generate a random name for
> inner_name_index. (The 4.7.6 text assumes the "original simple name" can
> be derived from source code, but that's not applicable for synthetic
> classes.) This change could reasonably affect all target levels, since
> no-one should be relying on the value of inner_name_index for these
> auxiliary classes.
>
> OTOH, your proposal to represent the auxiliary classes as true anonymous
> classes in InnerClasses is attractive because it exposes even less
> information than at present. This change could reasonably affect all
> target levels too, since no-one should be relying on the value of
> outer_class_info_index for these auxiliary classes.
>
> Alex
>
> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>> Hello,
>>
>> I have a few questions about JDK-8034854 and a possible patch/fix for
>> it. The bug URL:
>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>
>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute)
>> mandates that:
>>   If a class file has a version number that is greater than or equal to
>>   51.0, and has an InnerClasses attribute in its attributes table, then
>>   for all entries in the classes array of the InnerClasses attribute,
>>   the value of the outer_class_info_index item must be zero if the value
>>   of the inner_name_index item is zero.
>> javac in some cases produces non-zero "outer_class_info_index" even if
>> "inner_name_index" is zero. This happens for synthetically generated
>> auxiliary classes. These classes are generated for a number of reasons,
>> for example to be used as tags when accessing private constructors. The
>> synthetic classes internally have an empty name, so the generated
>> "inner_name_index" is zero, but their owner is a class, so they get the
>> non-zero "outer_class_info_index".
>>
>> I've sketched out a simple fix for this problem, which ensures that
>> "outer_class_info_index" is zero for classes that have empty name:
>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>
>> After this change, the generated synthetic classes look a lot like
>> anonymous classes defined in an initializer of the given class (based on
>> the InnerClasses attribute and the EnclosingMethod attribute). That
>> seems reasonable to me.
>>
>> My questions are:
>> -does the fix above make sense?
>> -the change affects all target levels. It seems to me that the new
>> behavior makes sense even for pre-7 classfiles, but I'll gladly limit
>> the new behavior to only some minimal target level if desired.
>>
>> Any comments welcome.
>>
>> Thanks,
>>     Jan

From alex.buckley at oracle.com  Thu Feb 20 11:14:11 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 20 Feb 2014 11:14:11 -0800
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <5305E2D8.9040207@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
	<5305E2D8.9040207@oracle.com>
Message-ID: <53065403.4060506@oracle.com>

It would make sense to consider the full range of reasons why these 
auxiliary classes are generated. You indicated one reason - tags for 
accessing private ctors - and it makes sense to generate a "true" 
anonymous class there (outer_class_info_index=0, inner_name_index=0). 
But perhaps other reasons would justify auxiliary classes with 
meaningful "owners" - again, your word - and there it would be sensible 
to consider them as member classes rather than anonymous classes.

Alex

On 2/20/2014 3:11 AM, Jan Lahoda wrote:
> Hi Alex,
>
> Thanks for the comments.
>
> I was briefly considering filling some inner_name for the synthetic
> classes, but using zeroing outer_class_info_index seemed somewhat
> cleaner, safer (no risk of name clashes or misinterpretation of the
> name) and simpler. But if generating an inner_name for the synthetic
> classes would be (strongly) preferred, I can investigate it.
>
> Jan
>
> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>> Hi Jan,
>>
>> The requirement that outer_class_info_index must agree with
>> inner_name_index w.r.t. an anonymous class was added in JVMS7 because we
>> saw class files where they disagreed and it simply made no sense. The
>> requirement was conditioned on 51.0 class files because we didn't want
>> to break pre-7 class files with insensible InnerClasses.
>>
>> The auxiliary classes generated by javac appear to have a meaningful
>> "owner" - your word - so it would seem appropriate to have a non-zero
>> outer_class_info_index. Just generate a random name for
>> inner_name_index. (The 4.7.6 text assumes the "original simple name" can
>> be derived from source code, but that's not applicable for synthetic
>> classes.) This change could reasonably affect all target levels, since
>> no-one should be relying on the value of inner_name_index for these
>> auxiliary classes.
>>
>> OTOH, your proposal to represent the auxiliary classes as true anonymous
>> classes in InnerClasses is attractive because it exposes even less
>> information than at present. This change could reasonably affect all
>> target levels too, since no-one should be relying on the value of
>> outer_class_info_index for these auxiliary classes.
>>
>> Alex
>>
>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>> Hello,
>>>
>>> I have a few questions about JDK-8034854 and a possible patch/fix for
>>> it. The bug URL:
>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>
>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute)
>>> mandates that:
>>>   If a class file has a version number that is greater than or equal to
>>>   51.0, and has an InnerClasses attribute in its attributes table, then
>>>   for all entries in the classes array of the InnerClasses attribute,
>>>   the value of the outer_class_info_index item must be zero if the value
>>>   of the inner_name_index item is zero.
>>> javac in some cases produces non-zero "outer_class_info_index" even if
>>> "inner_name_index" is zero. This happens for synthetically generated
>>> auxiliary classes. These classes are generated for a number of reasons,
>>> for example to be used as tags when accessing private constructors. The
>>> synthetic classes internally have an empty name, so the generated
>>> "inner_name_index" is zero, but their owner is a class, so they get the
>>> non-zero "outer_class_info_index".
>>>
>>> I've sketched out a simple fix for this problem, which ensures that
>>> "outer_class_info_index" is zero for classes that have empty name:
>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>
>>> After this change, the generated synthetic classes look a lot like
>>> anonymous classes defined in an initializer of the given class (based on
>>> the InnerClasses attribute and the EnclosingMethod attribute). That
>>> seems reasonable to me.
>>>
>>> My questions are:
>>> -does the fix above make sense?
>>> -the change affects all target levels. It seems to me that the new
>>> behavior makes sense even for pre-7 classfiles, but I'll gladly limit
>>> the new behavior to only some minimal target level if desired.
>>>
>>> Any comments welcome.
>>>
>>> Thanks,
>>>     Jan

From jan.lahoda at oracle.com  Thu Feb 20 12:34:38 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 20 Feb 2014 21:34:38 +0100
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <53065403.4060506@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
	<5305E2D8.9040207@oracle.com> <53065403.4060506@oracle.com>
Message-ID: <530666DE.30505@oracle.com>

As far as I was able to determine, these are the cases where and why the 
auxiliary classes are generated/used:
-as tags for access constructors for private constructors. An existing 
anonymous innerclass is reused as a tag, if available, otherwise at most 
one class is synthesized per top-level type.
-for target levels whose ldc instruction does not support references to 
classes, desugared code for class literals (a "getter" and cache for the 
Class objects) is placed into a "cache" class. Depending on the 
circumstances, a top-level class or an existing anonymous innerclass is 
reused if possible, otherwise at most one class is synthesized per 
top-level type.
-for switch-over-enum, a lazy map between enum constants and ordinals is 
placed into a cache class. An existing anonymous innerclass is reused, 
if available, otherwise at most one class is synthesized per top-level type.
-for interfaces, to hold their assertions enabled status. At most one 
class is synthesized per top-level type.

Jan

On 02/20/2014 08:14 PM, Alex Buckley wrote:
> It would make sense to consider the full range of reasons why these
> auxiliary classes are generated. You indicated one reason - tags for
> accessing private ctors - and it makes sense to generate a "true"
> anonymous class there (outer_class_info_index=0, inner_name_index=0).
> But perhaps other reasons would justify auxiliary classes with
> meaningful "owners" - again, your word - and there it would be sensible
> to consider them as member classes rather than anonymous classes.
>
> Alex
>
> On 2/20/2014 3:11 AM, Jan Lahoda wrote:
>> Hi Alex,
>>
>> Thanks for the comments.
>>
>> I was briefly considering filling some inner_name for the synthetic
>> classes, but using zeroing outer_class_info_index seemed somewhat
>> cleaner, safer (no risk of name clashes or misinterpretation of the
>> name) and simpler. But if generating an inner_name for the synthetic
>> classes would be (strongly) preferred, I can investigate it.
>>
>> Jan
>>
>> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>>> Hi Jan,
>>>
>>> The requirement that outer_class_info_index must agree with
>>> inner_name_index w.r.t. an anonymous class was added in JVMS7 because we
>>> saw class files where they disagreed and it simply made no sense. The
>>> requirement was conditioned on 51.0 class files because we didn't want
>>> to break pre-7 class files with insensible InnerClasses.
>>>
>>> The auxiliary classes generated by javac appear to have a meaningful
>>> "owner" - your word - so it would seem appropriate to have a non-zero
>>> outer_class_info_index. Just generate a random name for
>>> inner_name_index. (The 4.7.6 text assumes the "original simple name" can
>>> be derived from source code, but that's not applicable for synthetic
>>> classes.) This change could reasonably affect all target levels, since
>>> no-one should be relying on the value of inner_name_index for these
>>> auxiliary classes.
>>>
>>> OTOH, your proposal to represent the auxiliary classes as true anonymous
>>> classes in InnerClasses is attractive because it exposes even less
>>> information than at present. This change could reasonably affect all
>>> target levels too, since no-one should be relying on the value of
>>> outer_class_info_index for these auxiliary classes.
>>>
>>> Alex
>>>
>>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>>> Hello,
>>>>
>>>> I have a few questions about JDK-8034854 and a possible patch/fix for
>>>> it. The bug URL:
>>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>>
>>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute)
>>>> mandates that:
>>>>   If a class file has a version number that is greater than or equal to
>>>>   51.0, and has an InnerClasses attribute in its attributes table, then
>>>>   for all entries in the classes array of the InnerClasses attribute,
>>>>   the value of the outer_class_info_index item must be zero if the
>>>> value
>>>>   of the inner_name_index item is zero.
>>>> javac in some cases produces non-zero "outer_class_info_index" even if
>>>> "inner_name_index" is zero. This happens for synthetically generated
>>>> auxiliary classes. These classes are generated for a number of reasons,
>>>> for example to be used as tags when accessing private constructors. The
>>>> synthetic classes internally have an empty name, so the generated
>>>> "inner_name_index" is zero, but their owner is a class, so they get the
>>>> non-zero "outer_class_info_index".
>>>>
>>>> I've sketched out a simple fix for this problem, which ensures that
>>>> "outer_class_info_index" is zero for classes that have empty name:
>>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>>
>>>> After this change, the generated synthetic classes look a lot like
>>>> anonymous classes defined in an initializer of the given class
>>>> (based on
>>>> the InnerClasses attribute and the EnclosingMethod attribute). That
>>>> seems reasonable to me.
>>>>
>>>> My questions are:
>>>> -does the fix above make sense?
>>>> -the change affects all target levels. It seems to me that the new
>>>> behavior makes sense even for pre-7 classfiles, but I'll gladly limit
>>>> the new behavior to only some minimal target level if desired.
>>>>
>>>> Any comments welcome.
>>>>
>>>> Thanks,
>>>>     Jan

From alex.buckley at oracle.com  Thu Feb 20 13:06:29 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 20 Feb 2014 13:06:29 -0800
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <530666DE.30505@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
	<5305E2D8.9040207@oracle.com> <53065403.4060506@oracle.com>
	<530666DE.30505@oracle.com>
Message-ID: <53066E55.3010500@oracle.com>

Interesting reasons. Does reuse of an existing top-level or anonymous 
class choose from a pool of all classes (inc. user-defined ones) or only 
synthetic classes?

I'm still not clear if "one class is synthesized per top-level type" 
means "one member class" or "one anonymous class". I guess the 
ill-formed answer currently given by javac is "one member-anonymous 
class", because the non-zero outer_class_info_index implies it's a 
member class while the zero inner_name_index implies it's an anonymous 
class - yuk. I recommend making them truly anonymous.

Alex

On 2/20/2014 12:34 PM, Jan Lahoda wrote:
> As far as I was able to determine, these are the cases where and why the
> auxiliary classes are generated/used:
> -as tags for access constructors for private constructors. An existing
> anonymous innerclass is reused as a tag, if available, otherwise at most
> one class is synthesized per top-level type.
> -for target levels whose ldc instruction does not support references to
> classes, desugared code for class literals (a "getter" and cache for the
> Class objects) is placed into a "cache" class. Depending on the
> circumstances, a top-level class or an existing anonymous innerclass is
> reused if possible, otherwise at most one class is synthesized per
> top-level type.
> -for switch-over-enum, a lazy map between enum constants and ordinals is
> placed into a cache class. An existing anonymous innerclass is reused,
> if available, otherwise at most one class is synthesized per top-level
> type.
> -for interfaces, to hold their assertions enabled status. At most one
> class is synthesized per top-level type.
>
> Jan
>
> On 02/20/2014 08:14 PM, Alex Buckley wrote:
>> It would make sense to consider the full range of reasons why these
>> auxiliary classes are generated. You indicated one reason - tags for
>> accessing private ctors - and it makes sense to generate a "true"
>> anonymous class there (outer_class_info_index=0, inner_name_index=0).
>> But perhaps other reasons would justify auxiliary classes with
>> meaningful "owners" - again, your word - and there it would be sensible
>> to consider them as member classes rather than anonymous classes.
>>
>> Alex
>>
>> On 2/20/2014 3:11 AM, Jan Lahoda wrote:
>>> Hi Alex,
>>>
>>> Thanks for the comments.
>>>
>>> I was briefly considering filling some inner_name for the synthetic
>>> classes, but using zeroing outer_class_info_index seemed somewhat
>>> cleaner, safer (no risk of name clashes or misinterpretation of the
>>> name) and simpler. But if generating an inner_name for the synthetic
>>> classes would be (strongly) preferred, I can investigate it.
>>>
>>> Jan
>>>
>>> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>>>> Hi Jan,
>>>>
>>>> The requirement that outer_class_info_index must agree with
>>>> inner_name_index w.r.t. an anonymous class was added in JVMS7
>>>> because we
>>>> saw class files where they disagreed and it simply made no sense. The
>>>> requirement was conditioned on 51.0 class files because we didn't want
>>>> to break pre-7 class files with insensible InnerClasses.
>>>>
>>>> The auxiliary classes generated by javac appear to have a meaningful
>>>> "owner" - your word - so it would seem appropriate to have a non-zero
>>>> outer_class_info_index. Just generate a random name for
>>>> inner_name_index. (The 4.7.6 text assumes the "original simple name"
>>>> can
>>>> be derived from source code, but that's not applicable for synthetic
>>>> classes.) This change could reasonably affect all target levels, since
>>>> no-one should be relying on the value of inner_name_index for these
>>>> auxiliary classes.
>>>>
>>>> OTOH, your proposal to represent the auxiliary classes as true
>>>> anonymous
>>>> classes in InnerClasses is attractive because it exposes even less
>>>> information than at present. This change could reasonably affect all
>>>> target levels too, since no-one should be relying on the value of
>>>> outer_class_info_index for these auxiliary classes.
>>>>
>>>> Alex
>>>>
>>>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>>>> Hello,
>>>>>
>>>>> I have a few questions about JDK-8034854 and a possible patch/fix for
>>>>> it. The bug URL:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>>>
>>>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute)
>>>>> mandates that:
>>>>>   If a class file has a version number that is greater than or
>>>>> equal to
>>>>>   51.0, and has an InnerClasses attribute in its attributes table,
>>>>> then
>>>>>   for all entries in the classes array of the InnerClasses attribute,
>>>>>   the value of the outer_class_info_index item must be zero if the
>>>>> value
>>>>>   of the inner_name_index item is zero.
>>>>> javac in some cases produces non-zero "outer_class_info_index" even if
>>>>> "inner_name_index" is zero. This happens for synthetically generated
>>>>> auxiliary classes. These classes are generated for a number of
>>>>> reasons,
>>>>> for example to be used as tags when accessing private constructors.
>>>>> The
>>>>> synthetic classes internally have an empty name, so the generated
>>>>> "inner_name_index" is zero, but their owner is a class, so they get
>>>>> the
>>>>> non-zero "outer_class_info_index".
>>>>>
>>>>> I've sketched out a simple fix for this problem, which ensures that
>>>>> "outer_class_info_index" is zero for classes that have empty name:
>>>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>>>
>>>>> After this change, the generated synthetic classes look a lot like
>>>>> anonymous classes defined in an initializer of the given class
>>>>> (based on
>>>>> the InnerClasses attribute and the EnclosingMethod attribute). That
>>>>> seems reasonable to me.
>>>>>
>>>>> My questions are:
>>>>> -does the fix above make sense?
>>>>> -the change affects all target levels. It seems to me that the new
>>>>> behavior makes sense even for pre-7 classfiles, but I'll gladly limit
>>>>> the new behavior to only some minimal target level if desired.
>>>>>
>>>>> Any comments welcome.
>>>>>
>>>>> Thanks,
>>>>>     Jan

From neil.toda at oracle.com  Thu Feb 20 17:25:48 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Thu, 20 Feb 2014 17:25:48 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <53054165.8080502@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
	<53054165.8080502@oracle.com>
Message-ID: <5306AB1C.6050309@oracle.com>


There is another test that does a negative check on a feature, 
testLambdaFeature.
However, it too will stop working when support for 1.7 is removed from 
the JDK.
Granted that will be several years from now, but by then we'll all 
forget and just
remove the negative test.

I think I've made a mistake taking out the ./sourceOption test.  It is 
better that this
test exist and be specifically designed to make sure -source is working.

With that in mind, I'll not remove it, and add to it so that we have a 
list of features
in each release that will fail in the next release.  Something like:

Release        Feature
=======        ===================
1.6            List<String> list = ArrayList<String>();
1.7            List<String> list = ArrayList<>();
1.8            Lambda or default methods
1.9            TBD

So for JDK9, the test will specify:
     -source 1.6
     A.java will contain : List<String> list = ArrayList<>();

     and the test will look for failure.

In this way, the intent will by conveyed in the test.

Does this all sound okay?

Thanks Joe

-neil


On 2/19/2014 3:42 PM, Joseph Darcy wrote:
> Hi Neil,
>
> On the removal of
>
>     test/tools/javadoc/sourceOption/SourceOption.java
>
> after your patch is there some remaining javadoc test which uses the 
> -source option? We probably want to keep one test which uses to the 
> option to make sure it is supported. If there is no such remaining 
> test, SourceOption.java could be resurrected and make to check that a 
> JDK 8 feature is rejected under source 7, etc.
>
> Otherwise, the removal of the other -source uses looks fine.
>
> Thanks,
>
> -Joe
>
> On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
>> Hi Neil,
>>
>> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>>
>> "It *amy* be deprecated in JDK8"
>>
>> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>>
>> I would add the note as an independent comment after the
>>
>> * @test
>> * @bug      8004893 8022738
>> section not as part of it.
>>
>> Vicente
>>
>> On 18/02/14 21:10, Neil Toda wrote:
>>>
>>> A small set of javadoc tests contain the -source parameter. In most 
>>> cases, the parameter is
>>> not required for the test.  In several cases, the -source parameter 
>>> is being explicitly tested,
>>> but relies on a JDK version that will be removed from JDK9.
>>>
>>> This changeset removes unnecessary -source specification when not 
>>> needed, or changes the
>>> test/source-version requested to one that will work in JDK9.
>>>
>>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>>
>>> Thanks
>>>
>>> -neil
>>>
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140220/e21bebf3/attachment.html 

From jan.lahoda at oracle.com  Fri Feb 21 08:29:02 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 21 Feb 2014 17:29:02 +0100
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <53066E55.3010500@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
	<5305E2D8.9040207@oracle.com> <53065403.4060506@oracle.com>
	<530666DE.30505@oracle.com> <53066E55.3010500@oracle.com>
Message-ID: <53077ECE.80705@oracle.com>

On 02/20/2014 10:06 PM, Alex Buckley wrote:
> Interesting reasons. Does reuse of an existing top-level or anonymous
> class choose from a pool of all classes (inc. user-defined ones) or only
> synthetic classes?

User-defined anonymous classes are reused for private constructor tags 
if available, but, on a closer look, user-defined anonymous classes 
don't seem to be reused in other cases. User-defined top-level classes 
(if available) appear to be reused for targets <= 1.4 to hold the 
desugared code for class literals.

>
> I'm still not clear if "one class is synthesized per top-level type"
> means "one member class" or "one anonymous class". I guess the

Internally, they look somewhat like a member class with an empty name 
("anonymous member class"). But I don't think the internal 
representation should affect the content of the attributes in this case.

> ill-formed answer currently given by javac is "one member-anonymous
> class", because the non-zero outer_class_info_index implies it's a
> member class while the zero inner_name_index implies it's an anonymous
> class - yuk. I recommend making them truly anonymous.

Thanks.

A webrev that updates tests according to comments received so far:
http://cr.openjdk.java.net/~jlahoda/8034854/webrev.01/

Jan

>
> Alex
>
> On 2/20/2014 12:34 PM, Jan Lahoda wrote:
>> As far as I was able to determine, these are the cases where and why the
>> auxiliary classes are generated/used:
>> -as tags for access constructors for private constructors. An existing
>> anonymous innerclass is reused as a tag, if available, otherwise at most
>> one class is synthesized per top-level type.
>> -for target levels whose ldc instruction does not support references to
>> classes, desugared code for class literals (a "getter" and cache for the
>> Class objects) is placed into a "cache" class. Depending on the
>> circumstances, a top-level class or an existing anonymous innerclass is
>> reused if possible, otherwise at most one class is synthesized per
>> top-level type.
>> -for switch-over-enum, a lazy map between enum constants and ordinals is
>> placed into a cache class. An existing anonymous innerclass is reused,
>> if available, otherwise at most one class is synthesized per top-level
>> type.
>> -for interfaces, to hold their assertions enabled status. At most one
>> class is synthesized per top-level type.
>>
>> Jan
>>
>> On 02/20/2014 08:14 PM, Alex Buckley wrote:
>>> It would make sense to consider the full range of reasons why these
>>> auxiliary classes are generated. You indicated one reason - tags for
>>> accessing private ctors - and it makes sense to generate a "true"
>>> anonymous class there (outer_class_info_index=0, inner_name_index=0).
>>> But perhaps other reasons would justify auxiliary classes with
>>> meaningful "owners" - again, your word - and there it would be sensible
>>> to consider them as member classes rather than anonymous classes.
>>>
>>> Alex
>>>
>>> On 2/20/2014 3:11 AM, Jan Lahoda wrote:
>>>> Hi Alex,
>>>>
>>>> Thanks for the comments.
>>>>
>>>> I was briefly considering filling some inner_name for the synthetic
>>>> classes, but using zeroing outer_class_info_index seemed somewhat
>>>> cleaner, safer (no risk of name clashes or misinterpretation of the
>>>> name) and simpler. But if generating an inner_name for the synthetic
>>>> classes would be (strongly) preferred, I can investigate it.
>>>>
>>>> Jan
>>>>
>>>> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>>>>> Hi Jan,
>>>>>
>>>>> The requirement that outer_class_info_index must agree with
>>>>> inner_name_index w.r.t. an anonymous class was added in JVMS7
>>>>> because we
>>>>> saw class files where they disagreed and it simply made no sense. The
>>>>> requirement was conditioned on 51.0 class files because we didn't want
>>>>> to break pre-7 class files with insensible InnerClasses.
>>>>>
>>>>> The auxiliary classes generated by javac appear to have a meaningful
>>>>> "owner" - your word - so it would seem appropriate to have a non-zero
>>>>> outer_class_info_index. Just generate a random name for
>>>>> inner_name_index. (The 4.7.6 text assumes the "original simple name"
>>>>> can
>>>>> be derived from source code, but that's not applicable for synthetic
>>>>> classes.) This change could reasonably affect all target levels, since
>>>>> no-one should be relying on the value of inner_name_index for these
>>>>> auxiliary classes.
>>>>>
>>>>> OTOH, your proposal to represent the auxiliary classes as true
>>>>> anonymous
>>>>> classes in InnerClasses is attractive because it exposes even less
>>>>> information than at present. This change could reasonably affect all
>>>>> target levels too, since no-one should be relying on the value of
>>>>> outer_class_info_index for these auxiliary classes.
>>>>>
>>>>> Alex
>>>>>
>>>>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have a few questions about JDK-8034854 and a possible patch/fix for
>>>>>> it. The bug URL:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>>>>
>>>>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute)
>>>>>> mandates that:
>>>>>>   If a class file has a version number that is greater than or
>>>>>> equal to
>>>>>>   51.0, and has an InnerClasses attribute in its attributes table,
>>>>>> then
>>>>>>   for all entries in the classes array of the InnerClasses attribute,
>>>>>>   the value of the outer_class_info_index item must be zero if the
>>>>>> value
>>>>>>   of the inner_name_index item is zero.
>>>>>> javac in some cases produces non-zero "outer_class_info_index"
>>>>>> even if
>>>>>> "inner_name_index" is zero. This happens for synthetically generated
>>>>>> auxiliary classes. These classes are generated for a number of
>>>>>> reasons,
>>>>>> for example to be used as tags when accessing private constructors.
>>>>>> The
>>>>>> synthetic classes internally have an empty name, so the generated
>>>>>> "inner_name_index" is zero, but their owner is a class, so they get
>>>>>> the
>>>>>> non-zero "outer_class_info_index".
>>>>>>
>>>>>> I've sketched out a simple fix for this problem, which ensures that
>>>>>> "outer_class_info_index" is zero for classes that have empty name:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>>>>
>>>>>> After this change, the generated synthetic classes look a lot like
>>>>>> anonymous classes defined in an initializer of the given class
>>>>>> (based on
>>>>>> the InnerClasses attribute and the EnclosingMethod attribute). That
>>>>>> seems reasonable to me.
>>>>>>
>>>>>> My questions are:
>>>>>> -does the fix above make sense?
>>>>>> -the change affects all target levels. It seems to me that the new
>>>>>> behavior makes sense even for pre-7 classfiles, but I'll gladly limit
>>>>>> the new behavior to only some minimal target level if desired.
>>>>>>
>>>>>> Any comments welcome.
>>>>>>
>>>>>> Thanks,
>>>>>>     Jan

From vicente.romero at oracle.com  Fri Feb 21 09:34:40 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 21 Feb 2014 17:34:40 +0000
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <53077ECE.80705@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
	<5305E2D8.9040207@oracle.com> <53065403.4060506@oracle.com>
	<530666DE.30505@oracle.com> <53066E55.3010500@oracle.com>
	<53077ECE.80705@oracle.com>
Message-ID: <53078E30.1070907@oracle.com>

On 21/02/14 16:29, Jan Lahoda wrote:
> On 02/20/2014 10:06 PM, Alex Buckley wrote:
>> Interesting reasons. Does reuse of an existing top-level or anonymous
>> class choose from a pool of all classes (inc. user-defined ones) or only
>> synthetic classes?
>
> User-defined anonymous classes are reused for private constructor tags 
> if available, but, on a closer look, user-defined anonymous classes 
> don't seem to be reused in other cases. User-defined top-level classes 
> (if available) appear to be reused for targets <= 1.4 to hold the 
> desugared code for class literals.
>
>>
>> I'm still not clear if "one class is synthesized per top-level type"
>> means "one member class" or "one anonymous class". I guess the
>
> Internally, they look somewhat like a member class with an empty name 
> ("anonymous member class"). But I don't think the internal 
> representation should affect the content of the attributes in this case.
>
>> ill-formed answer currently given by javac is "one member-anonymous
>> class", because the non-zero outer_class_info_index implies it's a
>> member class while the zero inner_name_index implies it's an anonymous
>> class - yuk. I recommend making them truly anonymous.
>
> Thanks.
>
> A webrev that updates tests according to comments received so far:
> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.01/

Hi Jan,

I would modify the proposed test by including all the cases for which 
javac generates synthetic classes, also it would be preferable if the 
test is included in just one file.

Thanks,
Vicente

>
> Jan
>
>>
>> Alex
>>
>> On 2/20/2014 12:34 PM, Jan Lahoda wrote:
>>> As far as I was able to determine, these are the cases where and why 
>>> the
>>> auxiliary classes are generated/used:
>>> -as tags for access constructors for private constructors. An existing
>>> anonymous innerclass is reused as a tag, if available, otherwise at 
>>> most
>>> one class is synthesized per top-level type.
>>> -for target levels whose ldc instruction does not support references to
>>> classes, desugared code for class literals (a "getter" and cache for 
>>> the
>>> Class objects) is placed into a "cache" class. Depending on the
>>> circumstances, a top-level class or an existing anonymous innerclass is
>>> reused if possible, otherwise at most one class is synthesized per
>>> top-level type.
>>> -for switch-over-enum, a lazy map between enum constants and 
>>> ordinals is
>>> placed into a cache class. An existing anonymous innerclass is reused,
>>> if available, otherwise at most one class is synthesized per top-level
>>> type.
>>> -for interfaces, to hold their assertions enabled status. At most one
>>> class is synthesized per top-level type.
>>>
>>> Jan
>>>
>>> On 02/20/2014 08:14 PM, Alex Buckley wrote:
>>>> It would make sense to consider the full range of reasons why these
>>>> auxiliary classes are generated. You indicated one reason - tags for
>>>> accessing private ctors - and it makes sense to generate a "true"
>>>> anonymous class there (outer_class_info_index=0, inner_name_index=0).
>>>> But perhaps other reasons would justify auxiliary classes with
>>>> meaningful "owners" - again, your word - and there it would be 
>>>> sensible
>>>> to consider them as member classes rather than anonymous classes.
>>>>
>>>> Alex
>>>>
>>>> On 2/20/2014 3:11 AM, Jan Lahoda wrote:
>>>>> Hi Alex,
>>>>>
>>>>> Thanks for the comments.
>>>>>
>>>>> I was briefly considering filling some inner_name for the synthetic
>>>>> classes, but using zeroing outer_class_info_index seemed somewhat
>>>>> cleaner, safer (no risk of name clashes or misinterpretation of the
>>>>> name) and simpler. But if generating an inner_name for the synthetic
>>>>> classes would be (strongly) preferred, I can investigate it.
>>>>>
>>>>> Jan
>>>>>
>>>>> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> The requirement that outer_class_info_index must agree with
>>>>>> inner_name_index w.r.t. an anonymous class was added in JVMS7
>>>>>> because we
>>>>>> saw class files where they disagreed and it simply made no sense. 
>>>>>> The
>>>>>> requirement was conditioned on 51.0 class files because we didn't 
>>>>>> want
>>>>>> to break pre-7 class files with insensible InnerClasses.
>>>>>>
>>>>>> The auxiliary classes generated by javac appear to have a meaningful
>>>>>> "owner" - your word - so it would seem appropriate to have a 
>>>>>> non-zero
>>>>>> outer_class_info_index. Just generate a random name for
>>>>>> inner_name_index. (The 4.7.6 text assumes the "original simple name"
>>>>>> can
>>>>>> be derived from source code, but that's not applicable for synthetic
>>>>>> classes.) This change could reasonably affect all target levels, 
>>>>>> since
>>>>>> no-one should be relying on the value of inner_name_index for these
>>>>>> auxiliary classes.
>>>>>>
>>>>>> OTOH, your proposal to represent the auxiliary classes as true
>>>>>> anonymous
>>>>>> classes in InnerClasses is attractive because it exposes even less
>>>>>> information than at present. This change could reasonably affect all
>>>>>> target levels too, since no-one should be relying on the value of
>>>>>> outer_class_info_index for these auxiliary classes.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have a few questions about JDK-8034854 and a possible 
>>>>>>> patch/fix for
>>>>>>> it. The bug URL:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>>>>>
>>>>>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses 
>>>>>>> Attribute)
>>>>>>> mandates that:
>>>>>>>   If a class file has a version number that is greater than or
>>>>>>> equal to
>>>>>>>   51.0, and has an InnerClasses attribute in its attributes table,
>>>>>>> then
>>>>>>>   for all entries in the classes array of the InnerClasses 
>>>>>>> attribute,
>>>>>>>   the value of the outer_class_info_index item must be zero if the
>>>>>>> value
>>>>>>>   of the inner_name_index item is zero.
>>>>>>> javac in some cases produces non-zero "outer_class_info_index"
>>>>>>> even if
>>>>>>> "inner_name_index" is zero. This happens for synthetically 
>>>>>>> generated
>>>>>>> auxiliary classes. These classes are generated for a number of
>>>>>>> reasons,
>>>>>>> for example to be used as tags when accessing private constructors.
>>>>>>> The
>>>>>>> synthetic classes internally have an empty name, so the generated
>>>>>>> "inner_name_index" is zero, but their owner is a class, so they get
>>>>>>> the
>>>>>>> non-zero "outer_class_info_index".
>>>>>>>
>>>>>>> I've sketched out a simple fix for this problem, which ensures that
>>>>>>> "outer_class_info_index" is zero for classes that have empty name:
>>>>>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>>>>>
>>>>>>> After this change, the generated synthetic classes look a lot like
>>>>>>> anonymous classes defined in an initializer of the given class
>>>>>>> (based on
>>>>>>> the InnerClasses attribute and the EnclosingMethod attribute). That
>>>>>>> seems reasonable to me.
>>>>>>>
>>>>>>> My questions are:
>>>>>>> -does the fix above make sense?
>>>>>>> -the change affects all target levels. It seems to me that the new
>>>>>>> behavior makes sense even for pre-7 classfiles, but I'll gladly 
>>>>>>> limit
>>>>>>> the new behavior to only some minimal target level if desired.
>>>>>>>
>>>>>>> Any comments welcome.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>     Jan


From cushon at google.com  Fri Feb 21 11:31:04 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 21 Feb 2014 11:31:04 -0800
Subject: Inference of recursive types
In-Reply-To: <CAL4Qsgv1_eHHfv_VOTgEE3iqCF7hv2wrOJ-b7RyiyN=Wesjabw@mail.gmail.com>
References: <CAL4Qsgv1_eHHfv_VOTgEE3iqCF7hv2wrOJ-b7RyiyN=Wesjabw@mail.gmail.com>
Message-ID: <CAL4QsguZtiC3MB9mbFBUXVssOj6PaEy51Aq52B-vcNE5KSKh3Q@mail.gmail.com>

+lambda-dev

Any thoughts on this?

This affects a significant amount of code, and the fact that it only
appears when compiling java 7 with javac8 makes it look like a regression.

The following is a less contrived example of code with recursive types that
doesn't currently compile with javac8 -source 7 -target 7:

class Test {
  <T extends Enum<T>> T getEnum() { return null; }
  <U extends Enum<U>> void m() {
    U e = getEnum();
  }
}

$ javac -source 7 -target 7 Test.java
Test.java:4: error: incompatible types: inference variable T#1 has
incompatible upper bounds Enum<T#2>,U
    U e = getEnum();
                 ^
  where T#1,T#2,U are type-variables:
    T#1 extends Enum<T#1> declared in method <T#1>getEnum()
    T#2 extends U
    U extends Enum<U> declared in method <U>m()

On Fri, Feb 14, 2014 at 5:07 PM, Liam Miller-Cushon <cushon at google.com>wrote:

> Hi -
>
> Sorry if this has already been discussed, but I ran into a difference in
> behaviour between javac8 -source 7/-target 7 and both javac7 and javac8
> -source 8/-target 8.
>
> The following program compiles with everything except javac8 -source
> 7/-target 7.
>
> Is this an intentional change? Having to make g's type parameter explicit
> feels like a regression.
>
> ===
> class Test {
>   static class One<T> {}
>   static class Two extends One<Two> {}
>
>   <T extends One<T>> T f(T a, String s) {
>     T t = g(s);
>     return t;
>   }
>   static <U extends One<U>> U g(String s) {
>     throw new RuntimeException();
>   }
> }
> ===
>
> Test.java:6: error: incompatible types: inference variable U#1 has
> incompatible upper bounds One<U#2>,T
>     T t = g(s);
>            ^
>   where U#1,U#2,T are type-variables:
>     U#1 extends One<U#1> declared in method <U#1>g(String)
>     U#2 extends T
>     T extends One<T> declared in method <T>f(T,String)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140221/07d8273c/attachment.html 

From vicente.romero at oracle.com  Fri Feb 21 12:53:21 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 21 Feb 2014 20:53:21 +0000
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5306AB1C.6050309@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
	<53054165.8080502@oracle.com> <5306AB1C.6050309@oracle.com>
Message-ID: <5307BCC1.2050109@oracle.com>

Hi Neil,

On 21/02/14 01:25, Neil Toda wrote:
>
> There is another test that does a negative check on a feature, 
> testLambdaFeature.
> However, it too will stop working when support for 1.7 is removed from 
> the JDK.
> Granted that will be several years from now, but by then we'll all 
> forget and just
> remove the negative test.

I hope that we won't ever remove negative tests just because they fail.

>
> I think I've made a mistake taking out the ./sourceOption test. It is 
> better that this
> test exist and be specifically designed to make sure -source is working.

Agree.

>
> With that in mind, I'll not remove it, and add to it so that we have a 
> list of features
> in each release that will fail in the next release.  Something like:
>
> Release        Feature
> =======        ===================
> 1.6            List<String> list = ArrayList<String>();
> 1.7            List<String> list = ArrayList<>();
> 1.8            Lambda or default methods
> 1.9            TBD
>
> So for JDK9, the test will specify:
>     -source 1.6
>     A.java will contain : List<String> list = ArrayList<>();
>
>     and the test will look for failure.
>
> In this way, the intent will by conveyed in the test.
>
> Does this all sound okay?

I would prefer to see the proposed change, I'm not sure I fully 
understand what you want to do here.

Thanks,
Vicente
>
> Thanks Joe
>
> -neil
>
>
> On 2/19/2014 3:42 PM, Joseph Darcy wrote:
>> Hi Neil,
>>
>> On the removal of
>>
>>     test/tools/javadoc/sourceOption/SourceOption.java
>>
>> after your patch is there some remaining javadoc test which uses the 
>> -source option? We probably want to keep one test which uses to the 
>> option to make sure it is supported. If there is no such remaining 
>> test, SourceOption.java could be resurrected and make to check that a 
>> JDK 8 feature is rejected under source 7, etc.
>>
>> Otherwise, the removal of the other -source uses looks fine.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>> Hi Neil,
>>>
>>> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>>>
>>> "It *amy* be deprecated in JDK8"
>>>
>>> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>>>
>>> I would add the note as an independent comment after the
>>>
>>> * @test
>>> * @bug      8004893 8022738
>>> section not as part of it.
>>>
>>> Vicente
>>>
>>> On 18/02/14 21:10, Neil Toda wrote:
>>>>
>>>> A small set of javadoc tests contain the -source parameter. In most 
>>>> cases, the parameter is
>>>> not required for the test.  In several cases, the -source parameter 
>>>> is being explicitly tested,
>>>> but relies on a JDK version that will be removed from JDK9.
>>>>
>>>> This changeset removes unnecessary -source specification when not 
>>>> needed, or changes the
>>>> test/source-version requested to one that will work in JDK9.
>>>>
>>>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>>>
>>>> Thanks
>>>>
>>>> -neil
>>>>
>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140221/087335e8/attachment.html 

From vicente.romero at oracle.com  Fri Feb 21 13:02:44 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Fri, 21 Feb 2014 21:02:44 +0000
Subject: Inference of recursive types
In-Reply-To: <CAL4QsguZtiC3MB9mbFBUXVssOj6PaEy51Aq52B-vcNE5KSKh3Q@mail.gmail.com>
References: <CAL4Qsgv1_eHHfv_VOTgEE3iqCF7hv2wrOJ-b7RyiyN=Wesjabw@mail.gmail.com>
	<CAL4QsguZtiC3MB9mbFBUXVssOj6PaEy51Aq52B-vcNE5KSKh3Q@mail.gmail.com>
Message-ID: <5307BEF4.1060603@oracle.com>

On 21/02/14 19:31, Liam Miller-Cushon wrote:
> +lambda-dev
>
> Any thoughts on this?

Hi Liam,

I will look at this and get back to you. The fact that something is 
working find in 7 and not in 8 source 7 doesn't imply that there is a 
regression in the compiler. It can be a bug in 7 that we don't have to 
reproduce in 8 just to keep the compatibility. Every case is different 
and this could be a regression.

Thanks,
Vicente

>
> This affects a significant amount of code, and the fact that it only
> appears when compiling java 7 with javac8 makes it look like a regression.
>
> The following is a less contrived example of code with recursive types that
> doesn't currently compile with javac8 -source 7 -target 7:
>
> class Test {
>    <T extends Enum<T>> T getEnum() { return null; }
>    <U extends Enum<U>> void m() {
>      U e = getEnum();
>    }
> }
>
> $ javac -source 7 -target 7 Test.java
> Test.java:4: error: incompatible types: inference variable T#1 has
> incompatible upper bounds Enum<T#2>,U
>      U e = getEnum();
>                   ^
>    where T#1,T#2,U are type-variables:
>      T#1 extends Enum<T#1> declared in method <T#1>getEnum()
>      T#2 extends U
>      U extends Enum<U> declared in method <U>m()
>
> On Fri, Feb 14, 2014 at 5:07 PM, Liam Miller-Cushon <cushon at google.com>wrote:
>
>> Hi -
>>
>> Sorry if this has already been discussed, but I ran into a difference in
>> behaviour between javac8 -source 7/-target 7 and both javac7 and javac8
>> -source 8/-target 8.
>>
>> The following program compiles with everything except javac8 -source
>> 7/-target 7.
>>
>> Is this an intentional change? Having to make g's type parameter explicit
>> feels like a regression.
>>
>> ===
>> class Test {
>>    static class One<T> {}
>>    static class Two extends One<Two> {}
>>
>>    <T extends One<T>> T f(T a, String s) {
>>      T t = g(s);
>>      return t;
>>    }
>>    static <U extends One<U>> U g(String s) {
>>      throw new RuntimeException();
>>    }
>> }
>> ===
>>
>> Test.java:6: error: incompatible types: inference variable U#1 has
>> incompatible upper bounds One<U#2>,T
>>      T t = g(s);
>>             ^
>>    where U#1,U#2,T are type-variables:
>>      U#1 extends One<U#1> declared in method <U#1>g(String)
>>      U#2 extends T
>>      T extends One<T> declared in method <T>f(T,String)
>>


From cushon at google.com  Fri Feb 21 13:09:59 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 21 Feb 2014 13:09:59 -0800
Subject: Inference of recursive types
In-Reply-To: <5307BEF4.1060603@oracle.com>
References: <CAL4Qsgv1_eHHfv_VOTgEE3iqCF7hv2wrOJ-b7RyiyN=Wesjabw@mail.gmail.com>
	<CAL4QsguZtiC3MB9mbFBUXVssOj6PaEy51Aq52B-vcNE5KSKh3Q@mail.gmail.com>
	<5307BEF4.1060603@oracle.com>
Message-ID: <CAL4Qsgu2o5EvyOP0ajkLnDZC4r1CGrEYu2JOH-kAgquuMJQLOQ@mail.gmail.com>

I was surprised that it starts working again with javac 8 source 8, but I
appreciate that it may not be a regression. Thanks for investigating.

Liam


On Fri, Feb 21, 2014 at 1:02 PM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

> On 21/02/14 19:31, Liam Miller-Cushon wrote:
>
>> +lambda-dev
>>
>> Any thoughts on this?
>>
>
> Hi Liam,
>
> I will look at this and get back to you. The fact that something is
> working find in 7 and not in 8 source 7 doesn't imply that there is a
> regression in the compiler. It can be a bug in 7 that we don't have to
> reproduce in 8 just to keep the compatibility. Every case is different and
> this could be a regression.
>
> Thanks,
> Vicente
>
>
>
>> This affects a significant amount of code, and the fact that it only
>> appears when compiling java 7 with javac8 makes it look like a regression.
>>
>> The following is a less contrived example of code with recursive types
>> that
>> doesn't currently compile with javac8 -source 7 -target 7:
>>
>> class Test {
>>    <T extends Enum<T>> T getEnum() { return null; }
>>    <U extends Enum<U>> void m() {
>>      U e = getEnum();
>>    }
>> }
>>
>> $ javac -source 7 -target 7 Test.java
>> Test.java:4: error: incompatible types: inference variable T#1 has
>> incompatible upper bounds Enum<T#2>,U
>>      U e = getEnum();
>>                   ^
>>    where T#1,T#2,U are type-variables:
>>      T#1 extends Enum<T#1> declared in method <T#1>getEnum()
>>      T#2 extends U
>>      U extends Enum<U> declared in method <U>m()
>>
>> On Fri, Feb 14, 2014 at 5:07 PM, Liam Miller-Cushon <cushon at google.com
>> >wrote:
>>
>>  Hi -
>>>
>>> Sorry if this has already been discussed, but I ran into a difference in
>>> behaviour between javac8 -source 7/-target 7 and both javac7 and javac8
>>> -source 8/-target 8.
>>>
>>> The following program compiles with everything except javac8 -source
>>> 7/-target 7.
>>>
>>> Is this an intentional change? Having to make g's type parameter explicit
>>> feels like a regression.
>>>
>>> ===
>>> class Test {
>>>    static class One<T> {}
>>>    static class Two extends One<Two> {}
>>>
>>>    <T extends One<T>> T f(T a, String s) {
>>>      T t = g(s);
>>>      return t;
>>>    }
>>>    static <U extends One<U>> U g(String s) {
>>>      throw new RuntimeException();
>>>    }
>>> }
>>> ===
>>>
>>> Test.java:6: error: incompatible types: inference variable U#1 has
>>> incompatible upper bounds One<U#2>,T
>>>      T t = g(s);
>>>             ^
>>>    where U#1,U#2,T are type-variables:
>>>      U#1 extends One<U#1> declared in method <U#1>g(String)
>>>      U#2 extends T
>>>      T extends One<T> declared in method <T>f(T,String)
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140221/2270b4b4/attachment.html 

From neil.toda at oracle.com  Fri Feb 21 13:28:28 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Fri, 21 Feb 2014 13:28:28 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5307BCC1.2050109@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
	<53054165.8080502@oracle.com> <5306AB1C.6050309@oracle.com>
	<5307BCC1.2050109@oracle.com>
Message-ID: <5307C4FC.5050605@oracle.com>



Hi Vicente..  some additional thoughts/comments below...

On 2/21/2014 12:53 PM, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Neil,
>
> On 21/02/14 01:25, Neil Toda wrote:
>>
>> There is another test that does a negative check on a feature, 
>> testLambdaFeature.
>> However, it too will stop working when support for 1.7 is removed 
>> from the JDK.
>> Granted that will be several years from now, but by then we'll all 
>> forget and just
>> remove the negative test.
>
> I hope that we won't ever remove negative tests just because they fail.
>

This test has two parts.  The first checks to see that lambda is recognized.
The second part checks that if the version supplied via -source does not 
support
lambda, the case is correctly handled.

When 1.7 is no longer supported in the JDK, then specifying "-source 
1.7" will not be
valid.  At that point, all supported versions will support lambda.

So I mean that in that case, the second part of the test is no longer 
needed nor valid.


>>
>> I think I've made a mistake taking out the ./sourceOption test. It is 
>> better that this
>> test exist and be specifically designed to make sure -source is working.
>
> Agree.

So, below when you say you'd like to see the proposed change, you are 
referring to statement
about leaving ./sourceOption in?  I'm just suggesting that my note below 
be added to ./sourceOption
in the form of comment giving guidance for future releases, when 1.6, 
then 1.7 is no longer supported.

-neil

>
>>
>> With that in mind, I'll not remove it, and add to it so that we have 
>> a list of features
>> in each release that will fail in the next release.  Something like:
>>
>> Release        Feature
>> =======        ===================
>> 1.6            List<String> list = ArrayList<String>();
>> 1.7            List<String> list = ArrayList<>();
>> 1.8            Lambda or default methods
>> 1.9            TBD
>>
>> So for JDK9, the test will specify:
>>     -source 1.6
>>     A.java will contain : List<String> list = ArrayList<>();
>>
>>     and the test will look for failure.
>>
>> In this way, the intent will by conveyed in the test.
>>
>> Does this all sound okay?
>
> I would prefer to see the proposed change, I'm not sure I fully 
> understand what you want to do here.
>
> Thanks,
> Vicente
>>
>> Thanks Joe
>>
>> -neil
>>
>>
>> On 2/19/2014 3:42 PM, Joseph Darcy wrote:
>>> Hi Neil,
>>>
>>> On the removal of
>>>
>>>     test/tools/javadoc/sourceOption/SourceOption.java
>>>
>>> after your patch is there some remaining javadoc test which uses the 
>>> -source option? We probably want to keep one test which uses to the 
>>> option to make sure it is supported. If there is no such remaining 
>>> test, SourceOption.java could be resurrected and make to check that 
>>> a JDK 8 feature is rejected under source 7, etc.
>>>
>>> Otherwise, the removal of the other -source uses looks fine.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>>> Hi Neil,
>>>>
>>>> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>>>>
>>>> "It *amy* be deprecated in JDK8"
>>>>
>>>> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>>>>
>>>> I would add the note as an independent comment after the
>>>>
>>>> * @test
>>>> * @bug      8004893 8022738
>>>> section not as part of it.
>>>>
>>>> Vicente
>>>>
>>>> On 18/02/14 21:10, Neil Toda wrote:
>>>>>
>>>>> A small set of javadoc tests contain the -source parameter.  In 
>>>>> most cases, the parameter is
>>>>> not required for the test.  In several cases, the -source 
>>>>> parameter is being explicitly tested,
>>>>> but relies on a JDK version that will be removed from JDK9.
>>>>>
>>>>> This changeset removes unnecessary -source specification when not 
>>>>> needed, or changes the
>>>>> test/source-version requested to one that will work in JDK9.
>>>>>
>>>>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>>>>
>>>>> Thanks
>>>>>
>>>>> -neil
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140221/fa7042c5/attachment-0001.html 

From joe.darcy at oracle.com  Fri Feb 21 15:19:20 2014
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 21 Feb 2014 15:19:20 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5307C4FC.5050605@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
	<53054165.8080502@oracle.com> <5306AB1C.6050309@oracle.com>
	<5307BCC1.2050109@oracle.com> <5307C4FC.5050605@oracle.com>
Message-ID: <5307DEF8.1000306@oracle.com>


On 2/21/2014 1:28 PM, Neil Toda wrote:
>
>
> Hi Vicente..  some additional thoughts/comments below...
>
> On 2/21/2014 12:53 PM, Vicente-Arturo Romero-Zaldivar wrote:
>> Hi Neil,
>>
>> On 21/02/14 01:25, Neil Toda wrote:
>>>
>>> There is another test that does a negative check on a feature, 
>>> testLambdaFeature.
>>> However, it too will stop working when support for 1.7 is removed 
>>> from the JDK.
>>> Granted that will be several years from now, but by then we'll all 
>>> forget and just
>>> remove the negative test.
>>
>> I hope that we won't ever remove negative tests just because they fail.
>>
>
> This test has two parts.  The first checks to see that lambda is 
> recognized.
> The second part checks that if the version supplied via -source does 
> not support
> lambda, the case is correctly handled.
>
> When 1.7 is no longer supported in the JDK, then specifying "-source 
> 1.7" will not be
> valid.  At that point, all supported versions will support lambda.
>
> So I mean that in that case, the second part of the test is no longer 
> needed nor valid.
>
>
>>>
>>> I think I've made a mistake taking out the ./sourceOption test.  It 
>>> is better that this
>>> test exist and be specifically designed to make sure -source is working.
>>
>> Agree.
>
> So, below when you say you'd like to see the proposed change, you are 
> referring to statement
> about leaving ./sourceOption in?  I'm just suggesting that my note 
> below be added to ./sourceOption
> in the form of comment giving guidance for future releases, when 1.6, 
> then 1.7 is no longer supported.
>

As a general comment, with the new policy on managing -source / -target 
options, one of the new start of release tasks will be cleaning out 
stale uses of the source/target value that is going to be dropped in the 
next release. (Since JDK 9 is the first full implementation of this 
policy, we have more work to do this time priming the pump.)


-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140221/8f97da8e/attachment.html 

From jonathan.gibbons at oracle.com  Fri Feb 21 18:06:55 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 21 Feb 2014 18:06:55 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5304CFB8.3000703@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
Message-ID: <5308063F.2070006@oracle.com>


On 02/19/2014 07:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
>
> I would add the note as an independent comment after the
>
> * @test
> * @bug      8004893 8022738
> section not as part of it.
>
> Vicente

Strongly agree.  The test description block is a structured block that 
is parsed by jtreg. It should not contain arbitrary comment text.   In 
particular, it should begin with @test, and not have any comment text 
before it.

-- Jon

From vicente.romero at oracle.com  Mon Feb 24 05:51:29 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 24 Feb 2014 13:51:29 +0000
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <5307C4FC.5050605@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
	<53054165.8080502@oracle.com> <5306AB1C.6050309@oracle.com>
	<5307BCC1.2050109@oracle.com> <5307C4FC.5050605@oracle.com>
Message-ID: <530B4E61.9000404@oracle.com>

Hi Neil,

Some comments below.

On 21/02/14 21:28, Neil Toda wrote:
>
>
> Hi Vicente..  some additional thoughts/comments below...
>
> On 2/21/2014 12:53 PM, Vicente-Arturo Romero-Zaldivar wrote:
>> Hi Neil,
>>
>> On 21/02/14 01:25, Neil Toda wrote:
>>>
>>> There is another test that does a negative check on a feature, 
>>> testLambdaFeature.
>>> However, it too will stop working when support for 1.7 is removed 
>>> from the JDK.
>>> Granted that will be several years from now, but by then we'll all 
>>> forget and just
>>> remove the negative test.
>>
>> I hope that we won't ever remove negative tests just because they fail.
>>
>
> This test has two parts.  The first checks to see that lambda is 
> recognized.
> The second part checks that if the version supplied via -source does 
> not support
> lambda, the case is correctly handled.
>
> When 1.7 is no longer supported in the JDK, then specifying "-source 
> 1.7" will not be
> valid.  At that point, all supported versions will support lambda.

I would create a task in JBS, something like, update source option in 
tests where you can add the comments of what needs to be done and what 
tests will need to be modified. Then add a comment in all affected tests 
referring to this JBS entry, see for example: 
https://bugs.openjdk.java.net/browse/JDK-8006694 and the associated 
changeset. This way we won't forget all your findings.



>
> So I mean that in that case, the second part of the test is no longer 
> needed nor valid.
>
>
>>>
>>> I think I've made a mistake taking out the ./sourceOption test.  It 
>>> is better that this
>>> test exist and be specifically designed to make sure -source is working.
>>
>> Agree.
>
> So, below when you say you'd like to see the proposed change, you are 
> referring to statement
> about leaving ./sourceOption in?  I'm just suggesting that my note 
> below be added to ./sourceOption
> in the form of comment giving guidance for future releases, when 1.6, 
> then 1.7 is no longer supported.

OK, I agree.

>
> -neil

- Vicente

>
>>
>>>
>>> With that in mind, I'll not remove it, and add to it so that we have 
>>> a list of features
>>> in each release that will fail in the next release.  Something like:
>>>
>>> Release        Feature
>>> =======        ===================
>>> 1.6            List<String> list = ArrayList<String>();
>>> 1.7            List<String> list = ArrayList<>();
>>> 1.8            Lambda or default methods
>>> 1.9            TBD
>>>
>>> So for JDK9, the test will specify:
>>>     -source 1.6
>>>     A.java will contain : List<String> list = ArrayList<>();
>>>
>>>     and the test will look for failure.
>>>
>>> In this way, the intent will by conveyed in the test.
>>>
>>> Does this all sound okay?
>>
>> I would prefer to see the proposed change, I'm not sure I fully 
>> understand what you want to do here.
>>
>> Thanks,
>> Vicente
>>>
>>> Thanks Joe
>>>
>>> -neil
>>>
>>>
>>> On 2/19/2014 3:42 PM, Joseph Darcy wrote:
>>>> Hi Neil,
>>>>
>>>> On the removal of
>>>>
>>>>     test/tools/javadoc/sourceOption/SourceOption.java
>>>>
>>>> after your patch is there some remaining javadoc test which uses 
>>>> the -source option? We probably want to keep one test which uses to 
>>>> the option to make sure it is supported. If there is no such 
>>>> remaining test, SourceOption.java could be resurrected and make to 
>>>> check that a JDK 8 feature is rejected under source 7, etc.
>>>>
>>>> Otherwise, the removal of the other -source uses looks fine.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>>>> Hi Neil,
>>>>>
>>>>> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>>>>>
>>>>> "It *amy* be deprecated in JDK8"
>>>>>
>>>>> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>>>>>
>>>>> I would add the note as an independent comment after the
>>>>>
>>>>> * @test
>>>>> * @bug      8004893 8022738
>>>>> section not as part of it.
>>>>>
>>>>> Vicente
>>>>>
>>>>> On 18/02/14 21:10, Neil Toda wrote:
>>>>>>
>>>>>> A small set of javadoc tests contain the -source parameter.  In 
>>>>>> most cases, the parameter is
>>>>>> not required for the test.  In several cases, the -source 
>>>>>> parameter is being explicitly tested,
>>>>>> but relies on a JDK version that will be removed from JDK9.
>>>>>>
>>>>>> This changeset removes unnecessary -source specification when not 
>>>>>> needed, or changes the
>>>>>> test/source-version requested to one that will work in JDK9.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -neil
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140224/7f396e09/attachment.html 

From neil.toda at oracle.com  Mon Feb 24 08:04:44 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Mon, 24 Feb 2014 08:04:44 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <530B4E61.9000404@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
	<53054165.8080502@oracle.com> <5306AB1C.6050309@oracle.com>
	<5307BCC1.2050109@oracle.com> <5307C4FC.5050605@oracle.com>
	<530B4E61.9000404@oracle.com>
Message-ID: <530B6D9C.5020406@oracle.com>


Thanks Vicente.  I like that idea of adding to JBS flagging future 
required changes.

-neil

On 2/24/2014 5:51 AM, Vicente-Arturo Romero-Zaldivar wrote:
> Hi Neil,
>
> Some comments below.
>
> On 21/02/14 21:28, Neil Toda wrote:
>>
>>
>> Hi Vicente..  some additional thoughts/comments below...
>>
>> On 2/21/2014 12:53 PM, Vicente-Arturo Romero-Zaldivar wrote:
>>> Hi Neil,
>>>
>>> On 21/02/14 01:25, Neil Toda wrote:
>>>>
>>>> There is another test that does a negative check on a feature, 
>>>> testLambdaFeature.
>>>> However, it too will stop working when support for 1.7 is removed 
>>>> from the JDK.
>>>> Granted that will be several years from now, but by then we'll all 
>>>> forget and just
>>>> remove the negative test.
>>>
>>> I hope that we won't ever remove negative tests just because they fail.
>>>
>>
>> This test has two parts.  The first checks to see that lambda is 
>> recognized.
>> The second part checks that if the version supplied via -source does 
>> not support
>> lambda, the case is correctly handled.
>>
>> When 1.7 is no longer supported in the JDK, then specifying "-source 
>> 1.7" will not be
>> valid.  At that point, all supported versions will support lambda.
>
> I would create a task in JBS, something like, update source option in 
> tests where you can add the comments of what needs to be done and what 
> tests will need to be modified. Then add a comment in all affected 
> tests referring to this JBS entry, see for example: 
> https://bugs.openjdk.java.net/browse/JDK-8006694 and the associated 
> changeset. This way we won't forget all your findings.
>
>
>
>>
>> So I mean that in that case, the second part of the test is no longer 
>> needed nor valid.
>>
>>
>>>>
>>>> I think I've made a mistake taking out the ./sourceOption test.  It 
>>>> is better that this
>>>> test exist and be specifically designed to make sure -source is 
>>>> working.
>>>
>>> Agree.
>>
>> So, below when you say you'd like to see the proposed change, you are 
>> referring to statement
>> about leaving ./sourceOption in?  I'm just suggesting that my note 
>> below be added to ./sourceOption
>> in the form of comment giving guidance for future releases, when 1.6, 
>> then 1.7 is no longer supported.
>
> OK, I agree.
>
>>
>> -neil
>
> - Vicente
>
>>
>>>
>>>>
>>>> With that in mind, I'll not remove it, and add to it so that we 
>>>> have a list of features
>>>> in each release that will fail in the next release. Something like:
>>>>
>>>> Release        Feature
>>>> =======        ===================
>>>> 1.6            List<String> list = ArrayList<String>();
>>>> 1.7            List<String> list = ArrayList<>();
>>>> 1.8            Lambda or default methods
>>>> 1.9            TBD
>>>>
>>>> So for JDK9, the test will specify:
>>>>     -source 1.6
>>>>     A.java will contain : List<String> list = ArrayList<>();
>>>>
>>>>     and the test will look for failure.
>>>>
>>>> In this way, the intent will by conveyed in the test.
>>>>
>>>> Does this all sound okay?
>>>
>>> I would prefer to see the proposed change, I'm not sure I fully 
>>> understand what you want to do here.
>>>
>>> Thanks,
>>> Vicente
>>>>
>>>> Thanks Joe
>>>>
>>>> -neil
>>>>
>>>>
>>>> On 2/19/2014 3:42 PM, Joseph Darcy wrote:
>>>>> Hi Neil,
>>>>>
>>>>> On the removal of
>>>>>
>>>>>     test/tools/javadoc/sourceOption/SourceOption.java
>>>>>
>>>>> after your patch is there some remaining javadoc test which uses 
>>>>> the -source option? We probably want to keep one test which uses 
>>>>> to the option to make sure it is supported. If there is no such 
>>>>> remaining test, SourceOption.java could be resurrected and make to 
>>>>> check that a JDK 8 feature is rejected under source 7, etc.
>>>>>
>>>>> Otherwise, the removal of the other -source uses looks fine.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>>>>> Hi Neil,
>>>>>>
>>>>>> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>>>>>>
>>>>>> "It *amy* be deprecated in JDK8"
>>>>>>
>>>>>> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>>>>>>
>>>>>> I would add the note as an independent comment after the
>>>>>>
>>>>>> * @test
>>>>>> * @bug      8004893 8022738
>>>>>> section not as part of it.
>>>>>>
>>>>>> Vicente
>>>>>>
>>>>>> On 18/02/14 21:10, Neil Toda wrote:
>>>>>>>
>>>>>>> A small set of javadoc tests contain the -source parameter.  In 
>>>>>>> most cases, the parameter is
>>>>>>> not required for the test.  In several cases, the -source 
>>>>>>> parameter is being explicitly tested,
>>>>>>> but relies on a JDK version that will be removed from JDK9.
>>>>>>>
>>>>>>> This changeset removes unnecessary -source specification when 
>>>>>>> not needed, or changes the
>>>>>>> test/source-version requested to one that will work in JDK9.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -neil
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140224/9cfa3d4f/attachment-0001.html 

From joe.darcy at oracle.com  Mon Feb 24 09:12:46 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 24 Feb 2014 09:12:46 -0800
Subject: Review Request : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <530B6D9C.5020406@oracle.com>
References: <5303CC29.8090909@oracle.com> <5304CFB8.3000703@oracle.com>
	<53054165.8080502@oracle.com> <5306AB1C.6050309@oracle.com>
	<5307BCC1.2050109@oracle.com> <5307C4FC.5050605@oracle.com>
	<530B4E61.9000404@oracle.com> <530B6D9C.5020406@oracle.com>
Message-ID: <530B7D8E.5030104@oracle.com>

FWIW, I've already filed several bugs against JDK 10 for exactly that 
purpose, recording some of the details of the version update from 8 -> 9 
so we don't have to rediscover all those details going from 9 -> 10.

-Joe

On 02/24/2014 08:04 AM, Neil Toda wrote:
>
> Thanks Vicente.  I like that idea of adding to JBS flagging future 
> required changes.
>
> -neil
>
> On 2/24/2014 5:51 AM, Vicente-Arturo Romero-Zaldivar wrote:
>> Hi Neil,
>>
>> Some comments below.
>>
>> On 21/02/14 21:28, Neil Toda wrote:
>>>
>>>
>>> Hi Vicente..  some additional thoughts/comments below...
>>>
>>> On 2/21/2014 12:53 PM, Vicente-Arturo Romero-Zaldivar wrote:
>>>> Hi Neil,
>>>>
>>>> On 21/02/14 01:25, Neil Toda wrote:
>>>>>
>>>>> There is another test that does a negative check on a feature, 
>>>>> testLambdaFeature.
>>>>> However, it too will stop working when support for 1.7 is removed 
>>>>> from the JDK.
>>>>> Granted that will be several years from now, but by then we'll all 
>>>>> forget and just
>>>>> remove the negative test.
>>>>
>>>> I hope that we won't ever remove negative tests just because they fail.
>>>>
>>>
>>> This test has two parts.  The first checks to see that lambda is 
>>> recognized.
>>> The second part checks that if the version supplied via -source does 
>>> not support
>>> lambda, the case is correctly handled.
>>>
>>> When 1.7 is no longer supported in the JDK, then specifying "-source 
>>> 1.7" will not be
>>> valid.  At that point, all supported versions will support lambda.
>>
>> I would create a task in JBS, something like, update source option in 
>> tests where you can add the comments of what needs to be done and 
>> what tests will need to be modified. Then add a comment in all 
>> affected tests referring to this JBS entry, see for example: 
>> https://bugs.openjdk.java.net/browse/JDK-8006694 and the associated 
>> changeset. This way we won't forget all your findings.
>>
>>
>>
>>>
>>> So I mean that in that case, the second part of the test is no 
>>> longer needed nor valid.
>>>
>>>
>>>>>
>>>>> I think I've made a mistake taking out the ./sourceOption test.  
>>>>> It is better that this
>>>>> test exist and be specifically designed to make sure -source is 
>>>>> working.
>>>>
>>>> Agree.
>>>
>>> So, below when you say you'd like to see the proposed change, you 
>>> are referring to statement
>>> about leaving ./sourceOption in?  I'm just suggesting that my note 
>>> below be added to ./sourceOption
>>> in the form of comment giving guidance for future releases, when 
>>> 1.6, then 1.7 is no longer supported.
>>
>> OK, I agree.
>>
>>>
>>> -neil
>>
>> - Vicente
>>
>>>
>>>>
>>>>>
>>>>> With that in mind, I'll not remove it, and add to it so that we 
>>>>> have a list of features
>>>>> in each release that will fail in the next release. Something like:
>>>>>
>>>>> Release        Feature
>>>>> =======        ===================
>>>>> 1.6            List<String> list = ArrayList<String>();
>>>>> 1.7            List<String> list = ArrayList<>();
>>>>> 1.8            Lambda or default methods
>>>>> 1.9            TBD
>>>>>
>>>>> So for JDK9, the test will specify:
>>>>>     -source 1.6
>>>>>     A.java will contain : List<String> list = ArrayList<>();
>>>>>
>>>>>     and the test will look for failure.
>>>>>
>>>>> In this way, the intent will by conveyed in the test.
>>>>>
>>>>> Does this all sound okay?
>>>>
>>>> I would prefer to see the proposed change, I'm not sure I fully 
>>>> understand what you want to do here.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>>
>>>>> Thanks Joe
>>>>>
>>>>> -neil
>>>>>
>>>>>
>>>>> On 2/19/2014 3:42 PM, Joseph Darcy wrote:
>>>>>> Hi Neil,
>>>>>>
>>>>>> On the removal of
>>>>>>
>>>>>>     test/tools/javadoc/sourceOption/SourceOption.java
>>>>>>
>>>>>> after your patch is there some remaining javadoc test which uses 
>>>>>> the -source option? We probably want to keep one test which uses 
>>>>>> to the option to make sure it is supported. If there is no such 
>>>>>> remaining test, SourceOption.java could be resurrected and make 
>>>>>> to check that a JDK 8 feature is rejected under source 7, etc.
>>>>>>
>>>>>> Otherwise, the removal of the other -source uses looks fine.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>> On 2/19/2014 7:37 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>>>>>> Hi Neil,
>>>>>>>
>>>>>>> there is a typo at test/tools/javadoc/6964914/JavacWarning.java:
>>>>>>>
>>>>>>> "It *amy* be deprecated in JDK8"
>>>>>>>
>>>>>>> at test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java:
>>>>>>>
>>>>>>> I would add the note as an independent comment after the
>>>>>>>
>>>>>>> * @test
>>>>>>> * @bug      8004893 8022738
>>>>>>> section not as part of it.
>>>>>>>
>>>>>>> Vicente
>>>>>>>
>>>>>>> On 18/02/14 21:10, Neil Toda wrote:
>>>>>>>>
>>>>>>>> A small set of javadoc tests contain the -source parameter.  In 
>>>>>>>> most cases, the parameter is
>>>>>>>> not required for the test.  In several cases, the -source 
>>>>>>>> parameter is being explicitly tested,
>>>>>>>> but relies on a JDK version that will be removed from JDK9.
>>>>>>>>
>>>>>>>> This changeset removes unnecessary -source specification when 
>>>>>>>> not needed, or changes the
>>>>>>>> test/source-version requested to one that will work in JDK9.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~darcy/neiltoda/8031670.0/
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -neil
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140224/b09a5869/attachment.html 

From eric.mccorkle at oracle.com  Mon Feb 24 12:53:16 2014
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 24 Feb 2014 15:53:16 -0500
Subject: Type annotations clarification
Message-ID: <530BB13C.9020101@oracle.com>

I need a brief clarification on what the type path should look like for
some type annotations.

In the following example:


class Outer {

  class Inner<T> {}

  Outer. at A Inner<@B Integer> f1;

  @C Inner<@D String> f2;

}


The type paths for @A and @B look like this:

@A: [INNER_TYPE]
@B: [INNER_TYPE, TYPE_ARGUMENT(0)]

The question is, what about @C and @D, which are on an unqualified
reference to Inner?  Should they be the same as for @A and @B, or should
they look like this:

@C: []
@D: [TYPE_ARGUMENT(0)]



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/20140224/ca7cfaed/eric_mccorkle.vcf 

From wdietl at gmail.com  Mon Feb 24 13:01:44 2014
From: wdietl at gmail.com (Werner Dietl)
Date: Mon, 24 Feb 2014 16:01:44 -0500
Subject: Type annotations clarification
In-Reply-To: <530BB13C.9020101@oracle.com>
References: <530BB13C.9020101@oracle.com>
Message-ID: <530BB338.2010905@gmail.com>

I think @C and @D need to have the same type path as @A and @B.
In the compiled bytecode, the signature for both fields is the same.
The output of javap for the example looks correct to me:

Outer$Inner<java.lang.Integer> f1;
  descriptor: LOuter$Inner;
  flags:
  Signature: #10              // LOuter$Inner<Ljava/lang/Integer;>;
  RuntimeInvisibleTypeAnnotations:
    0: #12(): FIELD, location=[INNER_TYPE]
    1: #13(): FIELD, location=[INNER_TYPE, TYPE_ARGUMENT(0)]

Outer$Inner<java.lang.String> f2;
  descriptor: LOuter$Inner;
  flags:
  Signature: #15              // LOuter$Inner<Ljava/lang/String;>;
  RuntimeInvisibleTypeAnnotations:
    0: #16(): FIELD, location=[INNER_TYPE, TYPE_ARGUMENT(0)]
    1: #17(): FIELD, location=[INNER_TYPE]

If @C and @D used a different type path, the type annotations couldn't
be correctly matched.

cu, WMD.


On 02/24/2014 03:53 PM, Eric McCorkle wrote:
> I need a brief clarification on what the type path should look like for
> some type annotations.
> 
> In the following example:
> 
> 
> class Outer {
> 
>   class Inner<T> {}
> 
>   Outer. at A Inner<@B Integer> f1;
> 
>   @C Inner<@D String> f2;
> 
> }
> 
> 
> The type paths for @A and @B look like this:
> 
> @A: [INNER_TYPE]
> @B: [INNER_TYPE, TYPE_ARGUMENT(0)]
> 
> The question is, what about @C and @D, which are on an unqualified
> reference to Inner?  Should they be the same as for @A and @B, or should
> they look like this:
> 
> @C: []
> @D: [TYPE_ARGUMENT(0)]
> 
> 
> 
> Thanks,
> Eric
> 

From alex.buckley at oracle.com  Mon Feb 24 13:20:06 2014
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 24 Feb 2014 13:20:06 -0800
Subject: Type annotations clarification
In-Reply-To: <530BB338.2010905@gmail.com>
References: <530BB13C.9020101@oracle.com> <530BB338.2010905@gmail.com>
Message-ID: <530BB786.4000900@oracle.com>

Right.

Now, if class Inner<T> is declared static (i.e. it's still a nested 
class, but not an inner class), then the INNER_TYPE path disappears. "@C 
Inner<@D String> f2" compiles to:

  Outer$Inner<java.lang.String> f2;
    descriptor: LOuter$Inner;
    flags:
    Signature: #10          // LOuter$Inner<Ljava/lang/String;>;
    RuntimeInvisibleTypeAnnotations:
      0: #12(): FIELD, location=[TYPE_ARGUMENT(0)]
      1: #12(): FIELD

because Outer is now a "scoping mechanism" for Inner, much like a 
package name would be, so it's not part of the annotated type per se.

Alex

On 2/24/2014 1:01 PM, Werner Dietl wrote:
> I think @C and @D need to have the same type path as @A and @B.
> In the compiled bytecode, the signature for both fields is the same.
> The output of javap for the example looks correct to me:
>
> Outer$Inner<java.lang.Integer> f1;
>    descriptor: LOuter$Inner;
>    flags:
>    Signature: #10              // LOuter$Inner<Ljava/lang/Integer;>;
>    RuntimeInvisibleTypeAnnotations:
>      0: #12(): FIELD, location=[INNER_TYPE]
>      1: #13(): FIELD, location=[INNER_TYPE, TYPE_ARGUMENT(0)]
>
> Outer$Inner<java.lang.String> f2;
>    descriptor: LOuter$Inner;
>    flags:
>    Signature: #15              // LOuter$Inner<Ljava/lang/String;>;
>    RuntimeInvisibleTypeAnnotations:
>      0: #16(): FIELD, location=[INNER_TYPE, TYPE_ARGUMENT(0)]
>      1: #17(): FIELD, location=[INNER_TYPE]
>
> If @C and @D used a different type path, the type annotations couldn't
> be correctly matched.
>
> cu, WMD.
>
>
> On 02/24/2014 03:53 PM, Eric McCorkle wrote:
>> I need a brief clarification on what the type path should look like for
>> some type annotations.
>>
>> In the following example:
>>
>>
>> class Outer {
>>
>>    class Inner<T> {}
>>
>>    Outer. at A Inner<@B Integer> f1;
>>
>>    @C Inner<@D String> f2;
>>
>> }
>>
>>
>> The type paths for @A and @B look like this:
>>
>> @A: [INNER_TYPE]
>> @B: [INNER_TYPE, TYPE_ARGUMENT(0)]
>>
>> The question is, what about @C and @D, which are on an unqualified
>> reference to Inner?  Should they be the same as for @A and @B, or should
>> they look like this:
>>
>> @C: []
>> @D: [TYPE_ARGUMENT(0)]
>>
>>
>>
>> Thanks,
>> Eric
>>

From vicente.romero at oracle.com  Mon Feb 24 13:27:36 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Mon, 24 Feb 2014 21:27:36 +0000
Subject: Inference of recursive types
In-Reply-To: <CAL4Qsgu2o5EvyOP0ajkLnDZC4r1CGrEYu2JOH-kAgquuMJQLOQ@mail.gmail.com>
References: <CAL4Qsgv1_eHHfv_VOTgEE3iqCF7hv2wrOJ-b7RyiyN=Wesjabw@mail.gmail.com>
	<CAL4QsguZtiC3MB9mbFBUXVssOj6PaEy51Aq52B-vcNE5KSKh3Q@mail.gmail.com>
	<5307BEF4.1060603@oracle.com>
	<CAL4Qsgu2o5EvyOP0ajkLnDZC4r1CGrEYu2JOH-kAgquuMJQLOQ@mail.gmail.com>
Message-ID: <530BB948.60601@oracle.com>

Hi Liam,

Thanks for the bug report. I also think that this is a bug. I have filed 
this entry: https://bugs.openjdk.java.net/browse/JDK-8035713 to track it.

Vicente

On 21/02/14 21:09, Liam Miller-Cushon wrote:
> I was surprised that it starts working again with javac 8 source 8, 
> but I appreciate that it may not be a regression. Thanks for 
> investigating.
>
> Liam
>
>
> On Fri, Feb 21, 2014 at 1:02 PM, Vicente-Arturo Romero-Zaldivar 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     On 21/02/14 19:31, Liam Miller-Cushon wrote:
>
>         +lambda-dev
>
>         Any thoughts on this?
>
>
>     Hi Liam,
>
>     I will look at this and get back to you. The fact that something
>     is working find in 7 and not in 8 source 7 doesn't imply that
>     there is a regression in the compiler. It can be a bug in 7 that
>     we don't have to reproduce in 8 just to keep the compatibility.
>     Every case is different and this could be a regression.
>
>     Thanks,
>     Vicente
>
>
>
>         This affects a significant amount of code, and the fact that
>         it only
>         appears when compiling java 7 with javac8 makes it look like a
>         regression.
>
>         The following is a less contrived example of code with
>         recursive types that
>         doesn't currently compile with javac8 -source 7 -target 7:
>
>         class Test {
>            <T extends Enum<T>> T getEnum() { return null; }
>            <U extends Enum<U>> void m() {
>              U e = getEnum();
>            }
>         }
>
>         $ javac -source 7 -target 7 Test.java
>         Test.java:4: error: incompatible types: inference variable T#1 has
>         incompatible upper bounds Enum<T#2>,U
>              U e = getEnum();
>                           ^
>            where T#1,T#2,U are type-variables:
>              T#1 extends Enum<T#1> declared in method <T#1>getEnum()
>              T#2 extends U
>              U extends Enum<U> declared in method <U>m()
>
>         On Fri, Feb 14, 2014 at 5:07 PM, Liam Miller-Cushon
>         <cushon at google.com <mailto:cushon at google.com>>wrote:
>
>             Hi -
>
>             Sorry if this has already been discussed, but I ran into a
>             difference in
>             behaviour between javac8 -source 7/-target 7 and both
>             javac7 and javac8
>             -source 8/-target 8.
>
>             The following program compiles with everything except
>             javac8 -source
>             7/-target 7.
>
>             Is this an intentional change? Having to make g's type
>             parameter explicit
>             feels like a regression.
>
>             ===
>             class Test {
>                static class One<T> {}
>                static class Two extends One<Two> {}
>
>                <T extends One<T>> T f(T a, String s) {
>                  T t = g(s);
>                  return t;
>                }
>                static <U extends One<U>> U g(String s) {
>                  throw new RuntimeException();
>                }
>             }
>             ===
>
>             Test.java:6: error: incompatible types: inference variable
>             U#1 has
>             incompatible upper bounds One<U#2>,T
>                  T t = g(s);
>                         ^
>                where U#1,U#2,T are type-variables:
>                  U#1 extends One<U#1> declared in method <U#1>g(String)
>                  U#2 extends T
>                  T extends One<T> declared in method <T>f(T,String)
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140224/40b625f4/attachment.html 

From jan.lahoda at oracle.com  Tue Feb 25 01:01:04 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 25 Feb 2014 10:01:04 +0100
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero
In-Reply-To: <53078E30.1070907@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
	<5305E2D8.9040207@oracle.com> <53065403.4060506@oracle.com>
	<530666DE.30505@oracle.com> <53066E55.3010500@oracle.com>
	<53077ECE.80705@oracle.com> <53078E30.1070907@oracle.com>
Message-ID: <530C5BD0.20101@oracle.com>

Hi Vicente,

Updated patch:
http://cr.openjdk.java.net/~jlahoda/8034854/webrev.02/

Thanks for the comments,
     Jan

On 02/21/2014 06:34 PM, Vicente-Arturo Romero-Zaldivar wrote:
> On 21/02/14 16:29, Jan Lahoda wrote:
>> On 02/20/2014 10:06 PM, Alex Buckley wrote:
>>> Interesting reasons. Does reuse of an existing top-level or anonymous
>>> class choose from a pool of all classes (inc. user-defined ones) or only
>>> synthetic classes?
>>
>> User-defined anonymous classes are reused for private constructor tags
>> if available, but, on a closer look, user-defined anonymous classes
>> don't seem to be reused in other cases. User-defined top-level classes
>> (if available) appear to be reused for targets <= 1.4 to hold the
>> desugared code for class literals.
>>
>>>
>>> I'm still not clear if "one class is synthesized per top-level type"
>>> means "one member class" or "one anonymous class". I guess the
>>
>> Internally, they look somewhat like a member class with an empty name
>> ("anonymous member class"). But I don't think the internal
>> representation should affect the content of the attributes in this case.
>>
>>> ill-formed answer currently given by javac is "one member-anonymous
>>> class", because the non-zero outer_class_info_index implies it's a
>>> member class while the zero inner_name_index implies it's an anonymous
>>> class - yuk. I recommend making them truly anonymous.
>>
>> Thanks.
>>
>> A webrev that updates tests according to comments received so far:
>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.01/
>
> Hi Jan,
>
> I would modify the proposed test by including all the cases for which
> javac generates synthetic classes, also it would be preferable if the
> test is included in just one file.
>
> Thanks,
> Vicente
>
>>
>> Jan
>>
>>>
>>> Alex
>>>
>>> On 2/20/2014 12:34 PM, Jan Lahoda wrote:
>>>> As far as I was able to determine, these are the cases where and why
>>>> the
>>>> auxiliary classes are generated/used:
>>>> -as tags for access constructors for private constructors. An existing
>>>> anonymous innerclass is reused as a tag, if available, otherwise at
>>>> most
>>>> one class is synthesized per top-level type.
>>>> -for target levels whose ldc instruction does not support references to
>>>> classes, desugared code for class literals (a "getter" and cache for
>>>> the
>>>> Class objects) is placed into a "cache" class. Depending on the
>>>> circumstances, a top-level class or an existing anonymous innerclass is
>>>> reused if possible, otherwise at most one class is synthesized per
>>>> top-level type.
>>>> -for switch-over-enum, a lazy map between enum constants and
>>>> ordinals is
>>>> placed into a cache class. An existing anonymous innerclass is reused,
>>>> if available, otherwise at most one class is synthesized per top-level
>>>> type.
>>>> -for interfaces, to hold their assertions enabled status. At most one
>>>> class is synthesized per top-level type.
>>>>
>>>> Jan
>>>>
>>>> On 02/20/2014 08:14 PM, Alex Buckley wrote:
>>>>> It would make sense to consider the full range of reasons why these
>>>>> auxiliary classes are generated. You indicated one reason - tags for
>>>>> accessing private ctors - and it makes sense to generate a "true"
>>>>> anonymous class there (outer_class_info_index=0, inner_name_index=0).
>>>>> But perhaps other reasons would justify auxiliary classes with
>>>>> meaningful "owners" - again, your word - and there it would be
>>>>> sensible
>>>>> to consider them as member classes rather than anonymous classes.
>>>>>
>>>>> Alex
>>>>>
>>>>> On 2/20/2014 3:11 AM, Jan Lahoda wrote:
>>>>>> Hi Alex,
>>>>>>
>>>>>> Thanks for the comments.
>>>>>>
>>>>>> I was briefly considering filling some inner_name for the synthetic
>>>>>> classes, but using zeroing outer_class_info_index seemed somewhat
>>>>>> cleaner, safer (no risk of name clashes or misinterpretation of the
>>>>>> name) and simpler. But if generating an inner_name for the synthetic
>>>>>> classes would be (strongly) preferred, I can investigate it.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> The requirement that outer_class_info_index must agree with
>>>>>>> inner_name_index w.r.t. an anonymous class was added in JVMS7
>>>>>>> because we
>>>>>>> saw class files where they disagreed and it simply made no sense.
>>>>>>> The
>>>>>>> requirement was conditioned on 51.0 class files because we didn't
>>>>>>> want
>>>>>>> to break pre-7 class files with insensible InnerClasses.
>>>>>>>
>>>>>>> The auxiliary classes generated by javac appear to have a meaningful
>>>>>>> "owner" - your word - so it would seem appropriate to have a
>>>>>>> non-zero
>>>>>>> outer_class_info_index. Just generate a random name for
>>>>>>> inner_name_index. (The 4.7.6 text assumes the "original simple name"
>>>>>>> can
>>>>>>> be derived from source code, but that's not applicable for synthetic
>>>>>>> classes.) This change could reasonably affect all target levels,
>>>>>>> since
>>>>>>> no-one should be relying on the value of inner_name_index for these
>>>>>>> auxiliary classes.
>>>>>>>
>>>>>>> OTOH, your proposal to represent the auxiliary classes as true
>>>>>>> anonymous
>>>>>>> classes in InnerClasses is attractive because it exposes even less
>>>>>>> information than at present. This change could reasonably affect all
>>>>>>> target levels too, since no-one should be relying on the value of
>>>>>>> outer_class_info_index for these auxiliary classes.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I have a few questions about JDK-8034854 and a possible
>>>>>>>> patch/fix for
>>>>>>>> it. The bug URL:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>>>>>>
>>>>>>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses
>>>>>>>> Attribute)
>>>>>>>> mandates that:
>>>>>>>>   If a class file has a version number that is greater than or
>>>>>>>> equal to
>>>>>>>>   51.0, and has an InnerClasses attribute in its attributes table,
>>>>>>>> then
>>>>>>>>   for all entries in the classes array of the InnerClasses
>>>>>>>> attribute,
>>>>>>>>   the value of the outer_class_info_index item must be zero if the
>>>>>>>> value
>>>>>>>>   of the inner_name_index item is zero.
>>>>>>>> javac in some cases produces non-zero "outer_class_info_index"
>>>>>>>> even if
>>>>>>>> "inner_name_index" is zero. This happens for synthetically
>>>>>>>> generated
>>>>>>>> auxiliary classes. These classes are generated for a number of
>>>>>>>> reasons,
>>>>>>>> for example to be used as tags when accessing private constructors.
>>>>>>>> The
>>>>>>>> synthetic classes internally have an empty name, so the generated
>>>>>>>> "inner_name_index" is zero, but their owner is a class, so they get
>>>>>>>> the
>>>>>>>> non-zero "outer_class_info_index".
>>>>>>>>
>>>>>>>> I've sketched out a simple fix for this problem, which ensures that
>>>>>>>> "outer_class_info_index" is zero for classes that have empty name:
>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>>>>>>
>>>>>>>> After this change, the generated synthetic classes look a lot like
>>>>>>>> anonymous classes defined in an initializer of the given class
>>>>>>>> (based on
>>>>>>>> the InnerClasses attribute and the EnclosingMethod attribute). That
>>>>>>>> seems reasonable to me.
>>>>>>>>
>>>>>>>> My questions are:
>>>>>>>> -does the fix above make sense?
>>>>>>>> -the change affects all target levels. It seems to me that the new
>>>>>>>> behavior makes sense even for pre-7 classfiles, but I'll gladly
>>>>>>>> limit
>>>>>>>> the new behavior to only some minimal target level if desired.
>>>>>>>>
>>>>>>>> Any comments welcome.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>     Jan
>

From vicente.romero at oracle.com  Tue Feb 25 06:28:52 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Tue, 25 Feb 2014 14:28:52 +0000
Subject: Queries and patch for JDK-8034854: outer_class_info_index of
	synthetic class is not zero - approved
In-Reply-To: <530C5BD0.20101@oracle.com>
References: <5304A4C3.3070202@oracle.com> <53050245.7090006@oracle.com>
	<5305E2D8.9040207@oracle.com> <53065403.4060506@oracle.com>
	<530666DE.30505@oracle.com> <53066E55.3010500@oracle.com>
	<53077ECE.80705@oracle.com> <53078E30.1070907@oracle.com>
	<530C5BD0.20101@oracle.com>
Message-ID: <530CA8A4.3080108@oracle.com>

On 25/02/14 09:01, Jan Lahoda wrote:
> Hi Vicente,
>
> Updated patch:
> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.02/

Hi Jan,

It's OK for me,

Vicente

>
> Thanks for the comments,
>     Jan
>
> On 02/21/2014 06:34 PM, Vicente-Arturo Romero-Zaldivar wrote:
>> On 21/02/14 16:29, Jan Lahoda wrote:
>>> On 02/20/2014 10:06 PM, Alex Buckley wrote:
>>>> Interesting reasons. Does reuse of an existing top-level or anonymous
>>>> class choose from a pool of all classes (inc. user-defined ones) or 
>>>> only
>>>> synthetic classes?
>>>
>>> User-defined anonymous classes are reused for private constructor tags
>>> if available, but, on a closer look, user-defined anonymous classes
>>> don't seem to be reused in other cases. User-defined top-level classes
>>> (if available) appear to be reused for targets <= 1.4 to hold the
>>> desugared code for class literals.
>>>
>>>>
>>>> I'm still not clear if "one class is synthesized per top-level type"
>>>> means "one member class" or "one anonymous class". I guess the
>>>
>>> Internally, they look somewhat like a member class with an empty name
>>> ("anonymous member class"). But I don't think the internal
>>> representation should affect the content of the attributes in this 
>>> case.
>>>
>>>> ill-formed answer currently given by javac is "one member-anonymous
>>>> class", because the non-zero outer_class_info_index implies it's a
>>>> member class while the zero inner_name_index implies it's an anonymous
>>>> class - yuk. I recommend making them truly anonymous.
>>>
>>> Thanks.
>>>
>>> A webrev that updates tests according to comments received so far:
>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.01/
>>
>> Hi Jan,
>>
>> I would modify the proposed test by including all the cases for which
>> javac generates synthetic classes, also it would be preferable if the
>> test is included in just one file.
>>
>> Thanks,
>> Vicente
>>
>>>
>>> Jan
>>>
>>>>
>>>> Alex
>>>>
>>>> On 2/20/2014 12:34 PM, Jan Lahoda wrote:
>>>>> As far as I was able to determine, these are the cases where and why
>>>>> the
>>>>> auxiliary classes are generated/used:
>>>>> -as tags for access constructors for private constructors. An 
>>>>> existing
>>>>> anonymous innerclass is reused as a tag, if available, otherwise at
>>>>> most
>>>>> one class is synthesized per top-level type.
>>>>> -for target levels whose ldc instruction does not support 
>>>>> references to
>>>>> classes, desugared code for class literals (a "getter" and cache for
>>>>> the
>>>>> Class objects) is placed into a "cache" class. Depending on the
>>>>> circumstances, a top-level class or an existing anonymous 
>>>>> innerclass is
>>>>> reused if possible, otherwise at most one class is synthesized per
>>>>> top-level type.
>>>>> -for switch-over-enum, a lazy map between enum constants and
>>>>> ordinals is
>>>>> placed into a cache class. An existing anonymous innerclass is 
>>>>> reused,
>>>>> if available, otherwise at most one class is synthesized per 
>>>>> top-level
>>>>> type.
>>>>> -for interfaces, to hold their assertions enabled status. At most one
>>>>> class is synthesized per top-level type.
>>>>>
>>>>> Jan
>>>>>
>>>>> On 02/20/2014 08:14 PM, Alex Buckley wrote:
>>>>>> It would make sense to consider the full range of reasons why these
>>>>>> auxiliary classes are generated. You indicated one reason - tags for
>>>>>> accessing private ctors - and it makes sense to generate a "true"
>>>>>> anonymous class there (outer_class_info_index=0, 
>>>>>> inner_name_index=0).
>>>>>> But perhaps other reasons would justify auxiliary classes with
>>>>>> meaningful "owners" - again, your word - and there it would be
>>>>>> sensible
>>>>>> to consider them as member classes rather than anonymous classes.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> On 2/20/2014 3:11 AM, Jan Lahoda wrote:
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> Thanks for the comments.
>>>>>>>
>>>>>>> I was briefly considering filling some inner_name for the synthetic
>>>>>>> classes, but using zeroing outer_class_info_index seemed somewhat
>>>>>>> cleaner, safer (no risk of name clashes or misinterpretation of the
>>>>>>> name) and simpler. But if generating an inner_name for the 
>>>>>>> synthetic
>>>>>>> classes would be (strongly) preferred, I can investigate it.
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> The requirement that outer_class_info_index must agree with
>>>>>>>> inner_name_index w.r.t. an anonymous class was added in JVMS7
>>>>>>>> because we
>>>>>>>> saw class files where they disagreed and it simply made no sense.
>>>>>>>> The
>>>>>>>> requirement was conditioned on 51.0 class files because we didn't
>>>>>>>> want
>>>>>>>> to break pre-7 class files with insensible InnerClasses.
>>>>>>>>
>>>>>>>> The auxiliary classes generated by javac appear to have a 
>>>>>>>> meaningful
>>>>>>>> "owner" - your word - so it would seem appropriate to have a
>>>>>>>> non-zero
>>>>>>>> outer_class_info_index. Just generate a random name for
>>>>>>>> inner_name_index. (The 4.7.6 text assumes the "original simple 
>>>>>>>> name"
>>>>>>>> can
>>>>>>>> be derived from source code, but that's not applicable for 
>>>>>>>> synthetic
>>>>>>>> classes.) This change could reasonably affect all target levels,
>>>>>>>> since
>>>>>>>> no-one should be relying on the value of inner_name_index for 
>>>>>>>> these
>>>>>>>> auxiliary classes.
>>>>>>>>
>>>>>>>> OTOH, your proposal to represent the auxiliary classes as true
>>>>>>>> anonymous
>>>>>>>> classes in InnerClasses is attractive because it exposes even less
>>>>>>>> information than at present. This change could reasonably 
>>>>>>>> affect all
>>>>>>>> target levels too, since no-one should be relying on the value of
>>>>>>>> outer_class_info_index for these auxiliary classes.
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I have a few questions about JDK-8034854 and a possible
>>>>>>>>> patch/fix for
>>>>>>>>> it. The bug URL:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>>>>>>>
>>>>>>>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses
>>>>>>>>> Attribute)
>>>>>>>>> mandates that:
>>>>>>>>>   If a class file has a version number that is greater than or
>>>>>>>>> equal to
>>>>>>>>>   51.0, and has an InnerClasses attribute in its attributes 
>>>>>>>>> table,
>>>>>>>>> then
>>>>>>>>>   for all entries in the classes array of the InnerClasses
>>>>>>>>> attribute,
>>>>>>>>>   the value of the outer_class_info_index item must be zero if 
>>>>>>>>> the
>>>>>>>>> value
>>>>>>>>>   of the inner_name_index item is zero.
>>>>>>>>> javac in some cases produces non-zero "outer_class_info_index"
>>>>>>>>> even if
>>>>>>>>> "inner_name_index" is zero. This happens for synthetically
>>>>>>>>> generated
>>>>>>>>> auxiliary classes. These classes are generated for a number of
>>>>>>>>> reasons,
>>>>>>>>> for example to be used as tags when accessing private 
>>>>>>>>> constructors.
>>>>>>>>> The
>>>>>>>>> synthetic classes internally have an empty name, so the generated
>>>>>>>>> "inner_name_index" is zero, but their owner is a class, so 
>>>>>>>>> they get
>>>>>>>>> the
>>>>>>>>> non-zero "outer_class_info_index".
>>>>>>>>>
>>>>>>>>> I've sketched out a simple fix for this problem, which ensures 
>>>>>>>>> that
>>>>>>>>> "outer_class_info_index" is zero for classes that have empty 
>>>>>>>>> name:
>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>>>>>>>
>>>>>>>>> After this change, the generated synthetic classes look a lot 
>>>>>>>>> like
>>>>>>>>> anonymous classes defined in an initializer of the given class
>>>>>>>>> (based on
>>>>>>>>> the InnerClasses attribute and the EnclosingMethod attribute). 
>>>>>>>>> That
>>>>>>>>> seems reasonable to me.
>>>>>>>>>
>>>>>>>>> My questions are:
>>>>>>>>> -does the fix above make sense?
>>>>>>>>> -the change affects all target levels. It seems to me that the 
>>>>>>>>> new
>>>>>>>>> behavior makes sense even for pre-7 classfiles, but I'll gladly
>>>>>>>>> limit
>>>>>>>>> the new behavior to only some minimal target level if desired.
>>>>>>>>>
>>>>>>>>> Any comments welcome.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>     Jan
>>


From sean.coffey at oracle.com  Wed Feb 26 15:07:08 2014
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Wed, 26 Feb 2014 23:07:08 +0000
Subject: hg: jdk8/tl/corba: 8035618: Four api/org_omg/CORBA TCK tests fail
	under plugin only
Message-ID: <20140226230711.5750362F74@hg.openjdk.java.net>

Changeset: 0683ee308085
Author:    coffeys
Date:      2014-02-26 23:04 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/0683ee308085

8035618: Four api/org_omg/CORBA TCK tests fail under plugin only
Reviewed-by: mchung, chegar

! src/share/classes/com/sun/corba/se/spi/orb/ORB.java


From vicente.romero at oracle.com  Thu Feb 27 07:32:45 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 27 Feb 2014 15:32:45 +0000
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>	<52FC2BE5.9010903@oracle.com>	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>	<52FD62C5.7020006@oracle.com>
	<CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
Message-ID: <530F5A9D.9020900@oracle.com>

Hi,

On 14/02/14 00:57, Liam Miller-Cushon wrote:
>
>     Filed https://bugs.openjdk.java.net/browse/JDK-8034924.
>
>
> Thanks!
>
>     - The compile-time error appears (incorrectly) whether the static
>     method in base.BaseImpl is package access or private. But if the
>     static method is public, then everything works fine:
>     Impl.foo(Object) attempts to override base.BaseImpl.foo(Object),
>     and a compile-time error occurs because an instance method cannot
>     override a static method.
>
>
> I think the culprit is that Symbol.hiddenIn(...) doesn't consider 
> visibility. It's incorrectly reporting Impl.foo() as being hidden by 
> base.BaseImpl.foo(), which causes an error during lowering when a 
> qualified base class reference is being synthesized for the invocation.

IMO, the problem here in hiddenIn() is not that visibility is not being 
considered, this caught in other part of the compiler. The problem here 
is that hiddenIn() was analyzing all the superclasses up to Object. This 
is not necessary to determine if a member is hidden or not.

Thanks,
Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/71090a5e/attachment.html 

From neil.toda at oracle.com  Thu Feb 27 08:13:10 2014
From: neil.toda at oracle.com (Neil Toda)
Date: Thu, 27 Feb 2014 08:13:10 -0800
Subject: Review Request - 2  : JDK-8031670: remove unneeded -source option
	from javadoc tests
In-Reply-To: <530EF0B0.6050700@oracle.com>
References: <530EF0B0.6050700@oracle.com>
Message-ID: <530F6416.2080004@oracle.com>

This is a Review Request resubmission with reviewer-based changes.

Original Description:

    A small set of javadoc tests contain the -source parameter.  In most
    cases, the parameter is
    not required for the test.  In several cases, the -source parameter
    is being explicitly tested,
    but relies on a JDK version that will be removed from JDK9.

    This changeset removes unnecessary -source specification when not
    needed, or changes the
    test/source-version requested to one that will work in JDK9


The revised changeset-webrev can be found here:

http://cr.openjdk.java.net/~darcy/neiltoda/8031670.1/


Changes from first submittal:

   * in ./test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java
     * correct spelling error : amy -> may
     * remove comment on test from jtreg tag block
   * to validate -source option operation
     * reinstate ./sourceOption test
     * in ./test/tools/javadoc/sourceOption/SourceOption.java
       * changed to a negative test to make sure javac lambda construct 
is not in 1.7
       * add information about updating test periodically
       * add a fixVersion bug [ set to 1.10 for current targeted feature ]
     * added ./test/tools/javadoc/sourceOption/p/LambdaConstructTest.java
       * valid for 1.8, but not for 1.7. "-source 1.7" is checked with 
this code.
     * added ./test/tools/javadoc/sourceOption2/SourceOption2.java
       * This test is a positive test to make sure that the lambda 
construct provided for ./sourceOption is valid for 8.
       * This test is actually examining 
./sourceOption/p/LambdaConstructTest.java

Thanks

-neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/86a43932/attachment.html 

From cushon at google.com  Thu Feb 27 08:17:40 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 27 Feb 2014 08:17:40 -0800
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <530F5A9D.9020900@oracle.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
	<52FD62C5.7020006@oracle.com>
	<CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
	<530F5A9D.9020900@oracle.com>
Message-ID: <CAL4QsgtcBEO6Q4=tVQ7eeh7gEaqz52EtB4Swbcxi8PCpKEx6MQ@mail.gmail.com>

> IMO, the problem here in hiddenIn() is not that visibility is not being
> considered, this caught in other part of the compiler. The problem here is
> that hiddenIn() was analyzing all the superclasses up to Object. This is
> not necessary to determine if a member is hidden or not.
>

The implementation of hiddenIn() is also examining all superinterfaces. Is
that necessary? It's a compile time error for a static method to hide an
interface method, and that error should get caught earlier in the
compilation.

If hiddenIn() was only considering superclasses then it could just examine
the path between the current class and the member's owner, which I think
would fix this bug.

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/a8fc7d21/attachment.html 

From vicente.romero at oracle.com  Thu Feb 27 08:41:21 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 27 Feb 2014 16:41:21 +0000
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <CAL4QsgtcBEO6Q4=tVQ7eeh7gEaqz52EtB4Swbcxi8PCpKEx6MQ@mail.gmail.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
	<52FD62C5.7020006@oracle.com>
	<CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
	<530F5A9D.9020900@oracle.com>
	<CAL4QsgtcBEO6Q4=tVQ7eeh7gEaqz52EtB4Swbcxi8PCpKEx6MQ@mail.gmail.com>
Message-ID: <530F6AB1.1060608@oracle.com>

On 27/02/14 16:17, Liam Miller-Cushon wrote:
>
>     IMO, the problem here in hiddenIn() is not that visibility is not
>     being considered, this caught in other part of the compiler. The
>     problem here is that hiddenIn() was analyzing all the superclasses
>     up to Object. This is not necessary to determine if a member is
>     hidden or not.
>
>
> The implementation of hiddenIn() is also examining all 
> superinterfaces. Is that necessary? It's a compile time error for a 
> static method to hide an interface method, and that error should get 
> caught earlier in the compilation.
>
> If hiddenIn() was only considering superclasses then it could just 
> examine the path between the current class and the member's owner, 
> which I think would fix this bug.
>
> Thanks,
> Liam
Well hiddenIn() is not used for methods only, also fields are considered.

Thanks,
Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/4d621ae5/attachment.html 

From cushon at google.com  Thu Feb 27 09:23:41 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 27 Feb 2014 09:23:41 -0800
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <530F6AB1.1060608@oracle.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
	<52FD62C5.7020006@oracle.com>
	<CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
	<530F5A9D.9020900@oracle.com>
	<CAL4QsgtcBEO6Q4=tVQ7eeh7gEaqz52EtB4Swbcxi8PCpKEx6MQ@mail.gmail.com>
	<530F6AB1.1060608@oracle.com>
Message-ID: <CAL4Qsgu8vwGFOX2RHogRvabkNhFPnnYfWh5SjGx2kVfB4by-9g@mail.gmail.com>

>
> Well hiddenIn() is not used for methods only, also fields are considered.
>

So hiddenIn() should search along the path from the class to the member's
owner, and at each step search the superinterfaces of the current class? I
think the only change from the current implementation would be terminating
the search after reaching the owner.

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/710d9e66/attachment-0001.html 

From vicente.romero at oracle.com  Thu Feb 27 12:07:35 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 27 Feb 2014 20:07:35 +0000
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <CAL4Qsgu8vwGFOX2RHogRvabkNhFPnnYfWh5SjGx2kVfB4by-9g@mail.gmail.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
	<52FD62C5.7020006@oracle.com>
	<CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
	<530F5A9D.9020900@oracle.com>
	<CAL4QsgtcBEO6Q4=tVQ7eeh7gEaqz52EtB4Swbcxi8PCpKEx6MQ@mail.gmail.com>
	<530F6AB1.1060608@oracle.com>
	<CAL4Qsgu8vwGFOX2RHogRvabkNhFPnnYfWh5SjGx2kVfB4by-9g@mail.gmail.com>
Message-ID: <530F9B07.3030700@oracle.com>

On 27/02/14 17:23, Liam Miller-Cushon wrote:
>
>     Well hiddenIn() is not used for methods only, also fields are
>     considered.
>
>
> So hiddenIn() should search along the path from the class to the 
> member's owner, and at each step search the superinterfaces of the 
> current class? I think the only change from the current implementation 
> would be terminating the search after reaching the owner.
>
> Thanks,
> Liam
Yes that's the idea of the patch I'm working on and that's why I 
suggested that this was the reason of the problem :) As a side effect we 
may have some performance improvement.

Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/70eb1fea/attachment.html 

From cushon at google.com  Thu Feb 27 13:14:35 2014
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 27 Feb 2014 13:14:35 -0800
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <530F9B07.3030700@oracle.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
	<52FD62C5.7020006@oracle.com>
	<CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
	<530F5A9D.9020900@oracle.com>
	<CAL4QsgtcBEO6Q4=tVQ7eeh7gEaqz52EtB4Swbcxi8PCpKEx6MQ@mail.gmail.com>
	<530F6AB1.1060608@oracle.com>
	<CAL4Qsgu8vwGFOX2RHogRvabkNhFPnnYfWh5SjGx2kVfB4by-9g@mail.gmail.com>
	<530F9B07.3030700@oracle.com>
Message-ID: <CAL4QsgunXqRtWn8GKT8_1V8jqLa9Kx5d6H41+yVfHcEpDQyt2Q@mail.gmail.com>

Got it, thanks for taking the time to explain.


On Thu, Feb 27, 2014 at 12:07 PM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

>  On 27/02/14 17:23, Liam Miller-Cushon wrote:
>
>   Well hiddenIn() is not used for methods only, also fields are
>> considered.
>>
>
>  So hiddenIn() should search along the path from the class to the
> member's owner, and at each step search the superinterfaces of the current
> class? I think the only change from the current implementation would be
> terminating the search after reaching the owner.
>
>  Thanks,
> Liam
>
> Yes that's the idea of the patch I'm working on and that's why I suggested
> that this was the reason of the problem :) As a side effect we may have
> some performance improvement.
>
> Vicente
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/87b4caa2/attachment.html 

From vicente.romero at oracle.com  Thu Feb 27 13:29:56 2014
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 27 Feb 2014 21:29:56 +0000
Subject: compilation fails with 'no enclosing instance' error
In-Reply-To: <CAL4QsgunXqRtWn8GKT8_1V8jqLa9Kx5d6H41+yVfHcEpDQyt2Q@mail.gmail.com>
References: <CAL4QsguefMRU5nEpijArL8GyRCmra5A6tFPPEbfo2+fQCrMfYA@mail.gmail.com>
	<52FC2BE5.9010903@oracle.com>
	<CAL4QsgsqrWZX07Eo8wO1b-1Wc76A+5KsPq8K9yGbnb_3MyboUA@mail.gmail.com>
	<52FD62C5.7020006@oracle.com>
	<CAL4QsgtRtyhj40qnh-br7exvgGDqvsgrXmxk-fnx+V0=erisLQ@mail.gmail.com>
	<530F5A9D.9020900@oracle.com>
	<CAL4QsgtcBEO6Q4=tVQ7eeh7gEaqz52EtB4Swbcxi8PCpKEx6MQ@mail.gmail.com>
	<530F6AB1.1060608@oracle.com>
	<CAL4Qsgu8vwGFOX2RHogRvabkNhFPnnYfWh5SjGx2kVfB4by-9g@mail.gmail.com>
	<530F9B07.3030700@oracle.com>
	<CAL4QsgunXqRtWn8GKT8_1V8jqLa9Kx5d6H41+yVfHcEpDQyt2Q@mail.gmail.com>
Message-ID: <530FAE54.9010106@oracle.com>

On 27/02/14 21:14, Liam Miller-Cushon wrote:
> Got it, thanks for taking the time to explain.

np, and thanks to you. You was right that the problem was there which 
made the search much easier.

Vicente

>
>
> On Thu, Feb 27, 2014 at 12:07 PM, Vicente-Arturo Romero-Zaldivar 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     On 27/02/14 17:23, Liam Miller-Cushon wrote:
>>
>>         Well hiddenIn() is not used for methods only, also fields are
>>         considered.
>>
>>
>>     So hiddenIn() should search along the path from the class to the
>>     member's owner, and at each step search the superinterfaces of
>>     the current class? I think the only change from the current
>>     implementation would be terminating the search after reaching the
>>     owner.
>>
>>     Thanks,
>>     Liam
>     Yes that's the idea of the patch I'm working on and that's why I
>     suggested that this was the reason of the problem :) As a side
>     effect we may have some performance improvement.
>
>     Vicente
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140227/aafcf3fa/attachment.html 

From robert.field at oracle.com  Fri Feb 28 10:45:50 2014
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Fri, 28 Feb 2014 18:45:50 +0000
Subject: hg: jdk8/tl/jdk: 8035777: Consistent Lambda construction
Message-ID: <20140228184805.22B6D6239C@hg.openjdk.java.net>

Changeset: 183a8c520b4a
Author:    rfield
Date:      2014-02-28 10:43 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/183a8c520b4a

8035777: Consistent Lambda construction
Reviewed-by: ahgross, briangoetz, dlsmith

! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
+ test/java/lang/invoke/lambda/LambdaReceiver.java
+ test/java/lang/invoke/lambda/LambdaReceiverBridge.java
+ test/java/lang/invoke/lambda/LambdaReceiver_anotherpkg/LambdaReceiver_A.java
+ test/java/lang/invoke/lambda/LambdaReturn.java
+ test/java/lang/invoke/lambda/MetafactoryArityTest.java
+ test/java/lang/invoke/lambda/MetafactoryParameterCastTest.java
+ test/java/lang/invoke/lambda/MetafactorySamReturnTest.java