From dev at marcelkliemannel.com Sat Apr 1 06:22:24 2017 From: dev at marcelkliemannel.com (Marcel Kliemannel) Date: Sat, 01 Apr 2017 08:22:24 +0200 Subject: TypeMirror is missing annotation Message-ID: <4AAD7915-D24D-4859-B212-17852665DF4D@marcelkliemannel.com> Hello, I am writing a compiler plugin for code analyzation. The bug JDK-8031744 (https://bugs.openjdk.java.net/browse/JDK-8031744) seems to fix some problems in jdk 9 with missing annotations in the types of some kinds of elements. I found a case where the annotation is still missing. Maybe someone can say whether this is a compiler bug related to JDK-8031744, or I am doing something totally wrong? The annotation: ----------------------------------------- import java.lang.annotation.*; import static java.lang.annotation.RetentionPolicy.CLASS; @Retention(CLASS) @Target({ElementType.TYPE_USE}) public @interface R {} ----------------------------------------- and the class to analyse: ----------------------------------------- import java.util.function.Consumer; public class Test { ??? public void test() { ????? ??Consumer<@R String> consumer = input -> {}; ??? } } ----------------------------------------- I am expecting that the parameter ?input? of the lambda expression is of type ?@R() java.lang.String?, but the TypeMirror of the Element ?input? just gives me ?java.lang.String? without the annotation. Below is a compiler plugin to reproduce this behaviour with jdk 9 build 163 and the annotation and class above. I invoke the plugin with the command: javac -processorpath CompilerPlugin.jar -Xplugin:CompilerPlugin Test.java R.java ----------------------------------------- import com.sun.source.tree.*; import com.sun.source.util.*; import javax.lang.model.element.Element; public class CompilerPlugin implements Plugin { ? @Override ? public String getName() { ??? return "CompilerPlugin"; ? } ??@Override ? public void init(JavacTask javacTask, String[] args) { ??? javacTask.addTaskListener(new TaskListener() { ????? @Override ????? public void started(TaskEvent e) {} ??????@Override ????? public void finished(TaskEvent taskEvent) { ??????? if (TaskEvent.Kind.ANALYZE.equals(taskEvent.getKind())) { ????????? taskEvent.getCompilationUnit().getTypeDecls().forEach(typeDecl -> { ??????????? ClassTree classTree = (ClassTree) typeDecl; ????????????classTree.getMembers().forEach(member -> { ????????????? MethodTree methodTree = (MethodTree) member; ????????????? methodTree.getBody().getStatements().forEach(statement -> { ??????????????? if (Tree.Kind.VARIABLE.equals(statement.getKind())) { ????????????????? // Consumer<@R String> consumer = input -> {}; ????????????????? VariableTree variableTree = (VariableTree) statement; ??????????????????LambdaExpressionTree lambdaExpressionTree = ????????????????????? (LambdaExpressionTree) variableTree.getInitializer(); // input -> {} ??????????????????Tree firstParameter = lambdaExpressionTree.getParameters().get(0); // input ??????????????????TreePath path = TreePath.getPath(taskEvent.getCompilationUnit(), firstParameter); ????????????????? Element element = Trees.instance(javacTask).getElement(path); ????????????????? System.out.println(element.asType()); // java.lang.String ????????????????? System.out.println(element.asType().getAnnotationMirrors()); // nothing :( ??????????????? } ????????????? }); ??????????? }); ????????? }); ??????? } ????? } ??? }); ? } } ----------------------------------------- Thank you for your time and best regards, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Apr 4 00:07:30 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 3 Apr 2017 17:07:30 -0700 Subject: question about symlink handling In-Reply-To: References: Message-ID: I filed https://bugs.openjdk.java.net/browse/JDK-8178017 for this. Would you consider taking a patch to restore the JDK 8 behaviour? The idea would be to use the userPath in SimpleFileObject#getShortName, and then use that definition of getShortName in getKind and isNameCompatibleWith. On Wed, Dec 7, 2016 at 12:36 PM, Liam Miller-Cushon wrote: > This is somewhat related to: http://mail.openjdk.java.net/ > pipermail/compiler-dev/2016-November/010544.html > > Starting in 9, javac uses canonical paths in isNameCompatible. So if a > source file is a symlink, it reports errors if the symlink target (rather > than the user-supplied path) doesn't match the public class name: > > $ echo 'public class Hello {}' > SOURCE > $ ln -s SOURCE Hello.java > $ javac Hello.java > Hello.java:1: error: class Hello is public, should be declared in a file > named Hello.java > > The diagnostic is confusing because it still uses the user-supplied path, > but I'm more interested in whether isNameCompatible should be using > canonical paths. > > For what it's worth I prefer the previous behaviour, because our build > system uses symlinks extensively and the symlink target is a hash of the > content instead of a valid Java file name. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Apr 4 00:54:18 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 03 Apr 2017 17:54:18 -0700 Subject: question about symlink handling In-Reply-To: References: Message-ID: <58E2EEBA.4070106@oracle.com> I agree the error message is less than optimal. It is certainly the intent of the JavaFileManager API to use user-friendly names in diagnostics: it would look really bad if all diagnostics used full/canonical path names, so we can't go that way. It would seem somewhat strange to rely on canonical path names for part of the functionality of the file manager and not for others, but maybe it would be OK for isNameCompatible and getKind. That being said, note the very long-standing behavior to use the canonical name on Windows, allowing a Windows user to use a command line "JAVAC HELLO.JAVA" and have it work. (Not that I advocate such usage!) It seems a somewhat specialized use case to be storing source code in files with non-standard file names. That's not to say you shouldn't but it seems like that is a different sort of "host system" than the one currently supported by javac. How easy would it be for you to provide and use a different file manager that has the semantics suitable for your environment? Given the existing "fault tolerant" code in PathFileObject.isNameCompatible, how practical would it be to override isNameCompatible in SimpleFileObject such that it first checks the userPath, and then rolls over to the default definition. Ideally that first check should be as fault-tolerant as the existing checks, so there would be a small refactoring to be able to apply the same checks to both the userPath and the real path. And, similar treatment for getKind(). -- Jon On 04/03/2017 05:07 PM, Liam Miller-Cushon wrote: > I filed https://bugs.openjdk.java.net/browse/JDK-8178017 for this. > > Would you consider taking a patch to restore the JDK 8 behaviour? The > idea would be to use the userPath in SimpleFileObject#getShortName, > and then use that definition of getShortName in getKind and > isNameCompatibleWith. > > On Wed, Dec 7, 2016 at 12:36 PM, Liam Miller-Cushon > wrote: > > This is somewhat related to: > http://mail.openjdk.java.net/pipermail/compiler-dev/2016-November/010544.html > > > Starting in 9, javac uses canonical paths in isNameCompatible. So > if a source file is a symlink, it reports errors if the symlink > target (rather than the user-supplied path) doesn't match the > public class name: > > $ echo 'public class Hello {}' > SOURCE > $ ln -s SOURCE Hello.java > $ javac Hello.java > Hello.java:1: error: class Hello is public, should be declared in > a file named Hello.java > > The diagnostic is confusing because it still uses the > user-supplied path, but I'm more interested in whether > isNameCompatible should be using canonical paths. > > For what it's worth I prefer the previous behaviour, because our > build system uses symlinks extensively and the symlink target is a > hash of the content instead of a valid Java file name. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Apr 4 01:41:49 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 3 Apr 2017 18:41:49 -0700 Subject: question about symlink handling In-Reply-To: <58E2EEBA.4070106@oracle.com> References: <58E2EEBA.4070106@oracle.com> Message-ID: On Mon, Apr 3, 2017 at 5:54 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > It seems a somewhat specialized use case to be storing source code in > files with non-standard file names. That's not to say you shouldn't but it > seems like that is a different sort of "host system" than the one currently > supported by javac. How easy would it be for you to provide and use a > different file manager that has the semantics suitable for your environment? > Agreed, the environment where I noticed this is unusual, and if it wasn't for the issue with the diagnostic I might not have reported it. I'll think about whether there's a cleaner way to hide those details from javac. For the most part it's a normal filesystem with a lot of symlinks, so it'd be nice to continue to use as much of the JavacFileManager implementation as possible. > Given the existing "fault tolerant" code in PathFileObject.isNameCompatible, > how practical would it be to override isNameCompatible in SimpleFileObject > such that it first checks the userPath, and then rolls over to the default > definition. Ideally that first check should be as fault-tolerant as the > existing checks, so there would be a small refactoring to be able to apply > the same checks to both the userPath and the real path. > That sounds practical to me. > And, similar treatment for getKind(). > Changing the handling of kind in isNameCompatible is straightforward, but making all uses of getKind() fault-tolerant seems harder. For example, JavacTool uses getKind() to validate that the source file objects are actually sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Apr 4 05:36:01 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Apr 2017 22:36:01 -0700 Subject: question about symlink handling In-Reply-To: References: <58E2EEBA.4070106@oracle.com> Message-ID: <8ebd9f05-51b6-d014-c22a-4fb703d832e0@oracle.com> On 4/3/17 6:41 PM, Liam Miller-Cushon wrote: > On Mon, Apr 3, 2017 at 5:54 PM, Jonathan Gibbons > > wrote: > > It seems a somewhat specialized use case to be storing source code > in files with non-standard file names. That's not to say you > shouldn't but it seems like that is a different sort of "host > system" than the one currently supported by javac. How easy would > it be for you to provide and use a different file manager that has > the semantics suitable for your environment? > > > Agreed, the environment where I noticed this is unusual, and if it > wasn't for the issue with the diagnostic I might not have reported it. > I'll think about whether there's a cleaner way to hide those details > from javac. For the most part it's a normal filesystem with a lot of > symlinks, so it'd be nice to continue to use as much of the > JavacFileManager implementation as possible. > > Given the existing "fault tolerant" code in > PathFileObject.isNameCompatible, how practical would it be to > override isNameCompatible in SimpleFileObject such that it first > checks the userPath, and then rolls over to the default > definition. Ideally that first check should be as fault-tolerant > as the existing checks, so there would be a small refactoring to > be able to apply the same checks to both the userPath and the real > path. > > > That sounds practical to me. > > And, similar treatment for getKind(). > > > Changing the handling of kind in isNameCompatible is straightforward, > but making all uses of getKind() fault-tolerant seems harder. For > example, JavacTool uses getKind() to validate that the source file > objects are actually sources. Maybe you're right that we can't do too much with getKind. I'll take another look at the code tomorrow. Mostly, I was wanting to come up with a definition that was "the best of both worlds" -- user path, and canonical path, supporting those folk on Windows who may be used to case-equivalence for user paths, and those folk who apparently use unadorned cryptographic hashes for their canonical file names! -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From postolowicz at gmail.com Wed Apr 5 10:29:08 2017 From: postolowicz at gmail.com (_) Date: Wed, 5 Apr 2017 12:29:08 +0200 Subject: javac "cannot find symbol" bug (?) Message-ID: Hello, I discovered strange behavior of javac in my project: depending on order of source files passed it compiles successfully or fail. Could you take a look at sample reproducible case at https://bitbucket.org/postolowicz/javac-error ? Steps to reproduce: 1. Run `./gradlew build` This depending on your luck may success or fail at buildling system-test module. 2. Run `./compile-successful.sh` It should succeed. 3. Run `./compile-failing.sh` It should fail with message: system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:18: error: cannot find symbol protected class RunnerImpl extends ValidationRunner { ^ symbol: class ValidationRunner location: class AbstractSystemTestWithoutDB system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:13: error: cannot find symbol @Configuration ^ symbol: class Configuration location: class AbstractSystemTestWithoutDB system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:14: error: cannot find symbol @PropertySource(value = "", ignoreResourceNotFound = true) ^ symbol: class PropertySource location: class AbstractSystemTestWithoutDB system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:23: error: method does not override or implement a method from a supertype @Override ^ system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:28: error: method does not override or implement a method from a supertype @Override ^ 5 errors The only difference between these two scripts is order of source files. Is it a bug or I miss something? Occurs for javac -version javac 1.8.0_121 TIA, Radek Posto?owicz From joe.darcy at oracle.com Wed Apr 5 23:31:56 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 05 Apr 2017 16:31:56 -0700 Subject: Request for feedback on annotation processing API changes made in JDK 9 Message-ID: <58E57E6C.9090209@oracle.com> Hello annotation processing users and authors, As has been done previously during Java SE 7 and Java SE 8, the JSR 269 annotation processing API is undergoing a maintenance review (MR) as part of Java SE 9. Most of the API changes are in support of adding modules to the platform, both as a language structure in javax.lang.model.* as well as another interaction points in javax.annotation.processing in the Filer and elsewhere. A small API change was also done to better support repeating annotations. A more detailed summary of the API changes as well as an issue list is included in the MR material: http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/summary-2017-03-27.html http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/issue-list-2017-03-27.txt A specdiff of the changes compared to Java SE 8 is also available: http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/specdiff-2017-04-05/ The API changes are intended to be largely compatible with the sources of existing processors, their binary linkage, as well as their runtime behavior. However, it would be helpful to verify that your existing processors work as expected when run under JDK 9. JDK 9 early access binaries are available for download: https://jdk9.java.net/download/ The current build, b163, includes all planned changes to existing types. The next build, b164, scheduled to be available later this week will also include the type javax.annotation.processing.Generated. The new type javax.annotation.processing.Generated is intended to be a drop-in replacement for javax.annotation.Generated. (The type javax.annotation.Generated is in a module no longer visible by default.) Please report experiences running processors under JDK 9 and feedback on the API changes. Thanks, -Joe From maurizio.cimadamore at oracle.com Wed Apr 5 23:34:19 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 6 Apr 2017 00:34:19 +0100 Subject: javac "cannot find symbol" bug (?) In-Reply-To: References: Message-ID: <77e66622-e9e1-1dc7-7595-df36d063ac55@oracle.com> Hi, this could be related to this JEP: http://openjdk.java.net/jeps/216 would it be possible for you to check if the same behavior occurs in JDK 9? Thanks Maurizio On 05/04/17 11:29, _ wrote: > Hello, > > I discovered strange behavior of javac in my project: depending on > order of source files passed it compiles successfully or fail. > > Could you take a look at sample reproducible case at > https://bitbucket.org/postolowicz/javac-error ? > > Steps to reproduce: > > 1. Run `./gradlew build` > This depending on your luck may success or fail at buildling system-test module. > > 2. Run `./compile-successful.sh` > It should succeed. > > 3. Run `./compile-failing.sh` > It should fail with message: > system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:18: > error: cannot find symbol > protected class RunnerImpl extends ValidationRunner { > ^ > symbol: class ValidationRunner > location: class AbstractSystemTestWithoutDB > system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:13: > error: cannot find symbol > @Configuration > ^ > symbol: class Configuration > location: class AbstractSystemTestWithoutDB > system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:14: > error: cannot find symbol > @PropertySource(value = "", ignoreResourceNotFound = true) > ^ > symbol: class PropertySource > location: class AbstractSystemTestWithoutDB > system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:23: > error: method does not override or implement a method from a supertype > @Override > ^ > system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:28: > error: method does not override or implement a method from a supertype > @Override > ^ > 5 errors > > The only difference between these two scripts is order of source files. > > Is it a bug or I miss something? > > Occurs for javac -version > javac 1.8.0_121 > > TIA, > Radek Posto?owicz From alex.buckley at oracle.com Thu Apr 6 17:45:19 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 06 Apr 2017 10:45:19 -0700 Subject: TypeMirror is missing annotation In-Reply-To: <4AAD7915-D24D-4859-B212-17852665DF4D@marcelkliemannel.com> References: <4AAD7915-D24D-4859-B212-17852665DF4D@marcelkliemannel.com> Message-ID: <58E67EAF.9070708@oracle.com> On 3/31/2017 11:22 PM, Marcel Kliemannel wrote: > import java.util.function.Consumer; > public class Test { > public void test() { > Consumer<@R String> consumer = input -> {}; > } > } > > ----------------------------------------- > > I am expecting that the parameter ?input? of the lambda expression is of > type ?@R() java.lang.String?, but the TypeMirror of the Element ?input? > just gives me ?java.lang.String? without the annotation. I don't recall anything in the JLS or API spec that mandates implicit transmission of type annotations in this manner. Alex From Alan.Bateman at oracle.com Thu Apr 6 18:57:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Apr 2017 19:57:59 +0100 Subject: Fwd: 8177530: Module system implementation refresh (4/2017) In-Reply-To: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: I just realized I didn't cc compiler-dev on this update. Would it be possible to get a reviewer for the langtools changes in this update? The update webrevs (against jdk-9+164) is here: http://cr.openjdk.java.net/~alanb/8177530/2/ The only two non-mechnical changes to the src tree in this update are Jan's update to com/sun/tools/javac/comp/Modules.java to align the handling of automatic modules with run-time. We also had to update com/sun/tools/javac/file/Locations.java to not drop trailing digits and so align the derivation of automatic module names with the latest proposal in JSR 376. Thanks, -Alan -------- Forwarded Message -------- Subject: 8177530: Module system implementation refresh (4/2017) Date: Tue, 4 Apr 2017 17:28:32 +0100 From: Alan Bateman To: jigsaw-dev , hotspot-runtime-dev at openjdk.java.net runtime As I mentioned on jigsaw-dev yesterday, we have accumulated a number of changes in the jake forest and would like to bring the changes into jdk9/dev for jdk-9+165. Most of the changes in this update are the move of Module and friends from java.lang.reflect to java.lang. This is mostly a mechanical update. We also have the update to the derivation of automatic modules to no longer ignore trailing digits in modules names, this is to align JDK 9 with the updated proposal for issue #VersionsInModuleNames [1]. There are a number of smaller changes, summarized in JDK-8177530 [2]. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8177530/1 The changes are currently based on jdk-9+163 and will be rebased before pushing to jdk9/dev. The corresponding update to jtreg is already in the code-tools/jtreg repo and will be tagged (I assume as jtreg4.2-b07) before this integration. Once it is tagged then we'll rev'ing the requiredVersion in each TEST.ROOT. -Alan [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames [2] https://bugs.openjdk.java.net/browse/JDK-8177530 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Apr 6 19:38:11 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 06 Apr 2017 12:38:11 -0700 Subject: Fwd: 8177530: Module system implementation refresh (4/2017) In-Reply-To: References: <98592be5-8e93-f90a-b572-cd1f85d48ae7@oracle.com> Message-ID: <58E69923.5080300@oracle.com> Looks OK to me. -- Jon On 04/06/2017 11:57 AM, Alan Bateman wrote: > > I just realized I didn't cc compiler-dev on this update. > > Would it be possible to get a reviewer for the langtools changes in > this update? The update webrevs (against jdk-9+164) is here: > > http://cr.openjdk.java.net/~alanb/8177530/2/ > > The only two non-mechnical changes to the src tree in this update are > Jan's update to com/sun/tools/javac/comp/Modules.java to align the > handling of automatic modules with run-time. We also had to update > com/sun/tools/javac/file/Locations.java to not drop trailing digits > and so align the derivation of automatic module names with the latest > proposal in JSR 376. > > Thanks, > > -Alan > > > > > -------- Forwarded Message -------- > Subject: 8177530: Module system implementation refresh (4/2017) > Date: Tue, 4 Apr 2017 17:28:32 +0100 > From: Alan Bateman > To: jigsaw-dev , > hotspot-runtime-dev at openjdk.java.net runtime > > > > > As I mentioned on jigsaw-dev yesterday, we have accumulated a number of > changes in the jake forest and would like to bring the changes into > jdk9/dev for jdk-9+165. > > Most of the changes in this update are the move of Module and friends > from java.lang.reflect to java.lang. This is mostly a mechanical update. > > We also have the update to the derivation of automatic modules to no > longer ignore trailing digits in modules names, this is to align JDK 9 > with the updated proposal for issue #VersionsInModuleNames [1]. > > There are a number of smaller changes, summarized in JDK-8177530 [2]. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8177530/1 > > The changes are currently based on jdk-9+163 and will be rebased before > pushing to jdk9/dev. > > The corresponding update to jtreg is already in the code-tools/jtreg > repo and will be tagged (I assume as jtreg4.2-b07) before this > integration. Once it is tagged then we'll rev'ing the requiredVersion in > each TEST.ROOT. > > -Alan > > [1] > http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames > [2]https://bugs.openjdk.java.net/browse/JDK-8177530 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dawid.weiss at gmail.com Fri Apr 7 10:15:07 2017 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 7 Apr 2017 12:15:07 +0200 Subject: Request for feedback on annotation processing API changes made in JDK 9 In-Reply-To: <58E57E6C.9090209@oracle.com> References: <58E57E6C.9090209@oracle.com> Message-ID: Hello Joe, I've tried this build on our simple preprocessor that extracts metadata from existing types and builds some additional metadata classes. Unfortunately we're getting an illegal access exception when trying to access properties of the TypeElement object made available to the processor (stack trace at [1]). In short, the problem seems to be that we use Apache Velocity as a template processor and pass those TypeElement instances for dynamic introspection. When Velocity tries to access a property accessor method (like getQualifiedName) it does so on the target class (not on the interface) and consequently fails with cross-module access check. I didn't dig deeper yet but I wonder how this kind of situation can be worked around if the processor is used in the wild (where we have no control and can't add --add-exports). Provide package-local wrapper classes that call the target via the interface methods (TypeElement)? Nothing else comes to my mind at the moment. Dawid [1] [javac] Caused by: org.carrot2.util.preprocessor.shaded.apache.velocity.exception.VelocityException: ASTIdentifier() : exception invoking method for identifier 'qualifiedName' in class com.sun.tools.javac.code.Symbol$ClassSymbol ... [javac] Caused by: java.lang.IllegalAccessException: class org.carrot2.util.preprocessor.shaded.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class com.sun.tools.javac.code.Symbol$ClassSymbol (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.code to unnamed module @7cc586a8 [javac] at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:370) [javac] at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) [javac] at java.base/java.lang.reflect.Method.invoke(Method.java:555) [javac] at org.carrot2.util.preprocessor.shaded.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:142) On Thu, Apr 6, 2017 at 1:31 AM, Joseph D. Darcy wrote: > Hello annotation processing users and authors, > > As has been done previously during Java SE 7 and Java SE 8, the JSR 269 > annotation processing API is undergoing a maintenance review (MR) as part of > Java SE 9. > > Most of the API changes are in support of adding modules to the platform, > both as a language structure in javax.lang.model.* as well as another > interaction points in javax.annotation.processing in the Filer and > elsewhere. A small API change was also done to better support repeating > annotations. A more detailed summary of the API changes as well as an issue > list is included in the MR material: > > http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/summary-2017-03-27.html > http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/issue-list-2017-03-27.txt > > A specdiff of the changes compared to Java SE 8 is also available: > > http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/specdiff-2017-04-05/ > > The API changes are intended to be largely compatible with the sources of > existing processors, their binary linkage, as well as their runtime > behavior. However, it would be helpful to verify that your existing > processors work as expected when run under JDK 9. JDK 9 early access > binaries are available for download: > > https://jdk9.java.net/download/ > > The current build, b163, includes all planned changes to existing types. The > next build, b164, scheduled to be available later this week will also > include the type javax.annotation.processing.Generated. The new type > javax.annotation.processing.Generated is intended to be a drop-in > replacement for javax.annotation.Generated. (The type > javax.annotation.Generated is in a module no longer visible by default.) > > Please report experiences running processors under JDK 9 and feedback on the > API changes. > > Thanks, > > -Joe From gunnar at hibernate.org Fri Apr 7 12:50:28 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 7 Apr 2017 14:50:28 +0200 Subject: Request for feedback on annotation processing API changes made in JDK 9 In-Reply-To: <58E57E6C.9090209@oracle.com> References: <58E57E6C.9090209@oracle.com> Message-ID: Hi Joe, > The new type javax.annotation.processing.Generated is intended to be a drop-in replacement for javax.annotation.Generated A @Generated annotation is useful for any kind of code generator, whether implemented as an annotation processor or not. Having it in javax.annotation.processing ties it to annotation processing, though. Of course other non-AP generators may still use it, but it'd feel not quite right. When discussing the case of @Generated earlier this year on jigsaw-dev, a proposal was to have java.lang.annotation.Generated, and Mark expressed support for this [1]. I still think that'd be the better place, or was there anything speaking against it? Thanks, --Gunnar [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011365.html 2017-04-06 1:31 GMT+02:00 Joseph D. Darcy : > Hello annotation processing users and authors, > > As has been done previously during Java SE 7 and Java SE 8, the JSR 269 > annotation processing API is undergoing a maintenance review (MR) as part of > Java SE 9. > > Most of the API changes are in support of adding modules to the platform, > both as a language structure in javax.lang.model.* as well as another > interaction points in javax.annotation.processing in the Filer and > elsewhere. A small API change was also done to better support repeating > annotations. A more detailed summary of the API changes as well as an issue > list is included in the MR material: > > http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/summary-2017-03-27.html > http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/issue-list-2017-03-27.txt > > A specdiff of the changes compared to Java SE 8 is also available: > > http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/specdiff-2017-04-05/ > > The API changes are intended to be largely compatible with the sources of > existing processors, their binary linkage, as well as their runtime > behavior. However, it would be helpful to verify that your existing > processors work as expected when run under JDK 9. JDK 9 early access > binaries are available for download: > > https://jdk9.java.net/download/ > > The current build, b163, includes all planned changes to existing types. The > next build, b164, scheduled to be available later this week will also > include the type javax.annotation.processing.Generated. The new type > javax.annotation.processing.Generated is intended to be a drop-in > replacement for javax.annotation.Generated. (The type > javax.annotation.Generated is in a module no longer visible by default.) > > Please report experiences running processors under JDK 9 and feedback on the > API changes. > > Thanks, > > -Joe From postolowicz at gmail.com Fri Apr 7 14:51:18 2017 From: postolowicz at gmail.com (_) Date: Fri, 7 Apr 2017 16:51:18 +0200 Subject: javac "cannot find symbol" bug (?) In-Reply-To: <77e66622-e9e1-1dc7-7595-df36d063ac55@oracle.com> References: <77e66622-e9e1-1dc7-7595-df36d063ac55@oracle.com> Message-ID: Indeed, it works with javac from jdk 9. Thanks 2017-04-06 1:34 GMT+02:00 Maurizio Cimadamore : > Hi, > this could be related to this JEP: > > http://openjdk.java.net/jeps/216 > > would it be possible for you to check if the same behavior occurs in JDK 9? > > Thanks > Maurizio > > > > On 05/04/17 11:29, _ wrote: >> >> Hello, >> >> I discovered strange behavior of javac in my project: depending on >> order of source files passed it compiles successfully or fail. >> >> Could you take a look at sample reproducible case at >> https://bitbucket.org/postolowicz/javac-error ? >> >> Steps to reproduce: >> >> 1. Run `./gradlew build` >> This depending on your luck may success or fail at buildling system-test >> module. >> >> 2. Run `./compile-successful.sh` >> It should succeed. >> >> 3. Run `./compile-failing.sh` >> It should fail with message: >> >> system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:18: >> error: cannot find symbol >> protected class RunnerImpl extends ValidationRunner { >> ^ >> symbol: class ValidationRunner >> location: class AbstractSystemTestWithoutDB >> >> system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:13: >> error: cannot find symbol >> @Configuration >> ^ >> symbol: class Configuration >> location: class AbstractSystemTestWithoutDB >> >> system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:14: >> error: cannot find symbol >> @PropertySource(value = "", ignoreResourceNotFound = true) >> ^ >> symbol: class PropertySource >> location: class AbstractSystemTestWithoutDB >> >> system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:23: >> error: method does not override or implement a method from a supertype >> @Override >> ^ >> >> system-test/src/main/java/postolowicz/systemtest/AbstractSystemTestWithoutDB.java:28: >> error: method does not override or implement a method from a supertype >> @Override >> ^ >> 5 errors >> >> The only difference between these two scripts is order of source files. >> >> Is it a bug or I miss something? >> >> Occurs for javac -version >> javac 1.8.0_121 >> >> TIA, >> Radek Posto?owicz > > From alex.buckley at oracle.com Fri Apr 7 21:15:25 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 07 Apr 2017 14:15:25 -0700 Subject: Request for feedback on annotation processing API changes made in JDK 9 In-Reply-To: References: <58E57E6C.9090209@oracle.com> Message-ID: <58E8016D.5030007@oracle.com> On 4/7/2017 3:15 AM, Dawid Weiss wrote: > In short, the problem seems to be that we use Apache Velocity as a > template processor and pass those TypeElement instances for dynamic > introspection. When Velocity tries to access a property accessor > method (like getQualifiedName) it does so on the target class (not on > the interface) and consequently fails with cross-module access check. Basically the same issue as "Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException" [1]. The fact that Velocity gets IllegalAccessException, not InaccessibleObjectException, is probably because Velocity has found 'public' members (in this case, a nested type) and expects them to be universally accessible. > I didn't dig deeper yet but I wonder how this kind of situation can be > worked around if the processor is used in the wild (where we have no > control and can't add --add-exports). Provide package-local wrapper > classes that call the target via the interface methods (TypeElement)? > Nothing else comes to my mind at the moment. Please report a bug to Velocity. They've dealt with this kind of thing over the years [2][3]. Alex [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010779.html [2] https://issues.apache.org/jira/browse/VELOCITY-70 [3] https://issues.apache.org/jira/browse/VELOCITY-579 From alex.buckley at oracle.com Fri Apr 7 21:46:46 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 07 Apr 2017 14:46:46 -0700 Subject: Request for feedback on annotation processing API changes made in JDK 9 In-Reply-To: <58E57E6C.9090209@oracle.com> References: <58E57E6C.9090209@oracle.com> Message-ID: <58E808C6.8080002@oracle.com> On 4/5/2017 4:31 PM, Joseph D. Darcy wrote: > http://cr.openjdk.java.net/~darcy/JDK-9-JSR-269-Changes/specdiff-2017-04-05/ - ModulePrefix in Processor::getSupportedAnnotationTypes would benefit from using ModuleName (JLS9 6.5, 6.5.3) rather than TypeName. - I was surprised that ModuleElement.Directive says "Represents a ***"module statement"*** within the declaration of this module." because the whole point of adopting "directive" was to avoid reusing the term "statement". Please consider borrowing terminology from JLS9 7.7 [1], such as "The directives of a module declaration configure the module in the Java Platform Module System." - ModuleElement provides access to "information about the module, ***its directives***, and its members." - Semantically, ModuleElement::getSimpleName makes even less sense than PackageElement::getSimpleName. At least for the latter, two PackageElements having different simple names is a meta-level guarantee that code in one package can't access package-access types in the other package. But for the former, two ModuleElements having different simple names tells you nothing about anything. Alex [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/java-se-9-jls-pr-diffs.pdf -- obviously not the Final Release, but 7.7 is a stable section number. From joe.darcy at oracle.com Fri Apr 7 22:01:42 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 7 Apr 2017 15:01:42 -0700 Subject: Request for feedback on annotation processing API changes made in JDK 9 In-Reply-To: References: <58E57E6C.9090209@oracle.com> Message-ID: <22c2d5de-032d-5583-657f-465eeb777bf3@oracle.com> Hi Gunnar, On 4/7/2017 5:50 AM, Gunnar Morling wrote: > Hi Joe, > >> The new type javax.annotation.processing.Generated is intended to be a drop-in replacement for javax.annotation.Generated > A @Generated annotation is useful for any kind of code generator, > whether implemented as an annotation processor or not. Having it in > javax.annotation.processing ties it to annotation processing, though. > Of course other non-AP generators may still use it, but it'd feel not > quite right. More specifically, the new Generated annotation type is tied to the java.compiler module rather than the java.xml.ws.annotation module which houses the old Generated. > When discussing the case of @Generated earlier this year on > jigsaw-dev, a proposal was to have java.lang.annotation.Generated, and > Mark expressed support for this [1]. I still think that'd be the > better place, or was there anything speaking against it? After additional discussion, it seemed preferable to put the generated annotation in a module related to code generation of some sort, java.compiler, rather than the universally imported module java.base. Thanks, -Joe From mark.reinhold at oracle.com Sat Apr 8 00:45:29 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 07 Apr 2017 17:45:29 -0700 Subject: Request for feedback on annotation processing API changes made in JDK 9 In-Reply-To: <22c2d5de-032d-5583-657f-465eeb777bf3@oracle.com> References: <58E57E6C.9090209@oracle.com> <22c2d5de-032d-5583-657f-465eeb777bf3@oracle.com> Message-ID: <20170407174529.350888544@eggemoggin.niobe.net> 2017/4/7 15:01:42 -0700, joe.darcy at oracle.com: > On 4/7/2017 5:50 AM, Gunnar Morling wrote: >> When discussing the case of @Generated earlier this year on >> jigsaw-dev, a proposal was to have java.lang.annotation.Generated, and >> Mark expressed support for this [1]. I still think that'd be the >> better place, or was there anything speaking against it? > > After additional discussion, it seemed preferable to put the generated > annotation in a module related to code generation of some sort, > java.compiler, rather than the universally imported module java.base. Yes -- just for the record, I agree with that. - Mark From dawid.weiss at gmail.com Sat Apr 8 07:54:57 2017 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Sat, 8 Apr 2017 09:54:57 +0200 Subject: Request for feedback on annotation processing API changes made in JDK 9 In-Reply-To: <58E8016D.5030007@oracle.com> References: <58E57E6C.9090209@oracle.com> <58E8016D.5030007@oracle.com> Message-ID: > Basically the same issue as "Using > java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes > InaccessibleObjectException" [1]. Thanks for the pointer, Alex. I followed up on that discussion. So my intuition was basically correct (Method from the module-private class instead of the exported API). Still, I fail to see how this can be ever backward compatible and even fixable for many libraries that just accept arbitrary Object instances and try to perform some reflective operations on their public properties (or methods). Peter's advice [1], while applicable, requires major changes to any scripting engine out there to make it work. Don't get me wrong, I understand it's a much better module isolation sandbox and the concept is right. But speaking of backward compatibility it's going to be a major one for existing scripting engines. Consider Velocity -- those issues you pointed to are fairly dated. In fact, last Velocity release was 7 years ago and somehow I don't think tracking return types to get the right call methods is going to be an easy fix... Joe asked for feedback on the update, not the general module compatibility, so this isn't really the same thread. Just wanted to point out that this still leaves us in a situation where we have to stick to Java8 or rewrite/fix the underlying scripting engine to make it work with Java9 (command line switches cannot be considered if we redistribute the annotation processor and expect it to work with vanilla javac). Dawid [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-January/010818.html From jan.lahoda at oracle.com Tue Apr 11 17:26:38 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 11 Apr 2017 19:26:38 +0200 Subject: RFR 9: JDK-8178012: Finish removal of -Xmodule: Message-ID: <58ED11CE.5010608@oracle.com> Hi, javac used to have an option, -Xmodule:, that allowed to compile given sources as if they were part of the specified module. This functionality has been merged into the --patch-module option, but the -Xmodule: option couldn't be fully removed at that time, as some tests and tools (e.g. jtreg) depended on it. The option was however removed from the javac help, etc. Since jtreg can use --patch-module instead of -Xmodule: now, I'd like to propose further demoting the option to an unsupported -XD-Xmodule: setting (the functionality is not removed completely, as there is a small amount of remaining dependencies). The option may be removed completely eventually when the remaining dependencies are resolved. The patch spans many repositories besides langtools, as it adjusts TEST.ROOT files, and the /test/lib/jdk/test/lib/InMemoryJavaCompiler.java. The latter is used by hotspot tests, and this change is a small tweak to translate -Xmodule: to --patch-module. This could be later improved by enhancing the test library API to pass the module name explicitly. Bug: https://bugs.openjdk.java.net/browse/JDK-8178012 Webrev: http://cr.openjdk.java.net/~jlahoda/8178012/webrev.00/ Any feedback is welcome. Thanks, Jan From forax at univ-mlv.fr Tue Apr 11 18:35:05 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 11 Apr 2017 20:35:05 +0200 (CEST) Subject: RFR 9: JDK-8178012: Finish removal of -Xmodule: In-Reply-To: <58ED11CE.5010608@oracle.com> References: <58ED11CE.5010608@oracle.com> Message-ID: <882534875.892667.1491935705947.JavaMail.zimbra@u-pem.fr> Yes, please hide -Xmodule, currently people get confused by -Xmodule vs --patch-module, i had several questions related to that at DevoxxFR. R?mi ----- Mail original ----- > De: "Jan Lahoda" > ?: "compiler-dev" , "Java Core Libs" , > hotspot-dev at openjdk.java.net > Envoy?: Mardi 11 Avril 2017 19:26:38 > Objet: RFR 9: JDK-8178012: Finish removal of -Xmodule: > Hi, > > javac used to have an option, -Xmodule:, that allowed to compile given > sources as if they were part of the specified module. > > This functionality has been merged into the --patch-module option, but > the -Xmodule: option couldn't be fully removed at that time, as some > tests and tools (e.g. jtreg) depended on it. The option was however > removed from the javac help, etc. > > Since jtreg can use --patch-module instead of -Xmodule: now, I'd like to > propose further demoting the option to an unsupported -XD-Xmodule: > setting (the functionality is not removed completely, as there is a > small amount of remaining dependencies). The option may be removed > completely eventually when the remaining dependencies are resolved. > > The patch spans many repositories besides langtools, as it adjusts > TEST.ROOT files, and the > /test/lib/jdk/test/lib/InMemoryJavaCompiler.java. The latter > is used by hotspot tests, and this change is a small tweak to translate > -Xmodule: to --patch-module. This could be later improved by enhancing > the test library API to pass the module name explicitly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8178012 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8178012/webrev.00/ > > Any feedback is welcome. > > Thanks, > Jan From jonathan.gibbons at oracle.com Tue Apr 11 18:39:50 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Apr 2017 11:39:50 -0700 Subject: RFR 9: JDK-8178012: Finish removal of -Xmodule: In-Reply-To: <58ED11CE.5010608@oracle.com> References: <58ED11CE.5010608@oracle.com> Message-ID: Langtools parts look OK. I have filed a followup for jtreg to remove the need for useNewPatchModule in TEST.ROOT files. -- Jon On 4/11/17 10:26 AM, Jan Lahoda wrote: > Hi, > > javac used to have an option, -Xmodule:, that allowed to compile given > sources as if they were part of the specified module. > > This functionality has been merged into the --patch-module option, but > the -Xmodule: option couldn't be fully removed at that time, as some > tests and tools (e.g. jtreg) depended on it. The option was however > removed from the javac help, etc. > > Since jtreg can use --patch-module instead of -Xmodule: now, I'd like > to propose further demoting the option to an unsupported -XD-Xmodule: > setting (the functionality is not removed completely, as there is a > small amount of remaining dependencies). The option may be removed > completely eventually when the remaining dependencies are resolved. > > The patch spans many repositories besides langtools, as it adjusts > TEST.ROOT files, and the > /test/lib/jdk/test/lib/InMemoryJavaCompiler.java. The > latter is used by hotspot tests, and this change is a small tweak to > translate -Xmodule: to --patch-module. This could be later improved by > enhancing the test library API to pass the module name explicitly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8178012 > > Webrev: > http://cr.openjdk.java.net/~jlahoda/8178012/webrev.00/ > > Any feedback is welcome. > > Thanks, > Jan From jonathan.gibbons at oracle.com Fri Apr 14 01:21:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Apr 2017 18:21:13 -0700 Subject: RFR: 8178017: JDK 9 change to symlink handling causes misleading class.public.should.be.in.file diagnostic Message-ID: <58F02409.5010006@oracle.com> Review for relatively simple fix to revert a change in behavior in JDK 9: JBS: https://bugs.openjdk.java.net/browse/JDK-8178017 Webrev: http://cr.openjdk.java.net/~jjg/8178017/webrev/ -- Jon From cushon at google.com Tue Apr 18 17:53:20 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 18 Apr 2017 10:53:20 -0700 Subject: RFR: 8178017: JDK 9 change to symlink handling causes misleading class.public.should.be.in.file diagnostic In-Reply-To: <58F02409.5010006@oracle.com> References: <58F02409.5010006@oracle.com> Message-ID: Looks good to me, thanks. On Thu, Apr 13, 2017 at 6:21 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Review for relatively simple fix to revert a change in behavior in JDK 9: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8178017 > Webrev: http://cr.openjdk.java.net/~jjg/8178017/webrev/ > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Apr 18 19:23:35 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 18 Apr 2017 12:23:35 -0700 Subject: JDK 9 RFR of JDK-8178916: Update annotation processing API for terminology changes in modules Message-ID: Hello, Per Alex's previous comments on the list [1], the wording of some parts of the annotation processor API can be better aligned with current terminology being used for modules. Please review the patch below to do this. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010905.html diff -r b9a29aa786dd src/java.compiler/share/classes/javax/annotation/processing/Processor.java --- a/src/java.compiler/share/classes/javax/annotation/processing/Processor.java Tue Apr 18 06:29:53 2017 -0700 +++ b/src/java.compiler/share/classes/javax/annotation/processing/Processor.java Tue Apr 18 12:21:56 2017 -0700 @@ -278,14 +278,14 @@ *
* * *
ModulePrefix: - *
TypeName / + *
ModuleName / * *
DotStar: *
. * * * * - * where TypeName is as defined in + * where TypeName and ModuleName are as defined in * The Java™ Language Specification. * * @apiNote When running in an environment which supports modules, @@ -299,7 +299,7 @@ * @return the names of the annotation types supported by this processor * @see javax.annotation.processing.SupportedAnnotationTypes * @jls 3.8 Identifiers - * @jls 6.5.5 Meaning of Type Names + * @jls 6.5 Determining the Meaning of a Name */ Set getSupportedAnnotationTypes(); diff -r b9a29aa786dd src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java --- a/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java Tue Apr 18 06:29:53 2017 -0700 +++ b/src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java Tue Apr 18 12:21:56 2017 -0700 @@ -28,13 +28,14 @@ import java.util.List; /** - * Represents a module program element. Provides access to information - * about the module and its members. + * Represents a module program element. Provides access to + * information about the module, its directives, and its members. * * @see javax.lang.model.util.Elements#getModuleOf * @since 9 + * @jls 7.7 Module Declarations * @spec JPMS - */ // TODO: add @jls to module section + */ public interface ModuleElement extends Element, QualifiedNameable { /** @@ -121,12 +122,13 @@ }; /** - * Represents a "module statement" within the declaration of this module. + * Represents the directives within the declaration of this + * module. The directives of a module declaration configure the + * module in the Java Platform Module System. * * @since 9 * @spec JPMS - * - */ // TODO: add jls to Module Statement + */ interface Directive { /** * Returns the {@code kind} of this directive. From jonathan.gibbons at oracle.com Tue Apr 18 19:32:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 18 Apr 2017 12:32:31 -0700 Subject: JDK 9 RFR of JDK-8178916: Update annotation processing API for terminology changes in modules In-Reply-To: References: Message-ID: <7af33bd9-5ae2-85bc-87fd-72df6a563825@oracle.com> You've changed the plurality of these lines: "a module statement" vs. "the directives". -- Jon On 4/18/17 12:23 PM, joe darcy wrote: > > @@ -121,12 +122,13 @@ > }; > > /** > - * Represents a "module statement" within the declaration of this > module. > + * Represents the directives within the declaration of this > + * module. The directives of a module declaration configure the > + * module in the Java Platform Module System. From joe.darcy at oracle.com Tue Apr 18 20:12:33 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 18 Apr 2017 13:12:33 -0700 Subject: JDK 9 RFR of JDK-8178916: Update annotation processing API for terminology changes in modules In-Reply-To: <7af33bd9-5ae2-85bc-87fd-72df6a563825@oracle.com> References: <7af33bd9-5ae2-85bc-87fd-72df6a563825@oracle.com> Message-ID: Hi Jon, Will change to "Represents a directive within the declaration of this module." before pushing. Thanks, -Joe On 4/18/2017 12:32 PM, Jonathan Gibbons wrote: > You've changed the plurality of these lines: "a module statement" vs. > "the directives". > > -- Jon > > > On 4/18/17 12:23 PM, joe darcy wrote: >> >> @@ -121,12 +122,13 @@ >> }; >> >> /** >> - * Represents a "module statement" within the declaration of >> this module. >> + * Represents the directives within the declaration of this >> + * module. The directives of a module declaration configure the >> + * module in the Java Platform Module System. > From jan.lahoda at oracle.com Wed Apr 19 11:53:36 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 19 Apr 2017 13:53:36 +0200 Subject: RFR: 8178017: JDK 9 change to symlink handling causes misleading class.public.should.be.in.file diagnostic In-Reply-To: References: <58F02409.5010006@oracle.com> Message-ID: <58F74FC0.7090503@oracle.com> Looks good to me too. Jan On 18.4.2017 19:53, Liam Miller-Cushon wrote: > Looks good to me, thanks. > > On Thu, Apr 13, 2017 at 6:21 PM, Jonathan Gibbons > > wrote: > > Review for relatively simple fix to revert a change in behavior in > JDK 9: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8178017 > > Webrev: http://cr.openjdk.java.net/~jjg/8178017/webrev/ > > > -- Jon > > From gunnar at hibernate.org Thu Apr 20 08:10:22 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 20 Apr 2017 10:10:22 +0200 Subject: Type annotations and arrays Message-ID: Hi, Working on the Bean Validation 2 specification we came across an ambiguity when using type annotations with arrays. Bean Validation 2 uses type annotations to put constraints to the elements of container types. This works great for generic types: // the list must contain 10 elements at most @Size(max=10) List list; // each String in the list must have 10 chars at most List<@Size(max=10) String> list; If the @Size annotation is given on the declaration, it applies to the list, if is given on the type argument, it applies to the elements in the list. For arrays the annotation on the declaration is ambiguous, though: @Size(max=10) String[] arr; Before the advent of type annotations it was clear that the annotation applies to the array. Now, as @Size supports both element types, FIELD and TYPE_USE, it appears here as both, as a declaration annotation and as a type annotation. I.e. for Bean Validation it's ambiguous whether it should apply to the array or the array elements. We could mandate that the usage above only is considered as type annotation, as the annotation can be applied to the array like so: String @Size(max=10) [] arr; But that'd break existing clients of Bean Validation so it's not an option we really have (as the semantics of giving the annotation on the declaration would change from "apply to the array" to "apply to the array elements"). So it seems the introduction of type annotations caused a migration concern for existing annotation-based APIs when it comes to arrays. The only backwards-compatible way out I can see is to add a member to @Size stating its target, allowing to disambiguate the issue: @Size(max=10, appliesTo=ARRAY_ELEMENTS) String[] arr; Are there other options we've missed? Thanks, --Gunnar From mario.luis.guimaraes at gmail.com Thu Apr 20 16:32:34 2017 From: mario.luis.guimaraes at gmail.com (=?UTF-8?B?TcOhcmlvIEd1aW1hcsOjZXM=?=) Date: Thu, 20 Apr 2017 17:32:34 +0100 Subject: What is the meaning of defining enums and fields inside annotation declarations? Message-ID: Hello, It seems it is possible to declare fields and enums inside the declaration of an annotation in Java. For example, javac compiles this: @interface ClassPreamble { public enum AnEnum { Value; } String aField = ""; String author(); String date(); String currentRevision() default ""; String lastModified() default "N/A"; String lastModifiedBy() default "N/A"; // Note use of array String[] reviewers();} What is the meaning / usefulness of defining enums and fields inside annotation declarations? Thanks M?rio -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Apr 20 20:38:07 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Apr 2017 13:38:07 -0700 Subject: JDK 9 RFR of JDK-8173164: Resolve remaining HTML5 issues in javax.lang.model.* In-Reply-To: References: Message-ID: <58F91C2F.4000106@oracle.com> Do you have any specific tools in mind? Can we file RFEs against those tools? -- Jon On 01/23/2017 08:57 AM, Martin Buchholz wrote: > It's good. > > There's a persistent ecosystem nuisance that tools don't recognize > imports done purely for javadoc's benefit and complain. For this > reason I generally use fully qualified @links in the javadoc, even > though it's uglier. > > > On Sun, Jan 22, 2017 at 4:45 PM, joe darcy > wrote: > > Hello, > > Even after the fixes for JDK-8172458, there is still a lingering > HTML5 compliance issue in javax.lang.model.* in addition to a few > javadoc linkage problems. These should all be fixed; small patch > below. > > With the patch, the code is doclint clean under both HTML 4.01 and > HTML 5 output. > > (I thought the linkage problem would have been caught by the javac > and javadoc build options, but apparently not.) > > Thanks, > > -Joe > > diff -r 50c877258ca9 > src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > --- > a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Fri Jan 20 18:24:50 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Sun Jan 22 16:23:28 2017 -0800 > @@ -35,7 +35,7 @@ > * type is a kind of class and an annotation type is a kind of > * interface. > * > - *

> + *

> * While a {@code TypeElement} represents a class or interface > * element, a {@link DeclaredType} represents a class > * or interface type, the latter being a use > diff -r 50c877258ca9 > src/java.compiler/share/classes/javax/lang/model/util/Elements.java > --- > a/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Fri Jan 20 18:24:50 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Sun Jan 22 16:23:28 2017 -0800 > @@ -29,6 +29,7 @@ > import java.util.List; > import java.util.Map; > > +import javax.annotation.processing.Pr > ocessingEnvironment; > import javax.lang.model.AnnotatedConstruct; > import javax.lang.model.element.*; > > @@ -91,7 +92,7 @@ > * If the named module cannot be found, null is returned. One > situation where a module > * cannot be found is if the environment does not include > modules, such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. * > + * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. > * > * @param name the name > * @return the named module element, or {@code null} if it > cannot be found > @@ -331,7 +332,7 @@ > * If there is no module for the element, null is returned. > One situation where there is > * no module for an element is if the environment does not > include modules, such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. * > + * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. > * > * @param type the element being examined > * @return the module of an element > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu Apr 20 20:51:08 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 20 Apr 2017 13:51:08 -0700 Subject: JDK 9 RFR of JDK-8173164: Resolve remaining HTML5 issues in javax.lang.model.* In-Reply-To: <58F91C2F.4000106@oracle.com> References: <58F91C2F.4000106@oracle.com> Message-ID: On Thu, Apr 20, 2017 at 1:38 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Do you have any specific tools in mind? Can we file RFEs against those > tools? > IIRC, checkstyle http://checkstyle.sourceforge.net/ has an unused import checker that doesn't recognize usage in doc comments. I have the vague feeling there are others. I have the feeling checkstyle's checks are not very good, but improving them would be a full time job. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Thu Apr 20 22:19:16 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 20 Apr 2017 15:19:16 -0700 Subject: JDK 9 RFR of JDK-8173164: Resolve remaining HTML5 issues in javax.lang.model.* In-Reply-To: References: <58F91C2F.4000106@oracle.com> Message-ID: Newer versions of checkstyle support it: http://checkstyle. sourceforge.net/config_imports.html#UnusedImports I remember some disagreement between other tools about whether e.g. `{@link #foo(Bar)}` needs an import for `Bar`, but javadoc's handling of that seems to have improved in 9. On Thu, Apr 20, 2017 at 1:51 PM, Martin Buchholz wrote: > > > On Thu, Apr 20, 2017 at 1:38 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> Do you have any specific tools in mind? Can we file RFEs against those >> tools? >> > > IIRC, checkstyle http://checkstyle.sourceforge.net/ has an unused import > checker that doesn't recognize usage in doc comments. I have the vague > feeling there are others. I have the feeling checkstyle's checks are not > very good, but improving them would be a full time job. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Fri Apr 21 20:19:35 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 21 Apr 2017 13:19:35 -0700 Subject: Type annotations and arrays In-Reply-To: References: Message-ID: <58FA6957.8040906@oracle.com> On 4/20/2017 1:10 AM, Gunnar Morling wrote: > For arrays the annotation on the declaration is ambiguous, though: > > @Size(max=10) String[] arr; > > Before the advent of type annotations it was clear that the annotation > applies to the array. > > Now, as @Size supports both element types, FIELD and TYPE_USE, it > appears here as both, as a declaration annotation and as a type > annotation. I.e. for Bean Validation it's ambiguous whether it should > apply to the array or the array elements. > > We could mandate that the usage above only is considered as type > annotation, as the annotation can be applied to the array like so: > > String @Size(max=10) [] arr; > > But that'd break existing clients of Bean Validation so it's not an > option we really have (as the semantics of giving the annotation on > the declaration would change from "apply to the array" to "apply to > the array elements"). > > So it seems the introduction of type annotations caused a migration > concern for existing annotation-based APIs when it comes to arrays. The unfortunate syntax for array types in Java, and the difficulty of a "best" order for the type annotations thereon, were discussed at length in the lifetime of JSR 308. > The only backwards-compatible way out I can see is to add a member to > @Size stating its target, allowing to disambiguate the issue: > > @Size(max=10, appliesTo=ARRAY_ELEMENTS) String[] arr; > > Are there other options we've missed? Given that you want: @Size(max=10) String[] arr; to constrain the size of the array, and not the size of each String in the array, I think I'd recommend a different TYPE_USE annotation type altogether for the new functionality of constraining the size of each String in the array. And I'd enforce that annotations of this new type are written in the "proper" location, on the element type only: @Size(max=10) @ElementSize(max=10) String[] arr; Alex From stuart.marks at oracle.com Fri Apr 21 22:45:09 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 21 Apr 2017 15:45:09 -0700 Subject: JDK 9 RFR(m): JDK-8168444: (jdeprscan) improper handling of primitives and primitive array types Message-ID: Hi all, Please review this fix to jdeprscan so that it handles primitive types and primitive array types properly. In the absence of this fix, jdeprscan botches this, resulting in potentially lots of error messages of the form error: cannot find class [D when it attempts to resolve the "class name" for double[]. (Similar phenomena occur for other primitive array types.) It can be quite disruptive to have these errors in the output, as they often overwhelm the legitimate output. Bug: https://bugs.openjdk.java.net/browse/JDK-8168444 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8168444/webrev.0/ Thanks, s'marks From daniel.smith at oracle.com Mon Apr 24 21:27:09 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 24 Apr 2017 15:27:09 -0600 Subject: Call for Speakers -- 2017 JVM Language Summit Message-ID: CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, JULY-AUGUST 2017 We are pleased to announce the 2017 JVM Language Summit to be held at Oracle's Santa Clara campus on July 31-August 2, 2017. Registration is now open for speaker submissions and will remain open through May 22, 2017. There is no registration fee for speakers. A limited number of early registration slots are also available for regular attendees. 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 6 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-4 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. Instructions for Speaker Registration If you'd like to give a presentation, please register as a Speaker and include a detailed abstract. Speaker registration will remain open through May 22. There is no fee. See below for help preparing your abstract and talk. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee. For a successful speaker submission, please note the following: - All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak bytecode here! - Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design or implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.) - Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire us to work together on JVM-based technologies that enable a rich ecosystem at higher layers. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2017 at jvmlangsummit.com From paul.sandoz at oracle.com Tue Apr 25 18:57:21 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 25 Apr 2017 11:57:21 -0700 Subject: JDK 9 RFR(m): JDK-8168444: (jdeprscan) improper handling of primitives and primitive array types In-Reply-To: References: Message-ID: > On 21 Apr 2017, at 15:45, Stuart Marks wrote: > > Hi all, > > Please review this fix to jdeprscan so that it handles primitive types and primitive array types properly. In the absence of this fix, jdeprscan botches this, resulting in potentially lots of error messages of the form > > error: cannot find class [D > > when it attempts to resolve the "class name" for double[]. (Similar phenomena occur for other primitive array types.) > > It can be quite disruptive to have these errors in the output, as they often overwhelm the legitimate output. > +1 Paul. > Bug: > https://bugs.openjdk.java.net/browse/JDK-8168444 > > Webrev: > http://cr.openjdk.java.net/~smarks/reviews/8168444/webrev.0/ > > Thanks, > > s'marks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jonathan.gibbons at oracle.com Wed Apr 26 00:40:25 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Apr 2017 17:40:25 -0700 Subject: RFR: Fix HTML 5 errors in various langtools modules Message-ID: <58FFEC79.4070607@oracle.com> compiler-dev, javadoc-dev, kulla-dev folk, Please review the following collections of trivial changes to make the API for these modules HTML 5 compliant. JBS: https://bugs.openjdk.java.net/browse/JDK-8179299 https://bugs.openjdk.java.net/browse/JDK-8179300 https://bugs.openjdk.java.net/browse/JDK-8179301 https://bugs.openjdk.java.net/browse/JDK-8179303 Webrev: http://cr.openjdk.java.net/~jjg/8179299-8179300-8179301-8179303/webrev.00/ -- Jon From stuart.marks at oracle.com Wed Apr 26 00:45:52 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 25 Apr 2017 17:45:52 -0700 Subject: JDK 9 RFR(s): 8169203: (jdeprscan) eliminate duplicate "can't find class" errors Message-ID: Hi all, Please review this small jdeprscan fix for another error message cleanup. This time, keep track of which classes aren't found so that a "not found" error is emitted only once per class not found. Without this fix, the duplicates can overwhelm the rest of the output. Bug: https://bugs.openjdk.java.net/browse/JDK-8169203 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8169203/webrev.0/ Thanks, s'marks From jonathan.gibbons at oracle.com Wed Apr 26 00:59:11 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Apr 2017 17:59:11 -0700 Subject: JDK 9 RFR(s): 8169203: (jdeprscan) eliminate duplicate "can't find class" errors In-Reply-To: References: Message-ID: <58FFF0DF.6020703@oracle.com> Look OK to me. Line 29 in the test is redundant but not wrong. -- Jon On 04/25/2017 05:45 PM, Stuart Marks wrote: > Hi all, > > Please review this small jdeprscan fix for another error message > cleanup. This time, keep track of which classes aren't found so that a > "not found" error is emitted only once per class not found. Without > this fix, the duplicates can overwhelm the rest of the output. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169203 > > Webrev: > http://cr.openjdk.java.net/~smarks/reviews/8169203/webrev.0/ > > Thanks, > > s'marks > From joe.darcy at oracle.com Wed Apr 26 01:00:49 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 25 Apr 2017 18:00:49 -0700 Subject: RFR: Fix HTML 5 errors in various langtools modules In-Reply-To: <58FFEC79.4070607@oracle.com> References: <58FFEC79.4070607@oracle.com> Message-ID: <9a921cea-aab0-5e97-5cf9-63f4923c0939@oracle.com> All the changes look fine Jon; thanks, -Joe On 4/25/2017 5:40 PM, Jonathan Gibbons wrote: > compiler-dev, javadoc-dev, kulla-dev folk, > > Please review the following collections of trivial changes to make the > API for these modules HTML 5 compliant. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8179299 > https://bugs.openjdk.java.net/browse/JDK-8179300 > https://bugs.openjdk.java.net/browse/JDK-8179301 > https://bugs.openjdk.java.net/browse/JDK-8179303 > > Webrev: > http://cr.openjdk.java.net/~jjg/8179299-8179300-8179301-8179303/webrev.00/ > > > -- Jon > From jan.lahoda at oracle.com Wed Apr 26 12:41:14 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 26 Apr 2017 14:41:14 +0200 Subject: RFR: Fix HTML 5 errors in various langtools modules In-Reply-To: <9a921cea-aab0-5e97-5cf9-63f4923c0939@oracle.com> References: <58FFEC79.4070607@oracle.com> <9a921cea-aab0-5e97-5cf9-63f4923c0939@oracle.com> Message-ID: <5900956A.3090402@oracle.com> Seems OK to me too. Jan On 26.4.2017 03:00, joe darcy wrote: > All the changes look fine Jon; thanks, > > -Joe > > On 4/25/2017 5:40 PM, Jonathan Gibbons wrote: >> compiler-dev, javadoc-dev, kulla-dev folk, >> >> Please review the following collections of trivial changes to make the >> API for these modules HTML 5 compliant. >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8179299 >> https://bugs.openjdk.java.net/browse/JDK-8179300 >> https://bugs.openjdk.java.net/browse/JDK-8179301 >> https://bugs.openjdk.java.net/browse/JDK-8179303 >> >> Webrev: >> http://cr.openjdk.java.net/~jjg/8179299-8179300-8179301-8179303/webrev.00/ >> >> >> -- Jon >> > From kumar.x.srinivasan at oracle.com Wed Apr 26 13:37:38 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 26 Apr 2017 06:37:38 -0700 Subject: RFR: Fix HTML 5 errors in various langtools modules In-Reply-To: <58FFEC79.4070607@oracle.com> References: <58FFEC79.4070607@oracle.com> Message-ID: <5900A2A2.8000008@oracle.com> +1 Kumar On 4/25/2017 5:40 PM, Jonathan Gibbons wrote: > compiler-dev, javadoc-dev, kulla-dev folk, > > Please review the following collections of trivial changes to make the > API for these modules HTML 5 compliant. > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8179299 > https://bugs.openjdk.java.net/browse/JDK-8179300 > https://bugs.openjdk.java.net/browse/JDK-8179301 > https://bugs.openjdk.java.net/browse/JDK-8179303 > > Webrev: > http://cr.openjdk.java.net/~jjg/8179299-8179300-8179301-8179303/webrev.00/ > > > -- Jon > From stuart.marks at oracle.com Wed Apr 26 19:10:11 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 26 Apr 2017 12:10:11 -0700 Subject: JDK 9 RFR(s): 8169203: (jdeprscan) eliminate duplicate "can't find class" errors In-Reply-To: <58FFF0DF.6020703@oracle.com> References: <58FFF0DF.6020703@oracle.com> Message-ID: On 4/25/17 5:59 PM, Jonathan Gibbons wrote: > Look OK to me. > > Line 29 in the test is redundant but not wrong. 24 /* 25 * @test 26 * @bug 8168444 27 * @summary Test of jdeprscan handling of primitives and primitive arrays. 28 * @modules jdk.jdeps/com.sun.tools.jdeprscan 29 * @build jdk.jdeprscan.TestNotFound 30 * @run main jdk.jdeprscan.TestNotFound 31 */ Ha! Yes. This is an old habit I still have from working around CODETOOLS-7900034 [1], which you fixed, um..., four years ago. I'll remove the extra line. Thanks, s'marks [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7900034 > > -- Jon > > On 04/25/2017 05:45 PM, Stuart Marks wrote: >> Hi all, >> >> Please review this small jdeprscan fix for another error message cleanup. This >> time, keep track of which classes aren't found so that a "not found" error is >> emitted only once per class not found. Without this fix, the duplicates can >> overwhelm the rest of the output. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8169203 >> >> Webrev: >> http://cr.openjdk.java.net/~smarks/reviews/8169203/webrev.0/ >> >> Thanks, >> >> s'marks >> > From forax at univ-mlv.fr Fri Apr 28 19:31:31 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 28 Apr 2017 21:31:31 +0200 (CEST) Subject: exports lint is perhaps a little overzealous Message-ID: <356809234.3135667.1493407891018.JavaMail.zimbra@u-pem.fr> javac output warnings when an annotation on public methods or a public class of an exported package comes from a dependencies which is not declared as transitive. I believe that annotations are not really part of the API so should not be checked by exports linter. In my case, the annotation is the JUnit5 @Test, given how JUnit works, the method is always called by reflection so having a requires transitive makes little sense. target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:9: warning: [exports] class Test in module junit.jupiter.api is not indirectly exported using requires transitive @Test ^ target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:15: warning: [exports] class Test in module junit.jupiter.api is not indirectly exported using requires transitive @Test ^ target\test\merged\com.github.forax.pro.api\com\github\forax\pro\api\helper\CmdLineTests.java:22: warning: [exports] class Test in module junit.jupiter.api is not indirectly exported using requires transitive @Test ^ target\test\merged\com.github.forax.pro.helper\com\github\forax\pro\helper\FileHelperTests.java:11: warning: [exports] class Test in module junit.jupiter.api is not indirectly exported using requires transitive @Test ^ regards, R?mi