From poraon at yahoo.com  Wed Jun  1 13:44:19 2016
From: poraon at yahoo.com (Prakash Oraon)
Date: Wed, 1 Jun 2016 13:44:19 +0000 (UTC)
Subject: A bug in JDK 1.8 Server VM using in memory compile
References: <700727183.2382151.1464788659204.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <700727183.2382151.1464788659204.JavaMail.yahoo@mail.yahoo.com>

I am compiling a java source (stored in String variable) and using JavaCompiler / CompilationTask to compile the source in memory using JDK 1.8, source compatibility set to 1.7I have the following classes - DynamicCompiler - The main driver program. A, B, C - These classes are refereed from the source. B implements C. Class A, B and C are compiled in three differnt JARS - A.jar, B.jar and C.jar located in C:/Temp/testJpublic class DynamicCompiler {
public static void main(String[] args) {
    String sourceCode = 
            "public class TestMain {\n"+
            "   public static void main(String[] args) throws NullPointerException {\n"+
            "\n"+
            "       A a = new A();\n"+
            "\n"+       
            "       System.out.println(\"Inside Test Main...\");\n"+
            "       a.getB().printB();\n"+
            "   }\n"+
            "\n"+
            "}";

    JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();

    Iterable<String> options = Arrays.asList(new String[] { "-classpath", "C:/Temp/testJ/A.jar;C:/Temp/testJ/B.jar;","-source","1.7"});
    JavaFileManager fileManager = 
            new ClassFileManager(compiler.getStandardFileManager(null, null, null));
    DiagnosticCollector<JavaFileObject> diagnosticListener = new DiagnosticCollector<JavaFileObject>();
    List<JavaFileObject> jfiles = new ArrayList<JavaFileObject>();
    jfiles.add(new CharSequenceJavaFileObject("TestMain", sourceCode));

    CompilationTask complieTask = compiler.getTask(null, fileManager, diagnosticListener, options, null, jfiles);

    if(!complieTask.call()) {
        StringBuffer bufferError = new StringBuffer();
        List<Diagnostic<? extends JavaFileObject>> compliationErros = diagnosticListener.getDiagnostics();
        for (Diagnostic<? extends JavaFileObject> diagnostic : compliationErros) {
            bufferError.append(diagnostic);
        }

        System.out.printf("Errors:%s",bufferError.toString());
    } else {
        System.out.println("Compilation Successfull...");
    }
}public class A {
private B b;

A() {
    b = new B("A");
}

public void printA() {
    System.out.println("Inside A...");
    b.printB();
}

public B getB() {
    return b;
}public class B implements C {
private String name;

B(String name) {
    this.name = name;
}

public void printB() {
    System.out.println("Inside B...");
    System.out.println(name);
}

@Override
public void printC() {
    System.out.println("Inside B.printC");

}public interface C {
    void printC();
}The source (stored in variable sourceCode in class DynamicCompiler) is getting compiled using - java version "1.8.0_11" Java(TM) SE Runtime Environment (build 1.8.0_11-b12) Java HotSpot(TM) Client VM (build 25.11-b03, mixed mode)
But the same source (stored in variable sourceCode in class DynamicCompiler) is not getting compiled using - java version "1.8.0_66" Java(TM) SE Runtime Environment (build 1.8.0_66-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)I am getting the following error -Errors:/TestMain.java:7: error: cannot access C a.getB().printB(); ^ class file for C not foundIf I add C:/Temp/testJ/C.jar in the classpath as below, the source is compiled.Iterable options = Arrays.asList(new String[] { "-classpath", "C:/Temp/testJ/A.jar;C:/Temp/testJ/B.jar;C:/Temp/testJ/A.jar","-source","1.6"});Question -Why does the same code gets compiled in JDK 1.8 64-Bit Server VM but not in JDK 1.8 Client VM.? Is there a difference in compilation model between Client and Server VM in JDK 1.8?Thanks, Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160601/d3d2175f/attachment.html>

From daniel.smith at oracle.com  Wed Jun  1 21:58:47 2016
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 1 Jun 2016 15:58:47 -0600
Subject: General Registration -- 2016 JVM Language Summit
Message-ID: <2D3901A9-AB23-4523-AD31-D5385CF2F42D@oracle.com>

GENERAL REGISTRATION -- JVM LANGUAGE SUMMIT, AUGUST 2016

General registration for the 2016 JVM Language Summit is now open.  The event will be held at Oracle's Santa Clara campus on August 1-3, 2016.

We've also decided to extend speaker registration, keeping it open for one more week, until June 8.  If you or someone you know is interested in presenting, take advantage and submit an abstract ASAP! See http://jvmlangsummit.com for detailed speaker instructions.

The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice.

Presentations will be recorded and made available to the public.

This event is being organized by language and JVM engineers?no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions.

Format

The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected.

The schedule consists of a single track of traditional presentations (about 7 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-3 each day) and, possibly, impromptu "lightning talks."

Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders.

To register:
register.jvmlangsummit.com

For further information:
jvmlangsummit.com

Questions:
inquire2016 at jvmlangsummit.com

From iris.clark at oracle.com  Thu Jun  2 01:17:10 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 1 Jun 2016 18:17:10 -0700 (PDT)
Subject: RFR: 8158458: Update references from "1.9" to "9"
Message-ID: <debc6713-f24e-4483-94fa-707853742266@default>

Hi.

I'm taking another pass at replacing instances of "@since 1.9" with
"@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
files which need to be updated.  I've filed the following but to 
address this problem:

    8158458: Update references from "1.9" to "9" (closed code))
    https://bugs.openjdk.java.net/browse/JDK-8158458

This is the necessary diff, against jdk9/dev:

[/w/iclark/verona/javadoc/jdk]: 
diff -r 0bd06ec69c5b src/java.desktop/macosx/classes/com/apple/eawt/Application.java 
--- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 11:22:06 2016 -0700 
+++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 17:40:09 2016 -0700 
@@ -372,7 +372,7 @@ 
  * Acceptable values are from 0 to 100, any other disables progress indication. 
  * 
  * @param value progress value 
- * @since 1.9 
+ * @since 9 
      */ 
     public void setDockIconProgress(final int value) { 
         iconHandler.setDockIconProgress(value); 

[/w/iclark/verona/javadoc/langtools]: 
diff -r 2d1a6b746310 src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java 
--- a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 12:39:24 2016 +0100 
+++ b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 17:40:09 2016 -0700 
@@ -34,7 +34,7 @@ 
  * <p> 
  * &#064;hidden 
  * 
- * @since 1.9 
+ * @since 9 
  */ 
 public interface HiddenTree extends BlockTagTree { 
     /**

Build and test runs show no regressions.

Thanks,
Iris

From philip.race at oracle.com  Thu Jun  2 03:29:31 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 01 Jun 2016 20:29:31 -0700
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <debc6713-f24e-4483-94fa-707853742266@default>
References: <debc6713-f24e-4483-94fa-707853742266@default>
Message-ID: <574FA81B.1040706@oracle.com>

I don't see why @since matters on internal classes ...

-phil.

On 6/1/16, 6:17 PM, Iris Clark wrote:
> Hi.
>
> I'm taking another pass at replacing instances of "@since 1.9" with
> "@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
> files which need to be updated.  I've filed the following but to
> address this problem:
>
>      8158458: Update references from "1.9" to "9" (closed code))
>      https://bugs.openjdk.java.net/browse/JDK-8158458
>
> This is the necessary diff, against jdk9/dev:
>
> [/w/iclark/verona/javadoc/jdk]:
> diff -r 0bd06ec69c5b src/java.desktop/macosx/classes/com/apple/eawt/Application.java
> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 11:22:06 2016 -0700
> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 17:40:09 2016 -0700
> @@ -372,7 +372,7 @@
>    * Acceptable values are from 0 to 100, any other disables progress indication.
>    *
>    * @param value progress value
> - * @since 1.9
> + * @since 9
>        */
>       public void setDockIconProgress(final int value) {
>           iconHandler.setDockIconProgress(value);
>
> [/w/iclark/verona/javadoc/langtools]:
> diff -r 2d1a6b746310 src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
> --- a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 12:39:24 2016 +0100
> +++ b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 17:40:09 2016 -0700
> @@ -34,7 +34,7 @@
>    *<p>
>    *&#064;hidden
>    *
> - * @since 1.9
> + * @since 9
>    */
>   public interface HiddenTree extends BlockTagTree {
>       /**
>
> Build and test runs show no regressions.
>
> Thanks,
> Iris

From philip.race at oracle.com  Thu Jun  2 03:42:00 2016
From: philip.race at oracle.com (Philip Race)
Date: Wed, 01 Jun 2016 20:42:00 -0700
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <574FA81B.1040706@oracle.com>
References: <debc6713-f24e-4483-94fa-707853742266@default>
	<574FA81B.1040706@oracle.com>
Message-ID: <574FAB08.9000205@oracle.com>

By which I mean "delete" is as good as "update'

-phil

On 6/1/16, 8:29 PM, Philip Race wrote:
> I don't see why @since matters on internal classes ...
>
> -phil.
>
> On 6/1/16, 6:17 PM, Iris Clark wrote:
>> Hi.
>>
>> I'm taking another pass at replacing instances of "@since 1.9" with
>> "@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
>> files which need to be updated.  I've filed the following but to
>> address this problem:
>>
>>      8158458: Update references from "1.9" to "9" (closed code))
>>      https://bugs.openjdk.java.net/browse/JDK-8158458
>>
>> This is the necessary diff, against jdk9/dev:
>>
>> [/w/iclark/verona/javadoc/jdk]:
>> diff -r 0bd06ec69c5b 
>> src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java 
>> Wed Jun 01 11:22:06 2016 -0700
>> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java 
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -372,7 +372,7 @@
>>    * Acceptable values are from 0 to 100, any other disables progress 
>> indication.
>>    *
>>    * @param value progress value
>> - * @since 1.9
>> + * @since 9
>>        */
>>       public void setDockIconProgress(final int value) {
>>           iconHandler.setDockIconProgress(value);
>>
>> [/w/iclark/verona/javadoc/langtools]:
>> diff -r 2d1a6b746310 
>> src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
>> --- 
>> a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java 
>> Wed Jun 01 12:39:24 2016 +0100
>> +++ 
>> b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java 
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -34,7 +34,7 @@
>>    *<p>
>>    *&#064;hidden
>>    *
>> - * @since 1.9
>> + * @since 9
>>    */
>>   public interface HiddenTree extends BlockTagTree {
>>       /**
>>
>> Build and test runs show no regressions.
>>
>> Thanks,
>> Iris

From iris.clark at oracle.com  Fri Jun  3 03:39:32 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 2 Jun 2016 20:39:32 -0700 (PDT)
Subject: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <574FAB08.9000205@oracle.com>
References: <debc6713-f24e-4483-94fa-707853742266@default>
	<574FA81B.1040706@oracle.com> <574FAB08.9000205@oracle.com>
Message-ID: <569c3e80-d59e-4880-bcf4-11717fd5d821@default>

Hi, Phil.

Thanks for looking that this tiny change.

I agree with you regarding the usefulness of this tag, but I just noticed that they are @since tags exist for every single method in the class.  Since you are the owner of the code, it's your call to keep it or remove it.

Here's the alternative changeset with the @since tag removed:

src/java.desktop/macosx/classes/com/apple/eawt/Application.java
--- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java   Wed Jun 01 11:22:06 2016 -0700
+++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java   Thu Jun 02 20:35:37 2016 -0700
@@ -372,7 +372,6 @@
      * Acceptable values are from 0 to 100, any other disables progress indication.
      *
      * @param value progress value
-     * @since 1.9
      */
     public void setDockIconProgress(final int value) {
         iconHandler.setDockIconProgress(value);

I'll use this unless you instruct me otherwise.  As discussed today, the plan is to push this small change to jdk9/dev.

Thanks,
iris

-----Original Message-----
From: Philip Race 
Sent: Wednesday, June 01, 2016 8:42 PM
To: Iris Clark
Cc: awt-dev at openjdk.java.net; compiler-dev at openjdk.java.net
Subject: Re: <AWT Dev> RFR: 8158458: Update references from "1.9" to "9"

By which I mean "delete" is as good as "update'

-phil

On 6/1/16, 8:29 PM, Philip Race wrote:
> I don't see why @since matters on internal classes ...
>
> -phil.
>
> On 6/1/16, 6:17 PM, Iris Clark wrote:
>> Hi.
>>
>> I'm taking another pass at replacing instances of "@since 1.9" with 
>> "@since 9" and discovered a couple of jdk (AWT?) and langtools 
>> (DocTree) files which need to be updated.  I've filed the following 
>> but to address this problem:
>>
>>      8158458: Update references from "1.9" to "9" (closed code))
>>      https://bugs.openjdk.java.net/browse/JDK-8158458
>>
>> This is the necessary diff, against jdk9/dev:
>>
>> [/w/iclark/verona/javadoc/jdk]:
>> diff -r 0bd06ec69c5b
>> src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> Wed Jun 01 11:22:06 2016 -0700
>> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -372,7 +372,7 @@
>>    * Acceptable values are from 0 to 100, any other disables progress 
>> indication.
>>    *
>>    * @param value progress value
>> - * @since 1.9
>> + * @since 9
>>        */
>>       public void setDockIconProgress(final int value) {
>>           iconHandler.setDockIconProgress(value);
>>
>> [/w/iclark/verona/javadoc/langtools]:
>> diff -r 2d1a6b746310
>> src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
>> ---
>> a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.ja
>> va
>> Wed Jun 01 12:39:24 2016 +0100
>> +++ 
>> b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.ja
>> va
>> Wed Jun 01 17:40:09 2016 -0700
>> @@ -34,7 +34,7 @@
>>    *<p>
>>    *&#064;hidden
>>    *
>> - * @since 1.9
>> + * @since 9
>>    */
>>   public interface HiddenTree extends BlockTagTree {
>>       /**
>>
>> Build and test runs show no regressions.
>>
>> Thanks,
>> Iris

From joe.darcy at oracle.com  Mon Jun  6 16:15:34 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 6 Jun 2016 09:15:34 -0700
Subject: Why the annotation processing API ?
In-Reply-To: <7403843e-2298-b850-41c5-27550d7138d9@oracle.com>
References: <CALo37o6jy4xs6Ts7-opCJQuSFP_xKUGsvOPKZGmQiFH5r+ishQ@mail.gmail.com>
	<7403843e-2298-b850-41c5-27550d7138d9@oracle.com>
Message-ID: <44f3e3ca-b881-6944-3365-345eaf02004e@oracle.com>

PS A concrete example of the design benefits of javax.lang.model over 
core reflection is the relative ease of adding API support for type 
annotations to javax.lang.model compared to core reflection.

This example is discussed in the 2014 JavaOne talk "Enhanced Metadata in 
Java SE 8," starting around slide 22

https://blogs.oracle.com/darcy/resource/JavaOne/J1_2014-Metadata.pdf

and about minute 30 of the youtube video:

     https://youtu.be/Ri5D9oCwI2Q?t=1810

Cheers,

-Joe


On 5/26/2016 9:07 AM, joe darcy wrote:
>
> On 5/25/2016 9:32 PM, St?phane NICOLAS wrote:
>> Hi folks,
>>
>> I know a simple mail like this generally has very minimal value. But 
>> still, it's been around 2-3 years now that I work on Android, doing a 
>> lot of work around reflection and annotation processing.
>>
>> I don't like the annotation processing API. I still find every 
>> concept hard to remember, and it is always taking time to get 
>> immersed into it for a new project.
>>
>> Thus, I don't understand, very humbly and very honestly, why this API 
>> even exists. Why can't we simply use reflection-like APIs ? It would 
>> not be that complex to expose an API that looks like reflection 
>> (read-only of course, no new instance of classes, to method calls or 
>> setting/getting field values, just the discovery part).
>>
>
> The core reflection API has a number of serious design flaws, for a 
> detailed discussion see
>
> Gilad Bracha and David Ungar. Mirrors: Design Principles for 
> Meta-level Facilities of Object-Oriented Programming Languages. In 
> Proc. of the ACM Conf. on Object-Oriented Programming, Systems, 
> Languages and Applications, October 2004.
> http://www.bracha.org/mirrors.pdf
>
> With the benefit of hindsight, these problems were avoided in the 
> language model portion of the annotation processing API, 
> javax.lang.model.
>
> Cheers,
>
> -Joe


From felipepontes at copin.ufcg.edu.br  Tue Jun  7 13:48:43 2016
From: felipepontes at copin.ufcg.edu.br (Felipe Barros Pontes)
Date: Tue, 7 Jun 2016 10:48:43 -0300
Subject: Variable initialized but javac presents compilation error
Message-ID: <CAEuhyRQZxbE7fReEsXUE+OiNrk0FqWMP6PnUW8-wzwWAvXa+DA@mail.gmail.com>

Hi all.

   The Java Language Specification 8 presents in section 8.3.1.2
(final Fields) the following note: "A blank final instance variable
must be definitely assigned at the end of every constructor of the
class in which it is declared, or a compile-time error occurs..."

   In the following program the variable "x" is initialized at the end
of the constructor but javac presents a compilation error.

Program

	class A {
		final int x;
		A() {
			setX();
		}
		void setX() {
			this.x = 10;
		}
	}

Result

A.java:7: error: cannot assign a value to final variable x
			this.x = 10;
			    ^
1 error

   Shouldn't it be compiled successfully?


Best regards,

Felipe Pontes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160607/110d8257/attachment.html>

From forax at univ-mlv.fr  Tue Jun  7 13:57:12 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 7 Jun 2016 15:57:12 +0200 (CEST)
Subject: Variable initialized but javac presents compilation error
In-Reply-To: <CAEuhyRQZxbE7fReEsXUE+OiNrk0FqWMP6PnUW8-wzwWAvXa+DA@mail.gmail.com>
References: <CAEuhyRQZxbE7fReEsXUE+OiNrk0FqWMP6PnUW8-wzwWAvXa+DA@mail.gmail.com>
Message-ID: <1875191738.914378.1465307832548.JavaMail.zimbra@u-pem.fr>

Hi Felipe, 
given that setX() can be overriden in a subclass of A, your code is not safe. 

But it's not what the compiler detects, the compiler only checks that the final fields are initialized in the constructor, not in methods called by the constructor. 

cheers, 
R?mi 

----- Mail original -----

> De: "Felipe Barros Pontes" <felipepontes at copin.ufcg.edu.br>
> ?: compiler-dev at openjdk.java.net
> Envoy?: Mardi 7 Juin 2016 15:48:43
> Objet: Variable initialized but javac presents compilation error

> Hi all.
> The Java Language Specification 8 presents in section 8.3.1.2 (final Fields)
> the following note: "A blank final instance variable must be definitely
> assigned at the end of every constructor of the class in which it is
> declared, or a compile-time error occurs..."
> In the following program the variable "x" is initialized at the end of the
> constructor but javac presents a compilation error.
> Program

> class A {
> final int x;
> A() {
> setX();
> }
> void setX() {
> this.x = 10;
> }
> }

> Result

> A.java:7: error: cannot assign a value to final variable x
> this.x = 10;
> ^
> 1 error
> Shouldn't it be compiled successfully?

> Best regards,
> Felipe Pontes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160607/f689d378/attachment-0001.html>

From daniel.smith at oracle.com  Tue Jun  7 23:00:54 2016
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 7 Jun 2016 17:00:54 -0600
Subject: RFR: Tweaks to langtools/test/Makefile
Message-ID: <0FC65DA0-CC73-4100-B37A-6DDEE922DC0C@oracle.com>

I'd like to make the following tweaks to langtools/test/Makefile, mostly to make use via the top-level 'make test' command more convenient.  Any objections?  Can I get a reviewer approval?

Bug number JDK-8158992; some extra discussion there:
https://bugs.openjdk.java.net/browse/JDK-8158992

?Dan


diff -r e69e0ec39b92 test/Makefile
--- a/test/Makefile	Wed Jun 01 15:27:52 2016 -0700
+++ b/test/Makefile	Tue Jun 07 16:56:46 2016 -0600
@@ -84,12 +84,14 @@
 endif
 
 # Default JTREG to run
-ifdef JPRT_JTREG_HOME
-  JTREG_HOME = $(JPRT_JTREG_HOME)
-else ifdef JT_HOME
-  JTREG_HOME = $(JT_HOME)
-else
-  JTREG_HOME = $(SLASH_JAVA)/re/jtreg/4.1-jigsaw/nightly/binaries/jtreg/
+ifndef JTREG_HOME
+  ifdef JPRT_JTREG_HOME
+    JTREG_HOME = $(JPRT_JTREG_HOME)
+  else ifdef JT_HOME
+    JTREG_HOME = $(JT_HOME)
+  else
+    JTREG_HOME = $(SLASH_JAVA)/re/jtreg/4.1-jigsaw/nightly/binaries/jtreg/
+  endif
 endif
 JTREG = $(JTREG_HOME)/bin/jtreg
 JTDIFF = $(JTREG_HOME)/bin/jtdiff
@@ -105,10 +107,12 @@
 endif
 
 # Default JCK to run
-ifdef JPRT_JCK_HOME
-  JCK_HOME = $(JPRT_JCK_HOME)
-else
-  JCK_HOME = $(SLASH_JAVA)/re/jck/8/promoted/latest/binaries
+ifndef JCK_HOME
+  ifdef JPRT_JCK_HOME
+    JCK_HOME = $(JPRT_JCK_HOME)
+  else
+    JCK_HOME = $(SLASH_JAVA)/re/jck/8/promoted/latest/binaries
+  endif
 endif
 
 # Default JDK for JTREG and JCK
@@ -203,10 +207,10 @@
 endif
 
 # Default verbosity setting for jtreg
-JTREG_VERBOSE = fail,error,nopass
+JTREG_VERBOSE ?= fail,error,nopass
 
 # Default verbosity setting for jck
-JCK_VERBOSE = non-pass
+JCK_VERBOSE ?= non-pass
 
 # Assertions: some tests show failures when assertions are enabled.
 # Since javac is typically loaded via the bootclassloader (either via TESTJAVA
@@ -232,10 +236,6 @@
 # to a given level. Redefine function or preceding FATAL_*_EXIT codes as needed.
 EXIT_IF_FATAL = status=$$?; if [ $$status -ge $(1) ]; then exit $$status ; fi
 
-# The test directories to run
-DEFAULT_TESTDIRS = .
-TESTDIRS = $(DEFAULT_TESTDIRS)
-
 # Root of all test results
 TEST_OUTPUT_DIR = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH)/test/langtools
 ABS_TEST_OUTPUT_DIR := \
@@ -260,9 +260,17 @@
 jck-runtime: $(JPRT_CLEAN) jck-runtime-tests $(JPRT_ARCHIVE_BUNDLE) jck-runtime-summary
 	@echo "Testing completed successfully"
 
+# a way to select tests from outside
+# works for targets 'jtreg', 'jck-compiler', and 'jck-runtime'
+ifdef TEST_SELECTION
+  JTREG_TESTDIRS = $(TEST_SELECTION)
+  JCK_COMPILER_TESTDIRS = $(TEST_SELECTION)
+  JCK_RUNTIME_TESTDIRS = $(TEST_SELECTION)
+endif
+
 # for use with JPRT -testrule
 all:		JTREG_TESTDIRS = .
-jtreg:		JTREG_TESTDIRS = .
+jtreg:		JTREG_TESTDIRS ?= .
 apt:		JTREG_TESTDIRS = tools/apt
 javac: 		JTREG_TESTDIRS = tools/javac
 javadoc:	JTREG_TESTDIRS = tools/javadoc com/sun/javadoc
@@ -270,11 +278,6 @@
 javap:		JTREG_TESTDIRS = tools/javap
 jdeps:		JTREG_TESTDIRS = tools/jdeps
 
-# a way to select jtreg tests from outside
-ifdef TEST_SELECTION
-  JTREG_TESTDIRS = $(TEST_SELECTION)
-endif
-
 
 # Run jtreg tests
 #
@@ -438,11 +441,11 @@
 
 # Check to make sure these directories exist
 check-jck:
-	if [ ! -d '$(JCK_HOME)' ]; then \
+	@if [ ! -d '$(JCK_HOME)' ]; then \
 	    echo "JCK_HOME $(JCK_HOME) missing" ; \
 	    $(EXIT) 1 ; \
 	fi
-	if [ ! -d '$(PRODUCT_HOME)' ]; then \
+	@if [ ! -d '$(PRODUCT_HOME)' ]; then \
 	    echo "PRODUCT_HOME $(PRODUCT_HOME) missing" ; \
 	    $(EXIT) 1 ; \
 	fi


From shafi.s.ahmad at oracle.com  Wed Jun  8 05:20:59 2016
From: shafi.s.ahmad at oracle.com (Shafi Ahmad)
Date: Tue, 7 Jun 2016 22:20:59 -0700 (PDT)
Subject: Variable initialized but javac presents compilation error
In-Reply-To: <CAEuhyRQZxbE7fReEsXUE+OiNrk0FqWMP6PnUW8-wzwWAvXa+DA@mail.gmail.com>
References: <CAEuhyRQZxbE7fReEsXUE+OiNrk0FqWMP6PnUW8-wzwWAvXa+DA@mail.gmail.com>
Message-ID: <2b864292-36b5-407d-97fb-2d8a010107cc@default>

Hi Felip,

?

I am not a java language expert but trying to answer your query.

It seems to me that the javac compiler error is perfectly correct. 

?

?instance variable must be definitely assigned at the end of every constructor of the class in which it is declared?

?

It should be assigned directly or through the instance initialization block only not indirectly through ?method call. 

?

Suppose the compiler compiles your code successfully, in that case how compiler restrict that your method setX() is getting called exactly once otherwise attribute final will lose its meaning.

?

To avoid such ambiguity the compiler doesn?t allow final variable initialization inside method and even inside try block within a constructor. 

?

import java.io.*;

import java.util.*;

public class ObjIn {

??? final int x;

??? public ObjIn() {

??????? ObjectInputStream s = null;

??????? // x = 10; // No error

??????? try {

??????????? x = 10;? // Error

??????????? FileInputStream f = new FileInputStream ("date.ser");

??????????? s = new ObjectInputStream (f);

??????? }

??????? catch (IOException e) {

??????????? e.printStackTrace();

??????? }

??? } 

????public static void main (String args[]) {

??????? new ObjIn();

??? }

}

?

Regards,

Shafi

?

?

?

From: Felipe Barros Pontes [mailto:felipepontes at copin.ufcg.edu.br] 
Sent: Tuesday, June 07, 2016 7:19 PM
To: compiler-dev at openjdk.java.net
Subject: Variable initialized but javac presents compilation error

?

Hi all.
?
?? The Java Language Specification 8 presents in section 8.3.1.2 (final Fields) the following note: "A blank final instance variable must be definitely assigned at the end of every constructor of the class in which it is declared, or a compile-time error occurs..."
?? In the following program the variable "x" is initialized at the end of the constructor but javac presents a compilation error.
?
Program
?
?????????????? class A {
?????????????????????????????? final int x;
?????????????????????????????? A() {
????????????????????????????????????????????? setX();
?????????????????????????????? }
?????????????????????????????? void setX() {
????????????????????????????????????????????? this.x = 10;
?????????????????????????????? }
?????????????? }
?
Result
?
A.java:7: error: cannot assign a value to final variable x
????????????????????????????????????????????? this.x = 10;
????????????????????????????????????????????? ??? ^
1 error
?? Shouldn't it be compiled successfully?
?
Best regards,

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

From daniel.smith at oracle.com  Wed Jun  8 21:02:33 2016
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 8 Jun 2016 15:02:33 -0600
Subject: RFR: Tweaks to langtools/test/Makefile
In-Reply-To: <0FC65DA0-CC73-4100-B37A-6DDEE922DC0C@oracle.com>
References: <0FC65DA0-CC73-4100-B37A-6DDEE922DC0C@oracle.com>
Message-ID: <370A7E84-9F3B-4306-A428-DAF733F5F0D2@oracle.com>

> On Jun 7, 2016, at 5:00 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> I'd like to make the following tweaks to langtools/test/Makefile, mostly to make use via the top-level 'make test' command more convenient.  Any objections?  Can I get a reviewer approval?
> 
> Bug number JDK-8158992; some extra discussion there:
> https://bugs.openjdk.java.net/browse/JDK-8158992

Updated patch below -- Jon suggested updating the default JTREG_HOME, as it's out of date.

?Dan


diff -r e69e0ec39b92 test/Makefile
--- a/test/Makefile	Wed Jun 01 15:27:52 2016 -0700
+++ b/test/Makefile	Wed Jun 08 15:01:05 2016 -0600
@@ -84,12 +84,14 @@
 endif
 
 # Default JTREG to run
-ifdef JPRT_JTREG_HOME
-  JTREG_HOME = $(JPRT_JTREG_HOME)
-else ifdef JT_HOME
-  JTREG_HOME = $(JT_HOME)
-else
-  JTREG_HOME = $(SLASH_JAVA)/re/jtreg/4.1-jigsaw/nightly/binaries/jtreg/
+ifndef JTREG_HOME
+  ifdef JPRT_JTREG_HOME
+    JTREG_HOME = $(JPRT_JTREG_HOME)
+  else ifdef JT_HOME
+    JTREG_HOME = $(JT_HOME)
+  else
+    JTREG_HOME = $(SLASH_JAVA)/re/jtreg/4.2/promoted/latest/
+  endif
 endif
 JTREG = $(JTREG_HOME)/bin/jtreg
 JTDIFF = $(JTREG_HOME)/bin/jtdiff
@@ -105,10 +107,12 @@
 endif
 
 # Default JCK to run
-ifdef JPRT_JCK_HOME
-  JCK_HOME = $(JPRT_JCK_HOME)
-else
-  JCK_HOME = $(SLASH_JAVA)/re/jck/8/promoted/latest/binaries
+ifndef JCK_HOME
+  ifdef JPRT_JCK_HOME
+    JCK_HOME = $(JPRT_JCK_HOME)
+  else
+    JCK_HOME = $(SLASH_JAVA)/re/jck/8/promoted/latest/binaries
+  endif
 endif
 
 # Default JDK for JTREG and JCK
@@ -203,10 +207,10 @@
 endif
 
 # Default verbosity setting for jtreg
-JTREG_VERBOSE = fail,error,nopass
+JTREG_VERBOSE ?= fail,error,nopass
 
 # Default verbosity setting for jck
-JCK_VERBOSE = non-pass
+JCK_VERBOSE ?= non-pass
 
 # Assertions: some tests show failures when assertions are enabled.
 # Since javac is typically loaded via the bootclassloader (either via TESTJAVA
@@ -232,10 +236,6 @@
 # to a given level. Redefine function or preceding FATAL_*_EXIT codes as needed.
 EXIT_IF_FATAL = status=$$?; if [ $$status -ge $(1) ]; then exit $$status ; fi
 
-# The test directories to run
-DEFAULT_TESTDIRS = .
-TESTDIRS = $(DEFAULT_TESTDIRS)
-
 # Root of all test results
 TEST_OUTPUT_DIR = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH)/test/langtools
 ABS_TEST_OUTPUT_DIR := \
@@ -260,9 +260,17 @@
 jck-runtime: $(JPRT_CLEAN) jck-runtime-tests $(JPRT_ARCHIVE_BUNDLE) jck-runtime-summary
 	@echo "Testing completed successfully"
 
+# a way to select tests from outside
+# works for targets 'jtreg', 'jck-compiler', and 'jck-runtime'
+ifdef TEST_SELECTION
+  JTREG_TESTDIRS = $(TEST_SELECTION)
+  JCK_COMPILER_TESTDIRS = $(TEST_SELECTION)
+  JCK_RUNTIME_TESTDIRS = $(TEST_SELECTION)
+endif
+
 # for use with JPRT -testrule
 all:		JTREG_TESTDIRS = .
-jtreg:		JTREG_TESTDIRS = .
+jtreg:		JTREG_TESTDIRS ?= .
 apt:		JTREG_TESTDIRS = tools/apt
 javac: 		JTREG_TESTDIRS = tools/javac
 javadoc:	JTREG_TESTDIRS = tools/javadoc com/sun/javadoc
@@ -270,11 +278,6 @@
 javap:		JTREG_TESTDIRS = tools/javap
 jdeps:		JTREG_TESTDIRS = tools/jdeps
 
-# a way to select jtreg tests from outside
-ifdef TEST_SELECTION
-  JTREG_TESTDIRS = $(TEST_SELECTION)
-endif
-
 
 # Run jtreg tests
 #
@@ -438,11 +441,11 @@
 
 # Check to make sure these directories exist
 check-jck:
-	if [ ! -d '$(JCK_HOME)' ]; then \
+	@if [ ! -d '$(JCK_HOME)' ]; then \
 	    echo "JCK_HOME $(JCK_HOME) missing" ; \
 	    $(EXIT) 1 ; \
 	fi
-	if [ ! -d '$(PRODUCT_HOME)' ]; then \
+	@if [ ! -d '$(PRODUCT_HOME)' ]; then \
 	    echo "PRODUCT_HOME $(PRODUCT_HOME) missing" ; \
 	    $(EXIT) 1 ; \
 	fi


From jonathan.gibbons at oracle.com  Wed Jun  8 21:18:50 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 08 Jun 2016 14:18:50 -0700
Subject: RFR: Tweaks to langtools/test/Makefile
In-Reply-To: <370A7E84-9F3B-4306-A428-DAF733F5F0D2@oracle.com>
References: <0FC65DA0-CC73-4100-B37A-6DDEE922DC0C@oracle.com>
	<370A7E84-9F3B-4306-A428-DAF733F5F0D2@oracle.com>
Message-ID: <57588BBA.3010207@oracle.com>

Looks good, but in time, we should look to align the various 
test/Makefiles with similar paradigms and features.

-- Jon

On 06/08/2016 02:02 PM, Dan Smith wrote:
>> On Jun 7, 2016, at 5:00 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>>
>> I'd like to make the following tweaks to langtools/test/Makefile, mostly to make use via the top-level 'make test' command more convenient.  Any objections?  Can I get a reviewer approval?
>>
>> Bug number JDK-8158992; some extra discussion there:
>> https://bugs.openjdk.java.net/browse/JDK-8158992
> Updated patch below -- Jon suggested updating the default JTREG_HOME, as it's out of date.
>
> ?Dan
>
>
> diff -r e69e0ec39b92 test/Makefile
> --- a/test/Makefile	Wed Jun 01 15:27:52 2016 -0700
> +++ b/test/Makefile	Wed Jun 08 15:01:05 2016 -0600
> @@ -84,12 +84,14 @@
>   endif
>   
>   # Default JTREG to run
> -ifdef JPRT_JTREG_HOME
> -  JTREG_HOME = $(JPRT_JTREG_HOME)
> -else ifdef JT_HOME
> -  JTREG_HOME = $(JT_HOME)
> -else
> -  JTREG_HOME = $(SLASH_JAVA)/re/jtreg/4.1-jigsaw/nightly/binaries/jtreg/
> +ifndef JTREG_HOME
> +  ifdef JPRT_JTREG_HOME
> +    JTREG_HOME = $(JPRT_JTREG_HOME)
> +  else ifdef JT_HOME
> +    JTREG_HOME = $(JT_HOME)
> +  else
> +    JTREG_HOME = $(SLASH_JAVA)/re/jtreg/4.2/promoted/latest/
> +  endif
>   endif
>   JTREG = $(JTREG_HOME)/bin/jtreg
>   JTDIFF = $(JTREG_HOME)/bin/jtdiff
> @@ -105,10 +107,12 @@
>   endif
>   
>   # Default JCK to run
> -ifdef JPRT_JCK_HOME
> -  JCK_HOME = $(JPRT_JCK_HOME)
> -else
> -  JCK_HOME = $(SLASH_JAVA)/re/jck/8/promoted/latest/binaries
> +ifndef JCK_HOME
> +  ifdef JPRT_JCK_HOME
> +    JCK_HOME = $(JPRT_JCK_HOME)
> +  else
> +    JCK_HOME = $(SLASH_JAVA)/re/jck/8/promoted/latest/binaries
> +  endif
>   endif
>   
>   # Default JDK for JTREG and JCK
> @@ -203,10 +207,10 @@
>   endif
>   
>   # Default verbosity setting for jtreg
> -JTREG_VERBOSE = fail,error,nopass
> +JTREG_VERBOSE ?= fail,error,nopass
>   
>   # Default verbosity setting for jck
> -JCK_VERBOSE = non-pass
> +JCK_VERBOSE ?= non-pass
>   
>   # Assertions: some tests show failures when assertions are enabled.
>   # Since javac is typically loaded via the bootclassloader (either via TESTJAVA
> @@ -232,10 +236,6 @@
>   # to a given level. Redefine function or preceding FATAL_*_EXIT codes as needed.
>   EXIT_IF_FATAL = status=$$?; if [ $$status -ge $(1) ]; then exit $$status ; fi
>   
> -# The test directories to run
> -DEFAULT_TESTDIRS = .
> -TESTDIRS = $(DEFAULT_TESTDIRS)
> -
>   # Root of all test results
>   TEST_OUTPUT_DIR = $(TEST_ROOT)/../build/$(PLATFORM)-$(ARCH)/test/langtools
>   ABS_TEST_OUTPUT_DIR := \
> @@ -260,9 +260,17 @@
>   jck-runtime: $(JPRT_CLEAN) jck-runtime-tests $(JPRT_ARCHIVE_BUNDLE) jck-runtime-summary
>   	@echo "Testing completed successfully"
>   
> +# a way to select tests from outside
> +# works for targets 'jtreg', 'jck-compiler', and 'jck-runtime'
> +ifdef TEST_SELECTION
> +  JTREG_TESTDIRS = $(TEST_SELECTION)
> +  JCK_COMPILER_TESTDIRS = $(TEST_SELECTION)
> +  JCK_RUNTIME_TESTDIRS = $(TEST_SELECTION)
> +endif
> +
>   # for use with JPRT -testrule
>   all:		JTREG_TESTDIRS = .
> -jtreg:		JTREG_TESTDIRS = .
> +jtreg:		JTREG_TESTDIRS ?= .
>   apt:		JTREG_TESTDIRS = tools/apt
>   javac: 		JTREG_TESTDIRS = tools/javac
>   javadoc:	JTREG_TESTDIRS = tools/javadoc com/sun/javadoc
> @@ -270,11 +278,6 @@
>   javap:		JTREG_TESTDIRS = tools/javap
>   jdeps:		JTREG_TESTDIRS = tools/jdeps
>   
> -# a way to select jtreg tests from outside
> -ifdef TEST_SELECTION
> -  JTREG_TESTDIRS = $(TEST_SELECTION)
> -endif
> -
>   
>   # Run jtreg tests
>   #
> @@ -438,11 +441,11 @@
>   
>   # Check to make sure these directories exist
>   check-jck:
> -	if [ ! -d '$(JCK_HOME)' ]; then \
> +	@if [ ! -d '$(JCK_HOME)' ]; then \
>   	    echo "JCK_HOME $(JCK_HOME) missing" ; \
>   	    $(EXIT) 1 ; \
>   	fi
> -	if [ ! -d '$(PRODUCT_HOME)' ]; then \
> +	@if [ ! -d '$(PRODUCT_HOME)' ]; then \
>   	    echo "PRODUCT_HOME $(PRODUCT_HOME) missing" ; \
>   	    $(EXIT) 1 ; \
>   	fi
>


From kumar.x.srinivasan at oracle.com  Fri Jun 10 17:51:28 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 10 Jun 2016 10:51:28 -0700
Subject: RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <debc6713-f24e-4483-94fa-707853742266@default>
References: <debc6713-f24e-4483-94fa-707853742266@default>
Message-ID: <575AFE20.7080607@oracle.com>


Hi Iris,

Apologies for the tardy reply, the HiddenTree change looks fine.

Thanks
Kumar

> Hi.
>
> I'm taking another pass at replacing instances of "@since 1.9" with
> "@since 9" and discovered a couple of jdk (AWT?) and langtools (DocTree)
> files which need to be updated.  I've filed the following but to
> address this problem:
>
>      8158458: Update references from "1.9" to "9" (closed code))
>      https://bugs.openjdk.java.net/browse/JDK-8158458
>
> This is the necessary diff, against jdk9/dev:
>
> [/w/iclark/verona/javadoc/jdk]:
> diff -r 0bd06ec69c5b src/java.desktop/macosx/classes/com/apple/eawt/Application.java
> --- a/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 11:22:06 2016 -0700
> +++ b/src/java.desktop/macosx/classes/com/apple/eawt/Application.java Wed Jun 01 17:40:09 2016 -0700
> @@ -372,7 +372,7 @@
>    * Acceptable values are from 0 to 100, any other disables progress indication.
>    *
>    * @param value progress value
> - * @since 1.9
> + * @since 9
>        */
>       public void setDockIconProgress(final int value) {
>           iconHandler.setDockIconProgress(value);
>
> [/w/iclark/verona/javadoc/langtools]:
> diff -r 2d1a6b746310 src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java
> --- a/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 12:39:24 2016 +0100
> +++ b/src/jdk.compiler/share/classes/com/sun/source/doctree/HiddenTree.java Wed Jun 01 17:40:09 2016 -0700
> @@ -34,7 +34,7 @@
>    * <p>
>    * &#064;hidden
>    *
> - * @since 1.9
> + * @since 9
>    */
>   public interface HiddenTree extends BlockTagTree {
>       /**
>
> Build and test runs show no regressions.
>
> Thanks,
> Iris


From iris.clark at oracle.com  Fri Jun 10 21:46:09 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 10 Jun 2016 14:46:09 -0700 (PDT)
Subject: RFR: 8158458: Update references from "1.9" to "9"
In-Reply-To: <575AFE20.7080607@oracle.com>
References: <debc6713-f24e-4483-94fa-707853742266@default>
	<575AFE20.7080607@oracle.com>
Message-ID: <445042d0-bba1-4d2f-bcdd-ae8a8be0c9ea@default>

Hi, Kumar.

Thanks for the Review.  

I think this change is now ready to push.  Jon has graciously offered to push these changes to jdk9/dev.

Regards,
iris

-----Original Message-----
From: Kumar Srinivasan 
Sent: Friday, June 10, 2016 10:51 AM
To: Iris Clark
Cc: compiler-dev at openjdk.java.net; awt-dev at openjdk.java.net
Subject: Re: RFR: 8158458: Update references from "1.9" to "9"


Hi Iris,

Apologies for the tardy reply, the HiddenTree change looks fine.

Thanks
Kumar

From brucechapman at paradise.net.nz  Sat Jun 11 01:56:36 2016
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Sat, 11 Jun 2016 13:56:36 +1200
Subject: JDK 9 request for specification changes of JDK-8032230: Enhance
	javax.a.p.RoundEnvironment after repeating annotations
In-Reply-To: <0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com>
References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com>
	<573CCB24.2030705@oracle.com>
	<590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com>
	<573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@oracle.com>
	<4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com>
	<0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com>
Message-ID: <bb8ab2bf-4ded-7895-f170-78fe27215034@paradise.net.nz>

Joe,

Just catching up on some reading, so this thread might be a bit stale now.

Anyway - your javadoc for both methods still talks about the argument 
*set* in the @implSpec, which is now no longer a set since you changed 
it to varargs.

Otherwise it looks good.

Bruce


On 25/05/2016 4:18 a.m., joe darcy wrote:
> Updated webrev:
>
>     http://cr.openjdk.java.net/~darcy/8032230.1/
>
> Now with specialized implementation in javac's implementation of
> RoundEnvironment and separate tests of the default methods in the
> interface and the javac implementation.
>
> Thanks,
>
> -Joe
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From joe.darcy at oracle.com  Sat Jun 11 19:23:53 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Sat, 11 Jun 2016 12:23:53 -0700
Subject: JDK 9 request for specification changes of JDK-8032230: Enhance
	javax.a.p.RoundEnvironment after repeating annotations
In-Reply-To: <bb8ab2bf-4ded-7895-f170-78fe27215034@paradise.net.nz>
References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com>
	<573CCB24.2030705@oracle.com>
	<590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com>
	<573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@oracle.com>
	<4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com>
	<0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com>
	<bb8ab2bf-4ded-7895-f170-78fe27215034@paradise.net.nz>
Message-ID: <35d6fba5-e499-e5f9-1f42-43e3e6e41b53@oracle.com>

Hi Bruce,

Thanks for the careful reading. Good catch on using "set" to describe 
the varargs array. To address this I propose the following patch which 
changes "set" to "array" for the one overload of 
getElementsAnnotatedWithAny which uses varargs:

--- 
a/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java 
Thu Jun 02 17:31:38 2016 -0700
+++ 
b/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java 
Sat Jun 11 12:18:44 2016 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2005, 2007, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2016, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -103,7 +103,7 @@
       *
       * @implSpec The default implementation of this method creates an
       * empty result set, iterates over the annotations in the argument
-     * set calling {@link #getElementsAnnotatedWith(TypeElement)} on
+     * array calling {@link #getElementsAnnotatedWith(TypeElement)} on
       * each annotation and adding those results to the result
       * set. Finally, the contents of the result set are returned as an
       * unmodifiable set.

-Joe


On 6/10/2016 6:56 PM, Bruce Chapman wrote:
> Joe,
>
> Just catching up on some reading, so this thread might be a bit stale 
> now.
>
> Anyway - your javadoc for both methods still talks about the argument 
> *set* in the @implSpec, which is now no longer a set since you changed 
> it to varargs.
>
> Otherwise it looks good.
>
> Bruce
>
>
> On 25/05/2016 4:18 a.m., joe darcy wrote:
>> Updated webrev:
>>
>>     http://cr.openjdk.java.net/~darcy/8032230.1/
>>
>> Now with specialized implementation in javac's implementation of
>> RoundEnvironment and separate tests of the default methods in the
>> interface and the javac implementation.
>>
>> Thanks,
>>
>> -Joe
>>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>


From joe.darcy at oracle.com  Mon Jun 13 05:46:15 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Sun, 12 Jun 2016 22:46:15 -0700
Subject: JDK 9 RFR of JDK-8155880: Fix langtools usage of the deprecated
	Class.newInstance method
Message-ID: <f2b9ca9c-478b-fc4d-5c0d-bc92ffb9358f@oracle.com>

Hello,

Please review the changes to fix

     JDK-8155880: Fix langtools usage of the deprecated 
Class.newInstance method
     http://cr.openjdk.java.net/~darcy/8155880.1/

All langtools regression tests pass with this patch.

Thanks,

-Joe


From maurizio.cimadamore at oracle.com  Mon Jun 13 10:00:10 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 13 Jun 2016 11:00:10 +0100
Subject: JDK 9 RFR of JDK-8155880: Fix langtools usage of the deprecated
	Class.newInstance method
In-Reply-To: <f2b9ca9c-478b-fc4d-5c0d-bc92ffb9358f@oracle.com>
References: <f2b9ca9c-478b-fc4d-5c0d-bc92ffb9358f@oracle.com>
Message-ID: <575E842A.2090603@oracle.com>

Looks good

Maurizio


On 13/06/16 06:46, joe darcy wrote:
> Hello,
>
> Please review the changes to fix
>
>     JDK-8155880: Fix langtools usage of the deprecated 
> Class.newInstance method
>     http://cr.openjdk.java.net/~darcy/8155880.1/
>
> All langtools regression tests pass with this patch.
>
> Thanks,
>
> -Joe
>


From bsrbnd at gmail.com  Mon Jun 13 10:35:55 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Mon, 13 Jun 2016 12:35:55 +0200
Subject: Symbolic annotation processor
In-Reply-To: <CAEgw74BE3r36KAX2aVs9B0tJ30T_4H9=yq2pAC7=DvOSm7YHaw@mail.gmail.com>
References: <CAEgw74BztdzFb7ZcgHs4rvWtD8aqKdn_TSGuZjFtidyaUyHAYw@mail.gmail.com>
	<CAEgw74BERMwvfAzXJEu_W6daN1L+tJABmBWGNu9q38+taOHorQ@mail.gmail.com>
	<CAEgw74BE3r36KAX2aVs9B0tJ30T_4H9=yq2pAC7=DvOSm7YHaw@mail.gmail.com>
Message-ID: <CAEgw74BpzpSMqaTQxNr7wMkw_C3YzFQqq3hc=s-6duu8mU+k1g@mail.gmail.com>

Hi,

As we all know, many numerical methods involve the derivative
computation of a function; Newton's method to solve a non-linear
equation, for example.
Using an imperative language, we would probably compute an
approximation of the derivative, which could be slow and probably
inaccurate.
But with symbolic expressions, we are able to compute the symbolic
form of the derivative directly, which is much faster and is an
absolutely correct solution.

I haven't written any example for that yet, but you can refer to John
McCarthy's paper: "Recursive Functions of Symbolic Expressions and
Their Computation by Machine, Part I", Massachusetts Institute of
Technology, Cambridge, Mass., April 1960, chapter 3.g on page 21;
which can be found at:
http://www-formal.stanford.edu/jmc/

In addition to previous discussions, this example shows a bit more the
benefits of symbolic programming.

Notice that I've also updated the genetic programming example
(presented in the previous email below) to link lambda to symbolic
expressions and to use the existing functional API.

Do you think it could be interesting to create an OpenJDK project to
study more about this subject?

Thanks,

Bernard

2016-04-03 13:16 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
> Hi,
>
> I wrote a simple genetic programming example (a symbolic regression)
> using SymProc, here:
> https://github.com/bsrbnd/draft/blob/master/src/examples/GeneticProgramming.java
>
> As we can see, symbolic programming could be also the basements for
> functional programming.
> Notice, for example, the ease of the computation of the integral of
> the absolute difference between two functions:
>
> private Double fitness(Symbol<?> $f) throws Exception {
>     return integral(LOWER_BOUND, UPPER_BOUND,
> $abs.apply($sub.apply($f,$target)));
> }
>
> Regards,
>
> Bernard
>
> 2016-03-17 12:26 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> After a very fast and superficial reading of the JLS, I wrote some
>> jtreg tests for points that might be impacted
>> by the symbolic-processor. Source code of the tests, grouped in two
>> files for more readability, can be found at:
>> https://github.com/bsrbnd/draft/tree/master/src/tests
>>
>> Some of them show a bit more precisely the benefit of incorporating in
>> some way the symbolic programming paradigm
>> (the ability to manipulate the symbols of a language) to enhance the
>> reflection (and perhaps even more...).
>>
>> As generics are earased during runtime, it could be hard to get the
>> reflective elements of members using generics
>> heavily (and even harder to maintain).
>> Consider the following example inspired by JLS8, chapter 4.4:
>>
>> class MyTypeVariable {
>>     public static class C {}
>>     public static interface I {}
>>
>>     @Symbolic private <T extends C & I> void myMethod(T t, T[] u) {}
>> }
>>
>> Without the symbolic view of members, you have to write something like
>> the following to get the reflective object:
>> Method m = MyTypeVariable.class.getDeclaredMethod("myMethod",
>> MyTypeVariable.C.class,
>> MyTypeVariable.C[].class));
>>
>> But, with the symbolic-processor, you delegate the generics and
>> erasures handling to the compiler:
>> Method m = MyTypeVariable.$myMethod.reflect();
>>
>> This is, of course, easier to write and to maintain.
>>
>> I've also tried to go further with this paradigm by introducing
>> dynamically constructed symbolic expressions
>> (a bit like LISP does) and evaluate them on a particular instance, for example:
>>
>> class DynamicExpression {
>>     @Symbolic private Integer a = 3;
>>     @Symbolic private Integer b = 2;
>>     @Symbolic private Integer c = 1;
>>
>>     @Symbolic public Integer add(Integer i, Integer j) {return i + j;}
>>     @Symbolic public Integer sub(Integer i, Integer j) {return i - j;}
>> }
>>
>> MethodSymbol $symbolicExpression = $add.apply($a, $sub.apply($b, $c));
>> Integer d = (Integer)$symbolicExpression.evaluate(new DynamicExpression());
>>
>> This expression evaluates naturally to 4 for this instance.
>>
>> The full running example can be found at:
>> https://github.com/bsrbnd/draft/blob/master/src/examples/DynamicExpression.java
>>
>> Symbolic expressions could be useful for evolutionary algorithms used
>> in genetic programming, where dynamic
>> expressions are iteratively crossed-over and mutated to find the best
>> approximation of a solution.
>>
>> I hope that I didn't miss anything in the JLS and that something like
>> this hasn't already been incorporated
>> in any existing project.
>>
>> Regards,
>>
>> Bernard
>>
>> 2015-12-10 14:50 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>>> Hi,
>>>
>>> Following our discussion (October 2015), I wrote an
>>> annotation-processor (only a draft for now) that gives a symbolic view
>>> of class members, for example:
>>> @Symbolic private Object myField;
>>> @Symbolic("_") private void myMethod(Object param) {}
>>>
>>> We can either access the name or the reflective object of members the
>>> following way:
>>> String name = $myField.toString(); // $ is the default prefix
>>> Method m = _myMethod.reflect(); // _ is a custom prefix, useful for
>>> overloaded identifiers
>>>
>>> You can find a simple example here:
>>> https://github.com/bsrbnd/draft/blob/master/src/examples/Example.java
>>>
>>> Full source code of the annotation-processor prototype is given there:
>>> https://github.com/bsrbnd/draft
>>>
>>> Comments are welcome, but I know this is probably not the right
>>> mailing-list for that.
>>>
>>> Regards,
>>>
>>> Bernard

From jan.lahoda at oracle.com  Mon Jun 13 16:12:12 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 13 Jun 2016 18:12:12 +0200
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types
	which are not accessible
Message-ID: <575EDB5C.5060601@oracle.com>

Hello,

There is:
https://bugs.openjdk.java.net/browse/JDK-8153362

which is about a new warning that should be produced by javac when 
exported API refers to types not exported/accessible to the API clients.

I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/

There are some warnings produced for existing code in the hotspot and 
jdk repositories (see the end for the warnings), I was using these 
patches to keep JDK buildable:
hotspot repository:
http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
jdk repository:
http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/

Any help with those (esp. those in the hotspot repository) would be 
wholeheartedly welcome.

Any feedback on this is welcome!

Thanks,
    Jan

The warnings:
-hotspot repository:
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API
     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
                     ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API
     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
                                                  ^
error: warnings found and -Werror specified
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54: 
warning: unexported type referenced in exported API
     public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
                                              ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73: 
warning: unexported type referenced in exported API
     public int adjustCompilationLevel(HotSpotVMConfig config, Class<?> 
declaringClass, String name, String signature, boolean isOsr, int level) {
                                       ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
     public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {
                               ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
     public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {

           ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
     public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {

                                        ^
1 error
7 warnings

-jdk/java.desktop:
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333: 
warning: inaccessible type referenced in exported API
     protected DefaultAction defaultPressAction;
               ^
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344: 
warning: inaccessible type referenced in exported API
     protected DefaultAction defaultReleaseAction;
               ^
error: warnings found and -Werror specified
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742: 
warning: inaccessible type referenced in exported API
         protected MetalBumps bumps = new MetalBumps( 10, 10,
                   ^
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java:926: 
warning: inaccessible type referenced in exported API
     protected DirectoryComboBoxRenderer 
createDirectoryComboBoxRenderer(JFileChooser fc) {
               ^
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollBarUI.java:65: 
warning: inaccessible type referenced in exported API
     protected MetalBumps bumps;
               ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
5 warnings


-jdk/java.naming:
.../jdk/src/java.naming/share/classes/javax/naming/CompoundName.java:156: warning: 
inaccessible type referenced in exported API
     protected transient NameImpl impl;
                         ^
error: warnings found and -Werror specified
1 error
1 warning


-jdk/jdk.accessibility:
.../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java:219: 
warning: inaccessible type referenced in exported API
     static protected AWTEventsListener awtListener = new 
AWTEventsListener();
                      ^
error: warnings found and -Werror specified
.../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java:66: 
warning: inaccessible type referenced in exported API
     static protected final AccessibilityEventListener 
accessibilityListener =
                            ^
.../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java:74: 
warning: inaccessible type referenced in exported API
     static protected final SwingEventListener swingListener = new 
SwingEventListener();
                            ^
1 error
3 warnings


-jdk/jdk.jsobject:
.../jdk/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java:153: 
warning: type from a module referenced in exported API that is not 
requires public from this module
     public static JSObject getWindow(Applet applet) throws JSException {
                                      ^
error: warnings found and -Werror specified
1 error
1 warning

-jdk/jdk.security.jgss:
.../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:42: 
warning: type that is invisible for some modules which read this package 
referenced in exported API
     static class ExtendedGSSContextImpl extends GSSContextImpl
                                                 ^
.../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:45: 
warning: type that is invisible for some modules which read this package 
referenced in exported API
         public ExtendedGSSContextImpl(GSSContextImpl old) {
                                       ^
error: warnings found and -Werror specified
.../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:38: 
warning: type that is invisible for some modules which read this package 
referenced in exported API
     static class ExtendedGSSCredentialImpl extends GSSCredentialImpl
                                                    ^
.../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:41: 
warning: type that is invisible for some modules which read this package 
referenced in exported API
         public ExtendedGSSCredentialImpl(GSSCredentialImpl old) {
                                          ^
1 error
4 warnings

From joe.darcy at oracle.com  Mon Jun 13 16:39:59 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 13 Jun 2016 09:39:59 -0700
Subject: JDK 9 request for specification changes of JDK-8032230: Enhance
	javax.a.p.RoundEnvironment after repeating annotations
In-Reply-To: <35d6fba5-e499-e5f9-1f42-43e3e6e41b53@oracle.com>
References: <2f908c4d-bbfc-f42b-8728-6e2bf806c3a6@oracle.com>
	<573CCB24.2030705@oracle.com>
	<590ed79c-51a6-7cf3-3f5c-c088fab06574@oracle.com>
	<573CD515.4090602@oracle.com> <573CD6BA.2030202@oracle.com>
	<b640ee83-1e6d-39b9-4c82-89ab7ec38b87@oracle.com>
	<4ade37d0-bedb-64d5-250a-ac5f40725d2b@oracle.com>
	<0e72d560-d8a5-0583-513d-a44d3f330dfd@oracle.com>
	<bb8ab2bf-4ded-7895-f170-78fe27215034@paradise.net.nz>
	<35d6fba5-e499-e5f9-1f42-43e3e6e41b53@oracle.com>
Message-ID: <f59d505d-5bee-2fb0-c3b6-5cf1fa02d5d7@oracle.com>

Fixed under

     8159378: Correct wording of 
RoundEnvironment.getElementsAnnotatedWithAny
     http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d0c742ddfb01

Thanks,

-Joe


On 6/11/2016 12:23 PM, joe darcy wrote:
> Hi Bruce,
>
> Thanks for the careful reading. Good catch on using "set" to describe 
> the varargs array. To address this I propose the following patch which 
> changes "set" to "array" for the one overload of 
> getElementsAnnotatedWithAny which uses varargs:
>
> --- 
> a/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java 
> Thu Jun 02 17:31:38 2016 -0700
> +++ 
> b/src/java.compiler/share/classes/javax/annotation/processing/RoundEnvironment.java 
> Sat Jun 11 12:18:44 2016 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2005, 2007, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2005, 2016, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -103,7 +103,7 @@
>       *
>       * @implSpec The default implementation of this method creates an
>       * empty result set, iterates over the annotations in the argument
> -     * set calling {@link #getElementsAnnotatedWith(TypeElement)} on
> +     * array calling {@link #getElementsAnnotatedWith(TypeElement)} on
>       * each annotation and adding those results to the result
>       * set. Finally, the contents of the result set are returned as an
>       * unmodifiable set.
>
> -Joe
>
>
> On 6/10/2016 6:56 PM, Bruce Chapman wrote:
>> Joe,
>>
>> Just catching up on some reading, so this thread might be a bit stale 
>> now.
>>
>> Anyway - your javadoc for both methods still talks about the argument 
>> *set* in the @implSpec, which is now no longer a set since you 
>> changed it to varargs.
>>
>> Otherwise it looks good.
>>
>> Bruce
>>
>>
>> On 25/05/2016 4:18 a.m., joe darcy wrote:
>>> Updated webrev:
>>>
>>>     http://cr.openjdk.java.net/~darcy/8032230.1/
>>>
>>> Now with specialized implementation in javac's implementation of
>>> RoundEnvironment and separate tests of the default methods in the
>>> interface and the javac implementation.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>


From philip.race at oracle.com  Mon Jun 13 17:59:44 2016
From: philip.race at oracle.com (Phil Race)
Date: Mon, 13 Jun 2016 10:59:44 -0700
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <575EDB5C.5060601@oracle.com>
References: <575EDB5C.5060601@oracle.com>
Message-ID: <575EF490.6040005@oracle.com>

Hmm .. given that the majority of the jdk changes are in client - 
specifically
swing & accessibility -  including the swing mailing list would have 
increased the
likelihood of the right people clicking on this webrev link.

IMO,  we should remove these unusable fields from the Swing API - where
we can - and I think some we can, and really it ought to be all.

So I suggest that you leave alone those files and submit
bugs against swing & accessibility and the area owner
can then make the decision as to the appropriate treatment.

You can keep the JDK buildable in the meanwhile by suppressing the
lint warnings on the desktop module.

-phil.


On 06/13/2016 09:12 AM, Jan Lahoda wrote:
> Hello,
>
> There is:
> https://bugs.openjdk.java.net/browse/JDK-8153362
>
> which is about a new warning that should be produced by javac when 
> exported API refers to types not exported/accessible to the API clients.
>
> I've put my current javac change here:
> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
>
> There are some warnings produced for existing code in the hotspot and 
> jdk repositories (see the end for the warnings), I was using these 
> patches to keep JDK buildable:
> hotspot repository:
> http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
> jdk repository:
> http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/
>
> Any help with those (esp. those in the hotspot repository) would be 
> wholeheartedly welcome.
>
> Any feedback on this is welcome!
>
> Thanks,
>    Jan
>
> The warnings:
> -hotspot repository:
> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
> warning: unexported type referenced in exported API
>     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
>                     ^
> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
> warning: unexported type referenced in exported API
>     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
>                                                  ^
> error: warnings found and -Werror specified
> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54: 
> warning: unexported type referenced in exported API
>     public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
>                                              ^
> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73: 
> warning: unexported type referenced in exported API
>     public int adjustCompilationLevel(HotSpotVMConfig config, Class<?> 
> declaringClass, String name, String signature, boolean isOsr, int 
> level) {
>                                       ^
> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
> warning: unexported type referenced in exported API
>     public void notifyInstall(HotSpotCodeCacheProvider 
> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
> compiledCode) {
>                               ^
> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
> warning: unexported type referenced in exported API
>     public void notifyInstall(HotSpotCodeCacheProvider 
> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
> compiledCode) {
>
>           ^
> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
> warning: unexported type referenced in exported API
>     public void notifyInstall(HotSpotCodeCacheProvider 
> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
> compiledCode) {
>
>                                        ^
> 1 error
> 7 warnings
>
> -jdk/java.desktop:
> .../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333: 
> warning: inaccessible type referenced in exported API
>     protected DefaultAction defaultPressAction;
>               ^
> .../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344: 
> warning: inaccessible type referenced in exported API
>     protected DefaultAction defaultReleaseAction;
>               ^
> error: warnings found and -Werror specified
> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742: 
> warning: inaccessible type referenced in exported API
>         protected MetalBumps bumps = new MetalBumps( 10, 10,
>                   ^
> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java:926: 
> warning: inaccessible type referenced in exported API
>     protected DirectoryComboBoxRenderer 
> createDirectoryComboBoxRenderer(JFileChooser fc) {
>               ^
> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollBarUI.java:65: 
> warning: inaccessible type referenced in exported API
>     protected MetalBumps bumps;
>               ^
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> 1 error
> 5 warnings
>
>
> -jdk/java.naming:
> .../jdk/src/java.naming/share/classes/javax/naming/CompoundName.java:156: 
> warning: inaccessible type referenced in exported API
>     protected transient NameImpl impl;
>                         ^
> error: warnings found and -Werror specified
> 1 error
> 1 warning
>
>
> -jdk/jdk.accessibility:
> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java:219: 
> warning: inaccessible type referenced in exported API
>     static protected AWTEventsListener awtListener = new 
> AWTEventsListener();
>                      ^
> error: warnings found and -Werror specified
> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java:66: 
> warning: inaccessible type referenced in exported API
>     static protected final AccessibilityEventListener 
> accessibilityListener =
>                            ^
> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java:74: 
> warning: inaccessible type referenced in exported API
>     static protected final SwingEventListener swingListener = new 
> SwingEventListener();
>                            ^
> 1 error
> 3 warnings
>
>
> -jdk/jdk.jsobject:
> .../jdk/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java:153: 
> warning: type from a module referenced in exported API that is not 
> requires public from this module
>     public static JSObject getWindow(Applet applet) throws JSException {
>                                      ^
> error: warnings found and -Werror specified
> 1 error
> 1 warning
>
> -jdk/jdk.security.jgss:
> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:42: 
> warning: type that is invisible for some modules which read this 
> package referenced in exported API
>     static class ExtendedGSSContextImpl extends GSSContextImpl
>                                                 ^
> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:45: 
> warning: type that is invisible for some modules which read this 
> package referenced in exported API
>         public ExtendedGSSContextImpl(GSSContextImpl old) {
>                                       ^
> error: warnings found and -Werror specified
> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:38: 
> warning: type that is invisible for some modules which read this 
> package referenced in exported API
>     static class ExtendedGSSCredentialImpl extends GSSCredentialImpl
>                                                    ^
> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:41: 
> warning: type that is invisible for some modules which read this 
> package referenced in exported API
>         public ExtendedGSSCredentialImpl(GSSCredentialImpl old) {
>                                          ^
> 1 error
> 4 warnings


From philip.race at oracle.com  Mon Jun 13 19:26:00 2016
From: philip.race at oracle.com (Philip Race)
Date: Mon, 13 Jun 2016 12:26:00 -0700
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <575EF490.6040005@oracle.com>
References: <575EDB5C.5060601@oracle.com> <575EF490.6040005@oracle.com>
Message-ID: <575F08C8.606@oracle.com>

PS .. also you probably should  just suppress lint on the jdk.jsobject 
module

The change you propose to JSObject is going to cause a potential conflict
with the ongoing review discussion about this here :-

http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html

-phil.

On 6/13/16, 10:59 AM, Phil Race wrote:
> Hmm .. given that the majority of the jdk changes are in client - 
> specifically
> swing & accessibility -  including the swing mailing list would have 
> increased the
> likelihood of the right people clicking on this webrev link.
>
> IMO,  we should remove these unusable fields from the Swing API - where
> we can - and I think some we can, and really it ought to be all.
>
> So I suggest that you leave alone those files and submit
> bugs against swing & accessibility and the area owner
> can then make the decision as to the appropriate treatment.
>
> You can keep the JDK buildable in the meanwhile by suppressing the
> lint warnings on the desktop module.
>
> -phil.
>
>
> On 06/13/2016 09:12 AM, Jan Lahoda wrote:
>> Hello,
>>
>> There is:
>> https://bugs.openjdk.java.net/browse/JDK-8153362
>>
>> which is about a new warning that should be produced by javac when 
>> exported API refers to types not exported/accessible to the API clients.
>>
>> I've put my current javac change here:
>> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
>>
>> There are some warnings produced for existing code in the hotspot and 
>> jdk repositories (see the end for the warnings), I was using these 
>> patches to keep JDK buildable:
>> hotspot repository:
>> http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
>> jdk repository:
>> http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/
>>
>> Any help with those (esp. those in the hotspot repository) would be 
>> wholeheartedly welcome.
>>
>> Any feedback on this is welcome!
>>
>> Thanks,
>>    Jan
>>
>> The warnings:
>> -hotspot repository:
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
>> warning: unexported type referenced in exported API
>>     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
>>                     ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
>> warning: unexported type referenced in exported API
>>     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
>>                                                  ^
>> error: warnings found and -Werror specified
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54: 
>> warning: unexported type referenced in exported API
>>     public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
>>                                              ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73: 
>> warning: unexported type referenced in exported API
>>     public int adjustCompilationLevel(HotSpotVMConfig config, 
>> Class<?> declaringClass, String name, String signature, boolean 
>> isOsr, int level) {
>>                                       ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
>> warning: unexported type referenced in exported API
>>     public void notifyInstall(HotSpotCodeCacheProvider 
>> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
>> compiledCode) {
>>                               ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
>> warning: unexported type referenced in exported API
>>     public void notifyInstall(HotSpotCodeCacheProvider 
>> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
>> compiledCode) {
>>
>>           ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
>> warning: unexported type referenced in exported API
>>     public void notifyInstall(HotSpotCodeCacheProvider 
>> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
>> compiledCode) {
>>
>>                                        ^
>> 1 error
>> 7 warnings
>>
>> -jdk/java.desktop:
>> .../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333: warning: 
>> inaccessible type referenced in exported API
>>     protected DefaultAction defaultPressAction;
>>               ^
>> .../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344: warning: 
>> inaccessible type referenced in exported API
>>     protected DefaultAction defaultReleaseAction;
>>               ^
>> error: warnings found and -Werror specified
>> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742: 
>> warning: inaccessible type referenced in exported API
>>         protected MetalBumps bumps = new MetalBumps( 10, 10,
>>                   ^
>> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java:926: 
>> warning: inaccessible type referenced in exported API
>>     protected DirectoryComboBoxRenderer 
>> createDirectoryComboBoxRenderer(JFileChooser fc) {
>>               ^
>> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollBarUI.java:65: 
>> warning: inaccessible type referenced in exported API
>>     protected MetalBumps bumps;
>>               ^
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> 1 error
>> 5 warnings
>>
>>
>> -jdk/java.naming:
>> .../jdk/src/java.naming/share/classes/javax/naming/CompoundName.java:156: 
>> warning: inaccessible type referenced in exported API
>>     protected transient NameImpl impl;
>>                         ^
>> error: warnings found and -Werror specified
>> 1 error
>> 1 warning
>>
>>
>> -jdk/jdk.accessibility:
>> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java:219: 
>> warning: inaccessible type referenced in exported API
>>     static protected AWTEventsListener awtListener = new 
>> AWTEventsListener();
>>                      ^
>> error: warnings found and -Werror specified
>> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java:66: 
>> warning: inaccessible type referenced in exported API
>>     static protected final AccessibilityEventListener 
>> accessibilityListener =
>>                            ^
>> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java:74: 
>> warning: inaccessible type referenced in exported API
>>     static protected final SwingEventListener swingListener = new 
>> SwingEventListener();
>>                            ^
>> 1 error
>> 3 warnings
>>
>>
>> -jdk/jdk.jsobject:
>> .../jdk/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java:153: 
>> warning: type from a module referenced in exported API that is not 
>> requires public from this module
>>     public static JSObject getWindow(Applet applet) throws JSException {
>>                                      ^
>> error: warnings found and -Werror specified
>> 1 error
>> 1 warning
>>
>> -jdk/jdk.security.jgss:
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:42: 
>> warning: type that is invisible for some modules which read this 
>> package referenced in exported API
>>     static class ExtendedGSSContextImpl extends GSSContextImpl
>>                                                 ^
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:45: 
>> warning: type that is invisible for some modules which read this 
>> package referenced in exported API
>>         public ExtendedGSSContextImpl(GSSContextImpl old) {
>>                                       ^
>> error: warnings found and -Werror specified
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:38: 
>> warning: type that is invisible for some modules which read this 
>> package referenced in exported API
>>     static class ExtendedGSSCredentialImpl extends GSSCredentialImpl
>>                                                    ^
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:41: 
>> warning: type that is invisible for some modules which read this 
>> package referenced in exported API
>>         public ExtendedGSSCredentialImpl(GSSCredentialImpl old) {
>>                                          ^
>> 1 error
>> 4 warnings
>

From Alan.Bateman at oracle.com  Mon Jun 13 19:47:25 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 13 Jun 2016 20:47:25 +0100
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <575F08C8.606@oracle.com>
References: <575EDB5C.5060601@oracle.com> <575EF490.6040005@oracle.com>
	<575F08C8.606@oracle.com>
Message-ID: <a56f14c3-b158-6ea2-e9c7-c8b403a161fb@oracle.com>



On 13/06/2016 20:26, Philip Race wrote:
> PS .. also you probably should  just suppress lint on the jdk.jsobject 
> module
>
> The change you propose to JSObject is going to cause a potential conflict
> with the ongoing review discussion about this here :-
>
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html
Speaking of, shouldn't this have forRemoval=true? The reason that 
jdk.jsobject doesn't `requires public java.desktop` is because we expect 
getWindow(Applet) will eventually be removed and we don't want to trip 
up those that might be relying on it to access APIs exported by 
java.desktop.

-Alan

From philip.race at oracle.com  Mon Jun 13 19:53:02 2016
From: philip.race at oracle.com (Philip Race)
Date: Mon, 13 Jun 2016 12:53:02 -0700
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <a56f14c3-b158-6ea2-e9c7-c8b403a161fb@oracle.com>
References: <575EDB5C.5060601@oracle.com> <575EF490.6040005@oracle.com>
	<575F08C8.606@oracle.com>
	<a56f14c3-b158-6ea2-e9c7-c8b403a161fb@oracle.com>
Message-ID: <575F0F1E.60502@oracle.com>

Alan,

See the comment here : 
http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011478.html

Probably you should chime in directly on that discussion with such input ..

-phil.

On 6/13/16, 12:47 PM, Alan Bateman wrote:
>
>
> On 13/06/2016 20:26, Philip Race wrote:
>> PS .. also you probably should  just suppress lint on the 
>> jdk.jsobject module
>>
>> The change you propose to JSObject is going to cause a potential 
>> conflict
>> with the ongoing review discussion about this here :-
>>
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html
> Speaking of, shouldn't this have forRemoval=true? The reason that 
> jdk.jsobject doesn't `requires public java.desktop` is because we 
> expect getWindow(Applet) will eventually be removed and we don't want 
> to trip up those that might be relying on it to access APIs exported 
> by java.desktop.
>
> -Alan

From mandy.chung at oracle.com  Mon Jun 13 20:37:13 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 13 Jun 2016 13:37:13 -0700
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <575F0F1E.60502@oracle.com>
References: <575EDB5C.5060601@oracle.com> <575EF490.6040005@oracle.com>
	<575F08C8.606@oracle.com>
	<a56f14c3-b158-6ea2-e9c7-c8b403a161fb@oracle.com>
	<575F0F1E.60502@oracle.com>
Message-ID: <7A1EF046-73C5-4CF9-B094-51291C7F6316@oracle.com>

I agree JSObject.getWindow(Applet) should have forRemoval=true, as I raised in awt-dev thread.  The confusion there was when the API marked forRemoval=true in JDK 9 and when it should really be removed.

Mandy 

> On Jun 13, 2016, at 12:53 PM, Philip Race <philip.race at oracle.com> wrote:
> 
> Alan,
> 
> See the comment here : http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011478.html
> 
> Probably you should chime in directly on that discussion with such input ..
> 
> -phil.
> 
> On 6/13/16, 12:47 PM, Alan Bateman wrote:
>> 
>> 
>> On 13/06/2016 20:26, Philip Race wrote:
>>> PS .. also you probably should  just suppress lint on the jdk.jsobject module
>>> 
>>> The change you propose to JSObject is going to cause a potential conflict
>>> with the ongoing review discussion about this here :-
>>> 
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html
>> Speaking of, shouldn't this have forRemoval=true? The reason that jdk.jsobject doesn't `requires public java.desktop` is because we expect getWindow(Applet) will eventually be removed and we don't want to trip up those that might be relying on it to access APIs exported by java.desktop.
>> 
>> -Alan


From Alan.Bateman at oracle.com  Tue Jun 14 10:57:26 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Jun 2016 11:57:26 +0100
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <575EDB5C.5060601@oracle.com>
References: <575EDB5C.5060601@oracle.com>
Message-ID: <d846c25b-24dc-0312-57d0-24885aa98f7e@oracle.com>

On 13/06/2016 17:12, Jan Lahoda wrote:

> Hello,
>
> There is:
> https://bugs.openjdk.java.net/browse/JDK-8153362
>
> which is about a new warning that should be produced by javac when 
> exported API refers to types not exported/accessible to the API clients.
>
> I've put my current javac change here:
> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
Did you have a short list of names for the lint option before deciding 
on "unexportedinapi"? If time has already been put into this and this is 
the best of a bad bunch then ignore my mail. I bring it up because it 
feels more like a "potentiallynotaccessible" or "notaccessible" or 
"leaksnotaccessible". For the cases where we have ended up with 
protected fields in public classes but the field type is package-private 
then the field is never accessible. For the JSObject.getWindow case then 
consumers will need to require java.desktop to use this method.

Related is the description:

javac.opt.Xlint.desc.unexportedinapi=\
     Warn about use of types not visible to clients in exported API

Shouldn't get say something about the type potentially not accessible 
rather than visible?

-Alan

PS: You asked about the JVMCI classes in the hotspot repo. While this 
might look strange then it is intentional. The "framework" uses the 
reflective APIs to export the otherwise internal packages to the JVMCI 
implementation when it is located and loaded.

From jan.lahoda at oracle.com  Tue Jun 14 12:24:00 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 14 Jun 2016 14:24:00 +0200
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <575EF490.6040005@oracle.com>
References: <575EDB5C.5060601@oracle.com> <575EF490.6040005@oracle.com>
Message-ID: <575FF760.2050205@oracle.com>

Hi Phil,

Thanks for the comments. I was preferring @SuppressWarnings over 
-Xlint:-unexportedinapi because it allows to disable the check only on 
selected elements (as opposed to disabling it for a whole module, where 
a newly added API might inadvertently still cause a new warning); and 
also because it would be slightly easier to phase the change in. But I 
have no problem with using -Xlint:-unexportedinapi, I'll work on that.

Thanks,
     Jan

On 13.6.2016 19:59, Phil Race wrote:
> Hmm .. given that the majority of the jdk changes are in client -
> specifically
> swing & accessibility -  including the swing mailing list would have
> increased the
> likelihood of the right people clicking on this webrev link.
>
> IMO,  we should remove these unusable fields from the Swing API - where
> we can - and I think some we can, and really it ought to be all.
>
> So I suggest that you leave alone those files and submit
> bugs against swing & accessibility and the area owner
> can then make the decision as to the appropriate treatment.
>
> You can keep the JDK buildable in the meanwhile by suppressing the
> lint warnings on the desktop module.
>
> -phil.
>
>
> On 06/13/2016 09:12 AM, Jan Lahoda wrote:
>> Hello,
>>
>> There is:
>> https://bugs.openjdk.java.net/browse/JDK-8153362
>>
>> which is about a new warning that should be produced by javac when
>> exported API refers to types not exported/accessible to the API clients.
>>
>> I've put my current javac change here:
>> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
>>
>> There are some warnings produced for existing code in the hotspot and
>> jdk repositories (see the end for the warnings), I was using these
>> patches to keep JDK buildable:
>> hotspot repository:
>> http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
>> jdk repository:
>> http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/
>>
>> Any help with those (esp. those in the hotspot repository) would be
>> wholeheartedly welcome.
>>
>> Any feedback on this is welcome!
>>
>> Thanks,
>>    Jan
>>
>> The warnings:
>> -hotspot repository:
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72:
>> warning: unexported type referenced in exported API
>>     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
>>                     ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72:
>> warning: unexported type referenced in exported API
>>     public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
>>                                                  ^
>> error: warnings found and -Werror specified
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54:
>> warning: unexported type referenced in exported API
>>     public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
>>                                              ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73:
>> warning: unexported type referenced in exported API
>>     public int adjustCompilationLevel(HotSpotVMConfig config, Class<?>
>> declaringClass, String name, String signature, boolean isOsr, int
>> level) {
>>                                       ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70:
>> warning: unexported type referenced in exported API
>>     public void notifyInstall(HotSpotCodeCacheProvider
>> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode
>> compiledCode) {
>>                               ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70:
>> warning: unexported type referenced in exported API
>>     public void notifyInstall(HotSpotCodeCacheProvider
>> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode
>> compiledCode) {
>>
>>           ^
>> .../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70:
>> warning: unexported type referenced in exported API
>>     public void notifyInstall(HotSpotCodeCacheProvider
>> hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode
>> compiledCode) {
>>
>>                                        ^
>> 1 error
>> 7 warnings
>>
>> -jdk/java.desktop:
>> .../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333:
>> warning: inaccessible type referenced in exported API
>>     protected DefaultAction defaultPressAction;
>>               ^
>> .../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344:
>> warning: inaccessible type referenced in exported API
>>     protected DefaultAction defaultReleaseAction;
>>               ^
>> error: warnings found and -Werror specified
>> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742:
>> warning: inaccessible type referenced in exported API
>>         protected MetalBumps bumps = new MetalBumps( 10, 10,
>>                   ^
>> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java:926:
>> warning: inaccessible type referenced in exported API
>>     protected DirectoryComboBoxRenderer
>> createDirectoryComboBoxRenderer(JFileChooser fc) {
>>               ^
>> .../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollBarUI.java:65:
>> warning: inaccessible type referenced in exported API
>>     protected MetalBumps bumps;
>>               ^
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> 1 error
>> 5 warnings
>>
>>
>> -jdk/java.naming:
>> .../jdk/src/java.naming/share/classes/javax/naming/CompoundName.java:156:
>> warning: inaccessible type referenced in exported API
>>     protected transient NameImpl impl;
>>                         ^
>> error: warnings found and -Werror specified
>> 1 error
>> 1 warning
>>
>>
>> -jdk/jdk.accessibility:
>> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java:219:
>> warning: inaccessible type referenced in exported API
>>     static protected AWTEventsListener awtListener = new
>> AWTEventsListener();
>>                      ^
>> error: warnings found and -Werror specified
>> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java:66:
>> warning: inaccessible type referenced in exported API
>>     static protected final AccessibilityEventListener
>> accessibilityListener =
>>                            ^
>> .../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java:74:
>> warning: inaccessible type referenced in exported API
>>     static protected final SwingEventListener swingListener = new
>> SwingEventListener();
>>                            ^
>> 1 error
>> 3 warnings
>>
>>
>> -jdk/jdk.jsobject:
>> .../jdk/src/jdk.jsobject/share/classes/netscape/javascript/JSObject.java:153:
>> warning: type from a module referenced in exported API that is not
>> requires public from this module
>>     public static JSObject getWindow(Applet applet) throws JSException {
>>                                      ^
>> error: warnings found and -Werror specified
>> 1 error
>> 1 warning
>>
>> -jdk/jdk.security.jgss:
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:42:
>> warning: type that is invisible for some modules which read this
>> package referenced in exported API
>>     static class ExtendedGSSContextImpl extends GSSContextImpl
>>                                                 ^
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java:45:
>> warning: type that is invisible for some modules which read this
>> package referenced in exported API
>>         public ExtendedGSSContextImpl(GSSContextImpl old) {
>>                                       ^
>> error: warnings found and -Werror specified
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:38:
>> warning: type that is invisible for some modules which read this
>> package referenced in exported API
>>     static class ExtendedGSSCredentialImpl extends GSSCredentialImpl
>>                                                    ^
>> .../jdk/src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java:41:
>> warning: type that is invisible for some modules which read this
>> package referenced in exported API
>>         public ExtendedGSSCredentialImpl(GSSCredentialImpl old) {
>>                                          ^
>> 1 error
>> 4 warnings
>

From jan.lahoda at oracle.com  Tue Jun 14 12:29:06 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 14 Jun 2016 14:29:06 +0200
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <d846c25b-24dc-0312-57d0-24885aa98f7e@oracle.com>
References: <575EDB5C.5060601@oracle.com>
	<d846c25b-24dc-0312-57d0-24885aa98f7e@oracle.com>
Message-ID: <575FF892.90608@oracle.com>

Hi Alan,

On 14.6.2016 12:57, Alan Bateman wrote:
> On 13/06/2016 17:12, Jan Lahoda wrote:
>
>> Hello,
>>
>> There is:
>> https://bugs.openjdk.java.net/browse/JDK-8153362
>>
>> which is about a new warning that should be produced by javac when
>> exported API refers to types not exported/accessible to the API clients.
>>
>> I've put my current javac change here:
>> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
> Did you have a short list of names for the lint option before deciding
> on "unexportedinapi"? If time has already been put into this and this is

I had a few (e.g. "publishingunexported"), but none of them particularly 
nice.

> the best of a bad bunch then ignore my mail. I bring it up because it
> feels more like a "potentiallynotaccessible" or "notaccessible" or
> "leaksnotaccessible". For the cases where we have ended up with

I like "leaksnotaccessible". Unless there would be better ideas or 
objections, I'd go with that. Thanks for the ideas!

> protected fields in public classes but the field type is package-private
> then the field is never accessible. For the JSObject.getWindow case then
> consumers will need to require java.desktop to use this method.
>
> Related is the description:
>
> javac.opt.Xlint.desc.unexportedinapi=\
>      Warn about use of types not visible to clients in exported API
>
> Shouldn't get say something about the type potentially not accessible
> rather than visible?

Yes, it should. I'll fix that. Thanks for catching that.

Jan

>
> -Alan
>
> PS: You asked about the JVMCI classes in the hotspot repo. While this
> might look strange then it is intentional. The "framework" uses the
> reflective APIs to export the otherwise internal packages to the JVMCI
> implementation when it is located and loaded.

From jonathan.gibbons at oracle.com  Tue Jun 14 14:45:01 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 14 Jun 2016 07:45:01 -0700
Subject: Symbolic annotation processor
In-Reply-To: <CAEgw74BpzpSMqaTQxNr7wMkw_C3YzFQqq3hc=s-6duu8mU+k1g@mail.gmail.com>
References: <CAEgw74BztdzFb7ZcgHs4rvWtD8aqKdn_TSGuZjFtidyaUyHAYw@mail.gmail.com>	<CAEgw74BERMwvfAzXJEu_W6daN1L+tJABmBWGNu9q38+taOHorQ@mail.gmail.com>	<CAEgw74BE3r36KAX2aVs9B0tJ30T_4H9=yq2pAC7=DvOSm7YHaw@mail.gmail.com>
	<CAEgw74BpzpSMqaTQxNr7wMkw_C3YzFQqq3hc=s-6duu8mU+k1g@mail.gmail.com>
Message-ID: <5760186D.3080505@oracle.com>

Bernard,

While the work you describe sounds interesting, as a general rule,
OpenJDK projects are those that are directly or indirectly related
to the ongoing evolution of OpenJDK and what you describe sounds
more like a use of OpenJDK more than anything that might be
contributed to be part of OpenJDK.

-- Jon

On 06/13/2016 03:35 AM, bsrbnd wrote:
> Hi,
>
> As we all know, many numerical methods involve the derivative
> computation of a function; Newton's method to solve a non-linear
> equation, for example.
> Using an imperative language, we would probably compute an
> approximation of the derivative, which could be slow and probably
> inaccurate.
> But with symbolic expressions, we are able to compute the symbolic
> form of the derivative directly, which is much faster and is an
> absolutely correct solution.
>
> I haven't written any example for that yet, but you can refer to John
> McCarthy's paper: "Recursive Functions of Symbolic Expressions and
> Their Computation by Machine, Part I", Massachusetts Institute of
> Technology, Cambridge, Mass., April 1960, chapter 3.g on page 21;
> which can be found at:
> http://www-formal.stanford.edu/jmc/
>
> In addition to previous discussions, this example shows a bit more the
> benefits of symbolic programming.
>
> Notice that I've also updated the genetic programming example
> (presented in the previous email below) to link lambda to symbolic
> expressions and to use the existing functional API.
>
> Do you think it could be interesting to create an OpenJDK project to
> study more about this subject?
>
> Thanks,
>
> Bernard
>
> 2016-04-03 13:16 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>> Hi,
>>
>> I wrote a simple genetic programming example (a symbolic regression)
>> using SymProc, here:
>> https://github.com/bsrbnd/draft/blob/master/src/examples/GeneticProgramming.java
>>
>> As we can see, symbolic programming could be also the basements for
>> functional programming.
>> Notice, for example, the ease of the computation of the integral of
>> the absolute difference between two functions:
>>
>> private Double fitness(Symbol<?> $f) throws Exception {
>>      return integral(LOWER_BOUND, UPPER_BOUND,
>> $abs.apply($sub.apply($f,$target)));
>> }
>>
>> Regards,
>>
>> Bernard
>>
>> 2016-03-17 12:26 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>>> Hi,
>>>
>>> After a very fast and superficial reading of the JLS, I wrote some
>>> jtreg tests for points that might be impacted
>>> by the symbolic-processor. Source code of the tests, grouped in two
>>> files for more readability, can be found at:
>>> https://github.com/bsrbnd/draft/tree/master/src/tests
>>>
>>> Some of them show a bit more precisely the benefit of incorporating in
>>> some way the symbolic programming paradigm
>>> (the ability to manipulate the symbols of a language) to enhance the
>>> reflection (and perhaps even more...).
>>>
>>> As generics are earased during runtime, it could be hard to get the
>>> reflective elements of members using generics
>>> heavily (and even harder to maintain).
>>> Consider the following example inspired by JLS8, chapter 4.4:
>>>
>>> class MyTypeVariable {
>>>      public static class C {}
>>>      public static interface I {}
>>>
>>>      @Symbolic private <T extends C & I> void myMethod(T t, T[] u) {}
>>> }
>>>
>>> Without the symbolic view of members, you have to write something like
>>> the following to get the reflective object:
>>> Method m = MyTypeVariable.class.getDeclaredMethod("myMethod",
>>> MyTypeVariable.C.class,
>>> MyTypeVariable.C[].class));
>>>
>>> But, with the symbolic-processor, you delegate the generics and
>>> erasures handling to the compiler:
>>> Method m = MyTypeVariable.$myMethod.reflect();
>>>
>>> This is, of course, easier to write and to maintain.
>>>
>>> I've also tried to go further with this paradigm by introducing
>>> dynamically constructed symbolic expressions
>>> (a bit like LISP does) and evaluate them on a particular instance, for example:
>>>
>>> class DynamicExpression {
>>>      @Symbolic private Integer a = 3;
>>>      @Symbolic private Integer b = 2;
>>>      @Symbolic private Integer c = 1;
>>>
>>>      @Symbolic public Integer add(Integer i, Integer j) {return i + j;}
>>>      @Symbolic public Integer sub(Integer i, Integer j) {return i - j;}
>>> }
>>>
>>> MethodSymbol $symbolicExpression = $add.apply($a, $sub.apply($b, $c));
>>> Integer d = (Integer)$symbolicExpression.evaluate(new DynamicExpression());
>>>
>>> This expression evaluates naturally to 4 for this instance.
>>>
>>> The full running example can be found at:
>>> https://github.com/bsrbnd/draft/blob/master/src/examples/DynamicExpression.java
>>>
>>> Symbolic expressions could be useful for evolutionary algorithms used
>>> in genetic programming, where dynamic
>>> expressions are iteratively crossed-over and mutated to find the best
>>> approximation of a solution.
>>>
>>> I hope that I didn't miss anything in the JLS and that something like
>>> this hasn't already been incorporated
>>> in any existing project.
>>>
>>> Regards,
>>>
>>> Bernard
>>>
>>> 2015-12-10 14:50 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>>>> Hi,
>>>>
>>>> Following our discussion (October 2015), I wrote an
>>>> annotation-processor (only a draft for now) that gives a symbolic view
>>>> of class members, for example:
>>>> @Symbolic private Object myField;
>>>> @Symbolic("_") private void myMethod(Object param) {}
>>>>
>>>> We can either access the name or the reflective object of members the
>>>> following way:
>>>> String name = $myField.toString(); // $ is the default prefix
>>>> Method m = _myMethod.reflect(); // _ is a custom prefix, useful for
>>>> overloaded identifiers
>>>>
>>>> You can find a simple example here:
>>>> https://github.com/bsrbnd/draft/blob/master/src/examples/Example.java
>>>>
>>>> Full source code of the annotation-processor prototype is given there:
>>>> https://github.com/bsrbnd/draft
>>>>
>>>> Comments are welcome, but I know this is probably not the right
>>>> mailing-list for that.
>>>>
>>>> Regards,
>>>>
>>>> Bernard


From bsrbnd at gmail.com  Thu Jun 16 08:21:20 2016
From: bsrbnd at gmail.com (bsrbnd)
Date: Thu, 16 Jun 2016 10:21:20 +0200
Subject: Symbolic annotation processor
In-Reply-To: <5760186D.3080505@oracle.com>
References: <CAEgw74BztdzFb7ZcgHs4rvWtD8aqKdn_TSGuZjFtidyaUyHAYw@mail.gmail.com>
	<CAEgw74BERMwvfAzXJEu_W6daN1L+tJABmBWGNu9q38+taOHorQ@mail.gmail.com>
	<CAEgw74BE3r36KAX2aVs9B0tJ30T_4H9=yq2pAC7=DvOSm7YHaw@mail.gmail.com>
	<CAEgw74BpzpSMqaTQxNr7wMkw_C3YzFQqq3hc=s-6duu8mU+k1g@mail.gmail.com>
	<5760186D.3080505@oracle.com>
Message-ID: <CAEgw74CXmS-Gs6x-Y-FK_qe4m=KM5+aU5UdTbnEUJBuQ6jVGAg@mail.gmail.com>

With respect to McCarthy's paper, I think that symbolic expressions
are at the heart of functional programming; the key idea being the
manipulation of algebraic formulas.

In his document, functional API and lambda notation come only as
instruments to construct and use symbolic expressions which are
represented by list structures.

But I agree that symbolic functions and expressions rely on
meta-expressions. Thus, in our case, we could see Java as the
meta-language and symbolic expressions as something built above, as
shown by the symbolic annotation processor.
Nevertheless, I consider that it could probably be also fully part of
Java the same way it is at the foundation of the LISP language...

Bernard

2016-06-14 16:45 GMT+02:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:
> Bernard,
>
> While the work you describe sounds interesting, as a general rule,
> OpenJDK projects are those that are directly or indirectly related
> to the ongoing evolution of OpenJDK and what you describe sounds
> more like a use of OpenJDK more than anything that might be
> contributed to be part of OpenJDK.
>
> -- Jon
>
>
> On 06/13/2016 03:35 AM, bsrbnd wrote:
>>
>> Hi,
>>
>> As we all know, many numerical methods involve the derivative
>> computation of a function; Newton's method to solve a non-linear
>> equation, for example.
>> Using an imperative language, we would probably compute an
>> approximation of the derivative, which could be slow and probably
>> inaccurate.
>> But with symbolic expressions, we are able to compute the symbolic
>> form of the derivative directly, which is much faster and is an
>> absolutely correct solution.
>>
>> I haven't written any example for that yet, but you can refer to John
>> McCarthy's paper: "Recursive Functions of Symbolic Expressions and
>> Their Computation by Machine, Part I", Massachusetts Institute of
>> Technology, Cambridge, Mass., April 1960, chapter 3.g on page 21;
>> which can be found at:
>> http://www-formal.stanford.edu/jmc/
>>
>> In addition to previous discussions, this example shows a bit more the
>> benefits of symbolic programming.
>>
>> Notice that I've also updated the genetic programming example
>> (presented in the previous email below) to link lambda to symbolic
>> expressions and to use the existing functional API.
>>
>> Do you think it could be interesting to create an OpenJDK project to
>> study more about this subject?
>>
>> Thanks,
>>
>> Bernard
>>
>> 2016-04-03 13:16 GMT+02:00 bsrbnd <bsrbnd at gmail.com>:
>>>
>>> Hi,
>>>
>>> I wrote a simple genetic programming example (a symbolic regression)
>>> using SymProc, here:
>>>
>>> https://github.com/bsrbnd/draft/blob/master/src/examples/GeneticProgramming.java
>>>
>>> As we can see, symbolic programming could be also the basements for
>>> functional programming.
>>> Notice, for example, the ease of the computation of the integral of
>>> the absolute difference between two functions:
>>>
>>> private Double fitness(Symbol<?> $f) throws Exception {
>>>      return integral(LOWER_BOUND, UPPER_BOUND,
>>> $abs.apply($sub.apply($f,$target)));
>>> }
>>>
>>> Regards,
>>>
>>> Bernard
>>>
>>> 2016-03-17 12:26 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> After a very fast and superficial reading of the JLS, I wrote some
>>>> jtreg tests for points that might be impacted
>>>> by the symbolic-processor. Source code of the tests, grouped in two
>>>> files for more readability, can be found at:
>>>> https://github.com/bsrbnd/draft/tree/master/src/tests
>>>>
>>>> Some of them show a bit more precisely the benefit of incorporating in
>>>> some way the symbolic programming paradigm
>>>> (the ability to manipulate the symbols of a language) to enhance the
>>>> reflection (and perhaps even more...).
>>>>
>>>> As generics are earased during runtime, it could be hard to get the
>>>> reflective elements of members using generics
>>>> heavily (and even harder to maintain).
>>>> Consider the following example inspired by JLS8, chapter 4.4:
>>>>
>>>> class MyTypeVariable {
>>>>      public static class C {}
>>>>      public static interface I {}
>>>>
>>>>      @Symbolic private <T extends C & I> void myMethod(T t, T[] u) {}
>>>> }
>>>>
>>>> Without the symbolic view of members, you have to write something like
>>>> the following to get the reflective object:
>>>> Method m = MyTypeVariable.class.getDeclaredMethod("myMethod",
>>>> MyTypeVariable.C.class,
>>>> MyTypeVariable.C[].class));
>>>>
>>>> But, with the symbolic-processor, you delegate the generics and
>>>> erasures handling to the compiler:
>>>> Method m = MyTypeVariable.$myMethod.reflect();
>>>>
>>>> This is, of course, easier to write and to maintain.
>>>>
>>>> I've also tried to go further with this paradigm by introducing
>>>> dynamically constructed symbolic expressions
>>>> (a bit like LISP does) and evaluate them on a particular instance, for
>>>> example:
>>>>
>>>> class DynamicExpression {
>>>>      @Symbolic private Integer a = 3;
>>>>      @Symbolic private Integer b = 2;
>>>>      @Symbolic private Integer c = 1;
>>>>
>>>>      @Symbolic public Integer add(Integer i, Integer j) {return i + j;}
>>>>      @Symbolic public Integer sub(Integer i, Integer j) {return i - j;}
>>>> }
>>>>
>>>> MethodSymbol $symbolicExpression = $add.apply($a, $sub.apply($b, $c));
>>>> Integer d = (Integer)$symbolicExpression.evaluate(new
>>>> DynamicExpression());
>>>>
>>>> This expression evaluates naturally to 4 for this instance.
>>>>
>>>> The full running example can be found at:
>>>>
>>>> https://github.com/bsrbnd/draft/blob/master/src/examples/DynamicExpression.java
>>>>
>>>> Symbolic expressions could be useful for evolutionary algorithms used
>>>> in genetic programming, where dynamic
>>>> expressions are iteratively crossed-over and mutated to find the best
>>>> approximation of a solution.
>>>>
>>>> I hope that I didn't miss anything in the JLS and that something like
>>>> this hasn't already been incorporated
>>>> in any existing project.
>>>>
>>>> Regards,
>>>>
>>>> Bernard
>>>>
>>>> 2015-12-10 14:50 GMT+01:00 bsrbnd <bsrbnd at gmail.com>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Following our discussion (October 2015), I wrote an
>>>>> annotation-processor (only a draft for now) that gives a symbolic view
>>>>> of class members, for example:
>>>>> @Symbolic private Object myField;
>>>>> @Symbolic("_") private void myMethod(Object param) {}
>>>>>
>>>>> We can either access the name or the reflective object of members the
>>>>> following way:
>>>>> String name = $myField.toString(); // $ is the default prefix
>>>>> Method m = _myMethod.reflect(); // _ is a custom prefix, useful for
>>>>> overloaded identifiers
>>>>>
>>>>> You can find a simple example here:
>>>>> https://github.com/bsrbnd/draft/blob/master/src/examples/Example.java
>>>>>
>>>>> Full source code of the annotation-processor prototype is given there:
>>>>> https://github.com/bsrbnd/draft
>>>>>
>>>>> Comments are welcome, but I know this is probably not the right
>>>>> mailing-list for that.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bernard
>
>

From jan.lahoda at oracle.com  Fri Jun 17 14:18:11 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 17 Jun 2016 16:18:11 +0200
Subject: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed
	types which are not accessible
In-Reply-To: <575FF892.90608@oracle.com>
References: <575EDB5C.5060601@oracle.com>
	<d846c25b-24dc-0312-57d0-24885aa98f7e@oracle.com>
	<575FF892.90608@oracle.com>
Message-ID: <576406A3.10008@oracle.com>

Hi,

I've updated the patches, reflecting the feedback so far.

The langtools change is now split into two parts, one is only adding the 
new lint key (but no checks are actually performed):
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase1/

And the second part is adding the checks:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase2/

We could push the first part first, and the second one together with 
other changes later, so that the repositories don't have to be updated 
in a lockstep.

In addition to the langtools changes, only the top-level repository 
needs to be changed now, to disable the checks in some modules:
http://cr.openjdk.java.net/~jlahoda/8153362/top-level.01/

Any feedback is welcome!

Thanks,
     Jan

On 14.6.2016 14:29, Jan Lahoda wrote:
> Hi Alan,
>
> On 14.6.2016 12:57, Alan Bateman wrote:
>> On 13/06/2016 17:12, Jan Lahoda wrote:
>>
>>> Hello,
>>>
>>> There is:
>>> https://bugs.openjdk.java.net/browse/JDK-8153362
>>>
>>> which is about a new warning that should be produced by javac when
>>> exported API refers to types not exported/accessible to the API clients.
>>>
>>> I've put my current javac change here:
>>> http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
>> Did you have a short list of names for the lint option before deciding
>> on "unexportedinapi"? If time has already been put into this and this is
>
> I had a few (e.g. "publishingunexported"), but none of them particularly
> nice.
>
>> the best of a bad bunch then ignore my mail. I bring it up because it
>> feels more like a "potentiallynotaccessible" or "notaccessible" or
>> "leaksnotaccessible". For the cases where we have ended up with
>
> I like "leaksnotaccessible". Unless there would be better ideas or
> objections, I'd go with that. Thanks for the ideas!
>
>> protected fields in public classes but the field type is package-private
>> then the field is never accessible. For the JSObject.getWindow case then
>> consumers will need to require java.desktop to use this method.
>>
>> Related is the description:
>>
>> javac.opt.Xlint.desc.unexportedinapi=\
>>      Warn about use of types not visible to clients in exported API
>>
>> Shouldn't get say something about the type potentially not accessible
>> rather than visible?
>
> Yes, it should. I'll fix that. Thanks for catching that.
>
> Jan
>
>>
>> -Alan
>>
>> PS: You asked about the JVMCI classes in the hotspot repo. While this
>> might look strange then it is intentional. The "framework" uses the
>> reflective APIs to export the otherwise internal packages to the JVMCI
>> implementation when it is located and loaded.

From jonathan.gibbons at oracle.com  Fri Jun 17 22:34:52 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 17 Jun 2016 15:34:52 -0700
Subject: RFR 8059631:  Use of '#' to represent MethodHandle kind is confusing
Message-ID: <57647B0C.1000101@oracle.com>

Trivial review to "tweak" the presentation of method handles in javap's 
presentation of the constant pool.

1.  A misleading initial '#' is removed.
2.  The description of the kind of MethHandle is changed to use the name 
given in the JVMS.

JBS: https://bugs.openjdk.java.net/browse/JDK-8059631
Webrev: http://cr.openjdk.java.net/~jjg/8059631/webrev

-- Jon

From maurizio.cimadamore at oracle.com  Fri Jun 17 22:40:27 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 17 Jun 2016 23:40:27 +0100
Subject: RFR 8059631: Use of '#' to represent MethodHandle kind is
	confusing
In-Reply-To: <57647B0C.1000101@oracle.com>
References: <57647B0C.1000101@oracle.com>
Message-ID: <57647C5B.1060608@oracle.com>

Looks good - my IDE also tells me that RefKind.name is now unused? 
Should it be dropped?

Maurizio

On 17/06/16 23:34, Jonathan Gibbons wrote:
> Trivial review to "tweak" the presentation of method handles in 
> javap's presentation of the constant pool.
>
> 1.  A misleading initial '#' is removed.
> 2.  The description of the kind of MethHandle is changed to use the 
> name given in the JVMS.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8059631
> Webrev: http://cr.openjdk.java.net/~jjg/8059631/webrev
>
> -- Jon


From jonathan.gibbons at oracle.com  Fri Jun 17 22:53:00 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 17 Jun 2016 15:53:00 -0700
Subject: RFR 8059631: Use of '#' to represent MethodHandle kind is
	confusing
In-Reply-To: <57647C5B.1060608@oracle.com>
References: <57647B0C.1000101@oracle.com> <57647C5B.1060608@oracle.com>
Message-ID: <57647F4C.1010509@oracle.com>

I'll do a build and test run;  I think it should go if it is unused.

I wasn't sure at first, since most of the names appear in the 3rd column 
of JVMS 8, Table 5.4.3.5-A
but the oddball is REF_newInvokeSpecial(8, "newinvokespecial") which 
isn't a JVMS name.

-- Jon

On 06/17/2016 03:40 PM, Maurizio Cimadamore wrote:
> Looks good - my IDE also tells me that RefKind.name is now unused? 
> Should it be dropped?
>
> Maurizio
>
> On 17/06/16 23:34, Jonathan Gibbons wrote:
>> Trivial review to "tweak" the presentation of method handles in 
>> javap's presentation of the constant pool.
>>
>> 1.  A misleading initial '#' is removed.
>> 2.  The description of the kind of MethHandle is changed to use the 
>> name given in the JVMS.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059631
>> Webrev: http://cr.openjdk.java.net/~jjg/8059631/webrev
>>
>> -- Jon
>


From jonathan.gibbons at oracle.com  Fri Jun 17 23:05:40 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 17 Jun 2016 16:05:40 -0700
Subject: RFR 8059631: Use of '#' to represent MethodHandle kind is
	confusing
In-Reply-To: <57647F4C.1010509@oracle.com>
References: <57647B0C.1000101@oracle.com> <57647C5B.1060608@oracle.com>
	<57647F4C.1010509@oracle.com>
Message-ID: <57648244.2090805@oracle.com>

Updated webrev:
http://cr.openjdk.java.net/~jjg/8059631/webrev.01

-- Jon

On 06/17/2016 03:53 PM, Jonathan Gibbons wrote:
> I'll do a build and test run;  I think it should go if it is unused.
>
> I wasn't sure at first, since most of the names appear in the 3rd 
> column of JVMS 8, Table 5.4.3.5-A
> but the oddball is REF_newInvokeSpecial(8, "newinvokespecial") which 
> isn't a JVMS name.
>
> -- Jon
>
> On 06/17/2016 03:40 PM, Maurizio Cimadamore wrote:
>> Looks good - my IDE also tells me that RefKind.name is now unused? 
>> Should it be dropped?
>>
>> Maurizio
>>
>> On 17/06/16 23:34, Jonathan Gibbons wrote:
>>> Trivial review to "tweak" the presentation of method handles in 
>>> javap's presentation of the constant pool.
>>>
>>> 1.  A misleading initial '#' is removed.
>>> 2.  The description of the kind of MethHandle is changed to use the 
>>> name given in the JVMS.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059631
>>> Webrev: http://cr.openjdk.java.net/~jjg/8059631/webrev
>>>
>>> -- Jon
>>
>


From john.r.rose at oracle.com  Fri Jun 17 23:33:47 2016
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 17 Jun 2016 16:33:47 -0700
Subject: RFR 8059631: Use of '#' to represent MethodHandle kind is
	confusing
In-Reply-To: <57647F4C.1010509@oracle.com>
References: <57647B0C.1000101@oracle.com> <57647C5B.1060608@oracle.com>
	<57647F4C.1010509@oracle.com>
Message-ID: <7C135022-15C9-46A2-B864-6E70AE970CC6@oracle.com>

On Jun 17, 2016, at 3:53 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> I'll do a build and test run;  I think it should go if it is unused.
> 
> I wasn't sure at first, since most of the names appear in the 3rd column of JVMS 8, Table 5.4.3.5-A
> but the oddball is REF_newInvokeSpecial(8, "newinvokespecial") which isn't a JVMS name.

That's because it corresponds to two instructions, new + invokespecial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160617/55671f86/attachment.html>

From jonathan.gibbons at oracle.com  Fri Jun 17 23:41:05 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 17 Jun 2016 16:41:05 -0700
Subject: RFR 8059631: Use of '#' to represent MethodHandle kind is
	confusing
In-Reply-To: <7C135022-15C9-46A2-B864-6E70AE970CC6@oracle.com>
References: <57647B0C.1000101@oracle.com> <57647C5B.1060608@oracle.com>
	<57647F4C.1010509@oracle.com>
	<7C135022-15C9-46A2-B864-6E70AE970CC6@oracle.com>
Message-ID: <57648A91.6070501@oracle.com>



On 06/17/2016 04:33 PM, John Rose wrote:
> On Jun 17, 2016, at 3:53 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>> I'll do a build and test run;  I think it should go if it is unused.
>>
>> I wasn't sure at first, since most of the names appear in the 3rd 
>> column of JVMS 8, Table 5.4.3.5-A
>> but the oddball is REF_newInvokeSpecial(8, "newinvokespecial") which 
>> isn't a JVMS name.
>
> That's because it corresponds to two instructions, new + invokespecial.

Sure, I guessed that, but it didn't seem useful to include that in a 
"name" field, when the enum name
itself is more indicative of a name defined in JVMS.

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

From john.r.rose at oracle.com  Sat Jun 18 00:01:38 2016
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 17 Jun 2016 17:01:38 -0700
Subject: RFR 8059631: Use of '#' to represent MethodHandle kind is
	confusing
In-Reply-To: <57648A91.6070501@oracle.com>
References: <57647B0C.1000101@oracle.com> <57647C5B.1060608@oracle.com>
	<57647F4C.1010509@oracle.com>
	<7C135022-15C9-46A2-B864-6E70AE970CC6@oracle.com>
	<57648A91.6070501@oracle.com>
Message-ID: <8FFE5974-6742-473D-BAEC-03B24E15F773@oracle.com>

On Jun 17, 2016, at 4:41 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> On 06/17/2016 04:33 PM, John Rose wrote:
>> On Jun 17, 2016, at 3:53 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>> 
>>> I'll do a build and test run;  I think it should go if it is unused.
>>> 
>>> I wasn't sure at first, since most of the names appear in the 3rd column of JVMS 8, Table 5.4.3.5-A
>>> but the oddball is REF_newInvokeSpecial(8, "newinvokespecial") which isn't a JVMS name.
>> 
>> That's because it corresponds to two instructions, new + invokespecial.
> 
> Sure, I guessed that, but it didn't seem useful to include that in a "name" field, when the enum name
> itself is more indicative of a name defined in JVMS.

Oh, right.  I guess the "name" fields are trying to look like instruction names, but that fails for new + invokespecial.
I agree it's simpler just to use the enum names.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160617/58902c30/attachment-0001.html>

From maurizio.cimadamore at oracle.com  Mon Jun 20 09:43:02 2016
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Jun 2016 10:43:02 +0100
Subject: RFR 8059631: Use of '#' to represent MethodHandle kind is
	confusing
In-Reply-To: <57648244.2090805@oracle.com>
References: <57647B0C.1000101@oracle.com> <57647C5B.1060608@oracle.com>
	<57647F4C.1010509@oracle.com> <57648244.2090805@oracle.com>
Message-ID: <5767BAA6.8080505@oracle.com>

Approved!

Thanks
Maurizio

On 18/06/16 00:05, Jonathan Gibbons wrote:
> Updated webrev:
> http://cr.openjdk.java.net/~jjg/8059631/webrev.01
>
> -- Jon
>
> On 06/17/2016 03:53 PM, Jonathan Gibbons wrote:
>> I'll do a build and test run;  I think it should go if it is unused.
>>
>> I wasn't sure at first, since most of the names appear in the 3rd 
>> column of JVMS 8, Table 5.4.3.5-A
>> but the oddball is REF_newInvokeSpecial(8, "newinvokespecial") which 
>> isn't a JVMS name.
>>
>> -- Jon
>>
>> On 06/17/2016 03:40 PM, Maurizio Cimadamore wrote:
>>> Looks good - my IDE also tells me that RefKind.name is now unused? 
>>> Should it be dropped?
>>>
>>> Maurizio
>>>
>>> On 17/06/16 23:34, Jonathan Gibbons wrote:
>>>> Trivial review to "tweak" the presentation of method handles in 
>>>> javap's presentation of the constant pool.
>>>>
>>>> 1.  A misleading initial '#' is removed.
>>>> 2.  The description of the kind of MethHandle is changed to use the 
>>>> name given in the JVMS.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059631
>>>> Webrev: http://cr.openjdk.java.net/~jjg/8059631/webrev
>>>>
>>>> -- Jon
>>>
>>
>


From jonathan.gibbons at oracle.com  Thu Jun 23 00:08:27 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 22 Jun 2016 17:08:27 -0700
Subject: Fwd: inner class reading uninitialized value from outer class
In-Reply-To: <mailman.16899.1466639648.23828.compiler-dev@openjdk.java.net>
References: <mailman.16899.1466639648.23828.compiler-dev@openjdk.java.net>
Message-ID: <576B287B.8000005@oracle.com>

As the owner of the compiler-dev list, I'm forwarding this email that 
was bounced here from the jls-jvms-spec-comments at openjdk.java.net list.

-- Jon

On 06/22/2016 04:54 PM, compiler-dev-owner at openjdk.java.net wrote:
> Subject:
> inner class reading uninitialized value from outer class
> From:
> Xen <list at xenhideout.nl>
> Date:
> 06/05/2016 07:10 AM
>
> To:
> jls-jvms-spec-comments at openjdk.java.net
>
>
> I am not sure if this is the proper list to discuss a thing like this.
>
> The only alternative I have really found thus far is compiler-dev.
>
>
> I created an inner class that reads a value from the outer class:
>
>
> class Outer {
>   final int value;
>
>   Outer() {
>     value = 1;
>   }
>
>   class Inner {
>     int mine = Outer.this.value;
>   }
> }
>
> Now an instance of inner is created before the constructor of outer is 
> called.
>
> The OpenJDK 8 compiler gives no error, but the value that is getting 
> read is 0; even though it has not been initialized (no oddity here) 
> but it is getting read even though it is not initialized; and there is 
> no compiler warning saying so:
>
> class Outer {
>   Inner haha = new Inner(); // gets initialized to 0, not to 1
>
>   ...
> }
>
> However if we put the creation into the constructor of outer, it gets 
> the proper value. So there are 2 init stages: before the constructor 
> is called, and after. You can call both inner class pre-init and 
> constructor (both instanced) before the outer class constructor has 
> been called.
>
> Nothing odd here, but it does read a final value that has not been 
> initialized yet. Maybe this should simply be a compiler error. I don't 
> know what the spec says about this. It will just compile fine on 
> openjdk 8 (I got a package error trying to install 9 on my system, 
> hence I am using 8 for (this) now).
>
> Basically I wonder if the spec allows this, or whether this is a 
> compiler error.

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

From alex.buckley at oracle.com  Thu Jun 23 00:36:05 2016
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 22 Jun 2016 17:36:05 -0700
Subject: Fwd: inner class reading uninitialized value from outer class
In-Reply-To: <576B287B.8000005@oracle.com>
References: <mailman.16899.1466639648.23828.compiler-dev@openjdk.java.net>
	<576B287B.8000005@oracle.com>
Message-ID: <576B2EF5.6050602@oracle.com>

On 6/22/2016 5:08 PM, Jonathan Gibbons wrote:
> As the owner of the compiler-dev list, I'm forwarding this email that
> was bounced here from the jls-jvms-spec-comments at openjdk.java.net list.

Thanks Jon.

> On 06/22/2016 04:54 PM, compiler-dev-owner at openjdk.java.net wrote:
>> Subject:
>> inner class reading uninitialized value from outer class
>> From:
>> Xen <list at xenhideout.nl>
>> Date:
>> 06/05/2016 07:10 AM
>>
>> To:
>> jls-jvms-spec-comments at openjdk.java.net
>>
>> I am not sure if this is the proper list to discuss a thing like this.
>>
>> The only alternative I have really found thus far is compiler-dev.
>>
>> I created an inner class that reads a value from the outer class:
>>
>>
>> class Outer {
>>   final int value;
>>
>>   Outer() {
>>     value = 1;
>>   }
>>
>>   class Inner {
>>     int mine = Outer.this.value;
>>   }
>> }
>>
>> Now an instance of inner is created before the constructor of outer is
>> called.
>>
>> The OpenJDK 8 compiler gives no error, but the value that is getting
>> read is 0; even though it has not been initialized (no oddity here)
>> but it is getting read even though it is not initialized; and there is
>> no compiler warning saying so:
>>
>> class Outer {
>>   Inner haha = new Inner(); // gets initialized to 0, not to 1
>>
>>   ...
>> }

Per JLS 12.5, the instance variable 'haha' is initialized prior to 
execution of Outer's constructor. This causes execution of 'new 
Inner()', which causes the instance variable 'mine' of Inner to be 
initialized, which causes an access to the 'value' field of the (still 
being created) Outer object which is the lexically enclosing instance of 
the (still being created) Inner object per JLS 15.9.2. That 'value' 
field is still at its default value of 0, since Outer's constructor has 
not yet run for the (still being created) Outer object. The access is 
not advisable, but definite assignment analysis cannot prevent it, so 
ultimately it's acceptable.

>> However if we put the creation into the constructor of outer, it gets
>> the proper value. So there are 2 init stages: before the constructor
>> is called, and after. You can call both inner class pre-init and
>> constructor (both instanced) before the outer class constructor has
>> been called.

This is all true.

>> Nothing odd here, but it does read a final value that has not been
>> initialized yet. Maybe this should simply be a compiler error. I don't
>> know what the spec says about this. It will just compile fine on
>> openjdk 8 (I got a package error trying to install 9 on my system,
>> hence I am using 8 for (this) now).
>>
>> Basically I wonder if the spec allows this, or whether this is a
>> compiler error.

The spec allows this. It is possible to do all kinds of crazy things as 
a result of the language allowing arbitrary code in instance variable 
initializers, instance initializers, static variable initializers, and 
static initializers.

Alex

From srikanth.adayapalam at oracle.com  Thu Jun 23 04:32:01 2016
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Thu, 23 Jun 2016 10:02:01 +0530
Subject: JDK-8145489 NPE in javac during Attribute stage. Sequel
In-Reply-To: <da16120eb5304738b90efb3f3fcb7e9f@nut-mbx-1.win.ftc.ru>
References: <da16120eb5304738b90efb3f3fcb7e9f@nut-mbx-1.win.ftc.ru>
Message-ID: <576B6641.7020403@oracle.com>

[This mail is dated 13th May, but showed up in my inbox today.]

Hi Plizga,

I suspect the problem you faced is the same as
https://bugs.openjdk.java.net/browse/JDK-8145489

which is addressed via

http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d1a6b746310

Perhaps you can check if the problem shows up on JDK9 tip

Thanks!
Srikanth.

On Friday 13 May 2016 10:10 AM, Plizga Vladimir wrote:
> Hello!
>
> I'm the initiator of issue https://bugs.openjdk.java.net/browse/JDK-8145489 "NullPointerException while compiling certain annotations". The issue was closed because the assignee (Fairoz Matte) unfortunately couldn't reproduce it and I had no additional info by that moment.
> But the bug is still actual for our project  and recently I researched it in detail. I've sent the results by email to Fairoz a week ago but I didn't receive any answer. Hope you can help me.
>
> 1. I've significantly simplified the code snippet to reproduce the bug. Now it consists of just 3 short Java files located in 'mypackage' package:
>
> <File PackageAnnotation.java>
> package mypackage;
> public @interface PackageAnnotation {
>    Class<?> classyAnnotationMember();
> }
> </File PackageAnnotation.java>
>
> <File MyClass.java>
> package mypackage;
> public class MyClass {
>    public class MyInnerClass { }
> }
> </File MyClass.java>
>
> <File package-info.java>
> @PackageAnnotation(classyAnnotationMember = MyClass.MyInnerClass.class)
> package mypackage;
> </File package-info.java>
>
> An attempt to compile this files with javac 1.8.0_92 will end up with NullPointerException during Attribute stage (see the stacktrace in JDK-8145489).
>
> 2. The source of the error is condition ?!env.next.tree.hasTag(REFERENCE)? in com/sun/tools/javac/comp/Attr.java:3335 line that was added in JDK 1.8.
> AFAIU there is no enclosing environment for some class-type members of annotations at the topmost (package) level. That's why "env.next == null" and "env.next.tree" fails with NPE.
>
> 3. As a temporal workaround (in order to proceed with my current task) I?ve fixed the problem in 1.8.0_92 compiler?s source code by prepending the new condition with a naive checking for enclosing environment nullness:
>     (env.next != null && !env.next.tree.hasTag(REFERENCE))
> and rebuilt the compiler. This fix has not affected the amount of successfully passed tests run with jtreg and has allowed me to proceed. I believe Oracle engineers would find a truly proper way to fix it:)
>
>
> I hope this information would be enough to reproduce and fix the bug. If not, you are welcome to request anything else.
>
> Thanks,
> Vladimir Plizga


From v.plizga at ftc.ru  Thu Jun 23 05:05:21 2016
From: v.plizga at ftc.ru (Plizga Vladimir)
Date: Thu, 23 Jun 2016 05:05:21 +0000
Subject: JDK-8145489 NPE in javac during Attribute stage. Sequel
In-Reply-To: <576B6641.7020403@oracle.com>
References: <da16120eb5304738b90efb3f3fcb7e9f@nut-mbx-1.win.ftc.ru>
	<576B6641.7020403@oracle.com>
Message-ID: <a6f8605a541f43c6b45387f8ff079145@nut-mbx-1.win.ftc.ru>

Hi Srikanth,

Yes, you're right - the issue was already closed and I had been watching it all that time. I don't know why my letter has been delivered just today.
Anyway thanks for your reply!


Kind regards,
Vladimir Plizga

-----Original Message-----
From: compiler-dev [mailto:compiler-dev-bounces at openjdk.java.net] On Behalf Of Srikanth
Sent: Thursday, June 23, 2016 10:32 AM
To: compiler-dev at openjdk.java.net
Subject: Re: JDK-8145489 NPE in javac during Attribute stage. Sequel

[This mail is dated 13th May, but showed up in my inbox today.]

Hi Plizga,

I suspect the problem you faced is the same as
https://bugs.openjdk.java.net/browse/JDK-8145489

which is addressed via

http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2d1a6b746310

Perhaps you can check if the problem shows up on JDK9 tip

Thanks!
Srikanth.

On Friday 13 May 2016 10:10 AM, Plizga Vladimir wrote:
> Hello!
>
> I'm the initiator of issue https://bugs.openjdk.java.net/browse/JDK-8145489 "NullPointerException while compiling certain annotations". The issue was closed because the assignee (Fairoz Matte) unfortunately couldn't reproduce it and I had no additional info by that moment.
> But the bug is still actual for our project  and recently I researched it in detail. I've sent the results by email to Fairoz a week ago but I didn't receive any answer. Hope you can help me.
>
> 1. I've significantly simplified the code snippet to reproduce the bug. Now it consists of just 3 short Java files located in 'mypackage' package:
>
> <File PackageAnnotation.java>
> package mypackage;
> public @interface PackageAnnotation {
>    Class<?> classyAnnotationMember();
> }
> </File PackageAnnotation.java>
>
> <File MyClass.java>
> package mypackage;
> public class MyClass {
>    public class MyInnerClass { }
> }
> </File MyClass.java>
>
> <File package-info.java>
> @PackageAnnotation(classyAnnotationMember = 
> MyClass.MyInnerClass.class) package mypackage; </File 
> package-info.java>
>
> An attempt to compile this files with javac 1.8.0_92 will end up with NullPointerException during Attribute stage (see the stacktrace in JDK-8145489).
>
> 2. The source of the error is condition ?!env.next.tree.hasTag(REFERENCE)? in com/sun/tools/javac/comp/Attr.java:3335 line that was added in JDK 1.8.
> AFAIU there is no enclosing environment for some class-type members of annotations at the topmost (package) level. That's why "env.next == null" and "env.next.tree" fails with NPE.
>
> 3. As a temporal workaround (in order to proceed with my current task) I?ve fixed the problem in 1.8.0_92 compiler?s source code by prepending the new condition with a naive checking for enclosing environment nullness:
>     (env.next != null && !env.next.tree.hasTag(REFERENCE)) and rebuilt 
> the compiler. This fix has not affected the amount of successfully 
> passed tests run with jtreg and has allowed me to proceed. I believe 
> Oracle engineers would find a truly proper way to fix it:)
>
>
> I hope this information would be enough to reproduce and fix the bug. If not, you are welcome to request anything else.
>
> Thanks,
> Vladimir Plizga

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9282 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160623/ff3be45b/smime.p7s>

From list at xenhideout.nl  Thu Jun 23 09:47:43 2016
From: list at xenhideout.nl (Xen)
Date: Thu, 23 Jun 2016 11:47:43 +0200 (CEST)
Subject: Fwd: inner class reading uninitialized value from outer class
In-Reply-To: <576B2EF5.6050602@oracle.com>
References: <mailman.16899.1466639648.23828.compiler-dev@openjdk.java.net>
	<576B287B.8000005@oracle.com> <576B2EF5.6050602@oracle.com>
Message-ID: <alpine.DEB.2.11.1606231139050.9645@shell3.dds.nl>

On Wed, 22 Jun 2016, Alex Buckley wrote:

> The access is not advisable, but definite assignment analysis cannot
> prevent it, so ultimately it's acceptable.

Alright. It seems out of the ordinary that you couldn't detect it, but 
alright. Thanks for the reply in any case in advance ;-) :).

>>> Nothing odd here, but it does read a final value that has not been
>>> initialized yet. Maybe this should simply be a compiler error. I don't
>>> know what the spec says about this. It will just compile fine on
>>> openjdk 8 (I got a package error trying to install 9 on my system,
>>> hence I am using 8 for (this) now).
>>> 
>>> Basically I wonder if the spec allows this, or whether this is a
>>> compiler error.
>
> The spec allows this. It is possible to do all kinds of crazy things as a 
> result of the language allowing arbitrary code in instance variable 
> initializers, instance initializers, static variable initializers, and static 
> initializers.

Right, thanks. It was just a bug in my program ;-). Well, call it 
unfamiliarity with the mechanics. I had expected a final variable 
to not be able to have 2 different values during the lifetime of the 
program / class. It took me a few .....minutes ;-) to discover what was 
going on, but thankfully troubleshooting is much easier than in e.g. Bash, 
where a million things can go wrong as a matter of joy.

Linux seems to be the agenda and the place of creating more and more 
difficult problems, so that there are more problems to solve for 
problem-solving minds. A way of keeping yourself busy I guess. That 
saying: do not give him a fish, give him a rod with which to fish. Linux 
is like: empty the river first.

Thankfully Java is very much isolated from that and this is really the 
first peculiar thing I have ever come across. So well, thank you for your 
reply.

Regards.

Bart.

From jonathan.gibbons at oracle.com  Mon Jun 27 18:33:18 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 27 Jun 2016 11:33:18 -0700
Subject: RFR(s): JDK-8155026: javac grants implied readability to explicit
	modules
In-Reply-To: <571F1AED.2090906@oracle.com>
References: <571F1AED.2090906@oracle.com>
Message-ID: <5771716E.2080907@oracle.com>

Generally looks good, but you might want to consider whether the test 
needs "@modules java.desktop".   Will the test incorrectly fail if it is 
run on a basebones image, such as java.base + jdk.compiler?

-- Jon

On 04/26/2016 12:38 AM, Jan Lahoda wrote:
> Hi,
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8155026
>
> Fix/webrev:
> http://cr.openjdk.java.net/~jlahoda/8155026/webrev.00/index.html
>
> Thanks,
>     Jan


From jan.lahoda at oracle.com  Tue Jun 28 13:07:08 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 28 Jun 2016 15:07:08 +0200
Subject: RFR(s): JDK-8155026: javac grants implied readability to explicit
	modules
In-Reply-To: <5771716E.2080907@oracle.com>
References: <571F1AED.2090906@oracle.com> <5771716E.2080907@oracle.com>
Message-ID: <5772767C.3090102@oracle.com>

On 27.6.2016 20:33, Jonathan Gibbons wrote:
> Generally looks good, but you might want to consider whether the test
> needs "@modules java.desktop".   Will the test incorrectly fail if it is
> run on a basebones image, such as java.base + jdk.compiler?

I guess that for test selection purposes, it should include @modules 
java.desktop. Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8155026/webrev.01/

Delta:
http://cr.openjdk.java.net/~jlahoda/8155026/webrev.00-01/

Changes:
-added @module java.desktop
-removed an unnecessary -doe
-made the test method public

Does this look OK?

Thanks,
     Jan

>
> -- Jon
>
> On 04/26/2016 12:38 AM, Jan Lahoda wrote:
>> Hi,
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8155026
>>
>> Fix/webrev:
>> http://cr.openjdk.java.net/~jlahoda/8155026/webrev.00/index.html
>>
>> Thanks,
>>     Jan
>

From jonathan.gibbons at oracle.com  Tue Jun 28 14:42:40 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 28 Jun 2016 07:42:40 -0700
Subject: RFR(s): JDK-8155026: javac grants implied readability to explicit
	modules
In-Reply-To: <5772767C.3090102@oracle.com>
References: <571F1AED.2090906@oracle.com> <5771716E.2080907@oracle.com>
	<5772767C.3090102@oracle.com>
Message-ID: <57728CE0.9060400@oracle.com>

Looks OK

-- Jon


On 06/28/2016 06:07 AM, Jan Lahoda wrote:
> On 27.6.2016 20:33, Jonathan Gibbons wrote:
>> Generally looks good, but you might want to consider whether the test
>> needs "@modules java.desktop".   Will the test incorrectly fail if it is
>> run on a basebones image, such as java.base + jdk.compiler?
>
> I guess that for test selection purposes, it should include @modules 
> java.desktop. Updated webrev:
> http://cr.openjdk.java.net/~jlahoda/8155026/webrev.01/
>
> Delta:
> http://cr.openjdk.java.net/~jlahoda/8155026/webrev.00-01/
>
> Changes:
> -added @module java.desktop
> -removed an unnecessary -doe
> -made the test method public
>
> Does this look OK?
>
> Thanks,
>     Jan
>
>>
>> -- Jon
>>
>> On 04/26/2016 12:38 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8155026
>>>
>>> Fix/webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8155026/webrev.00/index.html
>>>
>>> Thanks,
>>>     Jan
>>


From joe.darcy at oracle.com  Wed Jun 29 01:56:29 2016
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 28 Jun 2016 18:56:29 -0700
Subject: JDK 9 RFR of JDK-8160506: Use @implSpec tags in javax.lang.model.util
Message-ID: <57732ACD.3040100@oracle.com>

Hello,

Please review the webrev to add some use of @implSpec and a few more 
uses of @Override to javax.lang.model.util:

     JDK-8160506: Use @implSpec tags in javax.lang.model.util
     http://cr.openjdk.java.net/~darcy/8160506.0/

Thanks,

-Joe


From jonathan.gibbons at oracle.com  Thu Jun 30 02:10:54 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 29 Jun 2016 19:10:54 -0700
Subject: JDK 9 RFR of JDK-8160506: Use @implSpec tags in
	javax.lang.model.util
In-Reply-To: <57732ACD.3040100@oracle.com>
References: <57732ACD.3040100@oracle.com>
Message-ID: <57747FAE.5090206@oracle.com>

Looks good.

-- Jon

On 06/28/2016 06:56 PM, Joseph D. Darcy wrote:
> Hello,
>
> Please review the webrev to add some use of @implSpec and a few more 
> uses of @Override to javax.lang.model.util:
>
>     JDK-8160506: Use @implSpec tags in javax.lang.model.util
>     http://cr.openjdk.java.net/~darcy/8160506.0/
>
> Thanks,
>
> -Joe
>