Jigsaw + Ant
Hi All, the Ant 1.9.7alpha (https://ant.apache.org/nightlies.html) now supports modules in the Javac and Java tasks. The Javac single module compilation example: The Javac multi-module compilation example: The main module execution example: — Tomas
Modularity status?
Hi All, I see 8142968: Module System implementation already included in OpenJDK9 but jake is still in active as well as m3 seems. I just wonder what the status of modularity on OpenJDK9 now? Are there still more changes coming into OpenJDK9 from jake or m3? Thanks a lot!
Re: modulepath and classpath mixture
Russell, when you drop a jar on the classpath, module code will not be able to access it in a split package situation. That's the big barrier here. Maven test projects are typically written with the same package shared with the "main" code. Cheers, Paul On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold wrote: > Hi Stephen, > > Why do you need any kind of friend access? > > It seems to me that this is making things harder than they need to be. The > tests can simply run with the production code on the class path, and then > there are no module issues at all. > > I think a larger problem is that you can do what I just said with the > jars, even a jar which has been designated as a module by virtue of having > a module-info.class in it. That means that, when users are up taking jars, > they are not prevented from accessing module internals. They can put the > jars on the module path, of course, but they can still use them on the > class path! > > - Russ > > > > > On 28 March 2016 at 11:13, Remi Forax wrote: > >> Hi Stephen, Hi all, > >> I think that delivering tests as a separated module is a bad idea. > >> > >> I see that from the point of a developer, seeing the code and the test > as different modules can be attractive because everything seems to be put > at the right place but there is a big drawback. Because modules are reified > at runtime, it means that the runtime environment of the tests will be > different from the production environment. > > > > This last sentence doesn't make sense to me - tests are not run in a > > production environment. > > > > Tests have all the qualities of modules - code, dependencies, > > compilation phase, deployment. The only special part is the need for > > special "friend-like" access, which Jigsaw already has for other cases > > (the export...to clause). > > > > Put simply, I consider that module = > > deployment-artifact-with-dependencies. With that mental model, putting > > tests inside the module is just not acceptable, because tests should > > not be deployed with the main application and they have different > > dependencies. If we disagree that module = > > deployment-artifact-with-dependencies, then perhaps we have bigger > > problems to solve here. > > > > Stephen > > (And to Paul Benedict, the classpath is going to die over time, so any > > solution that uses that is flawed IMO). > > > > > >> So as Alan said, from the jigsaw point of view at runtime, the tests > and the code should be in the same module. > >> > >> So the building tools have to come with a way to support to have 2 > different module-info.java in two different folders and package them as one > module, > >> maybe javac should help by providing a way to merge 2 module-info at > compile time. > >> > >> Rémi > >> > >> - Mail original - > >>> De: "Alan Bateman" > >>> À: "Stephen Colebourne" , "jigsaw-dev" < > jigsaw-dev@openjdk.java.net> > >>> Envoyé: Mercredi 23 Mars 2016 16:18:50 > >>> Objet: Re: modulepath and classpath mixture > >>> > >>> > >>> On 23/03/2016 14:42, Stephen Colebourne wrote: > : > > I don't particularly care what the mechanism is for this, but at the > requirements level: > - there are two modules - main and test > - each has its own source tree > - each has its own dependencies > - each is released separately > - each could be hosted on a central repo > - the test module needs to be able to contain the same packages as the > main module > - the test module needs to be able to invoke package-scoped code in > the same package in the main module > > To clarify further consider 4 modules, A, B, A-test and B-test where B > depends on A. Module A-test may have a method foo() that uses package > scope to access something in A. Module B-test will depend on A-test > and rely on foo() to get access to that internal object. > >>> To your list, I would add the ability to make use of testing frameworks > >>> like TestNG and JUnit. > >>> > >>> In any case, and as things currently stand, you've got most of the > >>> above. One differences is that the tests are not a separate module, > they > >>> are instead compiled and run in a way that patches the main module. The > >>> second difference is that they don't have their own module declaration, > >>> instead the compilation or run augments the dependences with any > >>> additional dependences that the tests have. As I said, if they tools > >>> makes it easy then I don't think it's too bad. > >>> > > (Note that I view the thread discussion of > references to test classes on the classpath as another hack. > > >>> Packages can't be split between modules and classpath so there is no > >>> support for that. > >>> > >>> -Alan > >>> > >
Re: RFR: 8152704: jlink command line output/help message improvement
Thanks. Yes, the usage message is always displayed on PluginException as before. Naoto On 3/29/16 4:40 PM, Mandy Chung wrote: On Mar 29, 2016, at 2:25 PM, Naoto Sato wrote: Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8152704 The suggested change is located at: http://cr.openjdk.java.net/~naoto/8152704/webrev.01/ Looks okay. Does this show the usage message? JlinkTask::run catches PluginException and print “main.usage.summary”. It’d be more appropriate to show the plugin usage message instead that should be addressed by JDK-8152800. Mandy
Re: RFR: 8152704: jlink command line output/help message improvement
> On Mar 29, 2016, at 2:25 PM, Naoto Sato wrote: > > Hello, > > Please review the changes for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8152704 > > The suggested change is located at: > > http://cr.openjdk.java.net/~naoto/8152704/webrev.01/ Looks okay. Does this show the usage message? JlinkTask::run catches PluginException and print “main.usage.summary”. It’d be more appropriate to show the plugin usage message instead that should be addressed by JDK-8152800. Mandy
Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time
Hi Peter, Mandy,
On 2016-03-26 12:47, Peter Levart wrote:
Comparing this with proposed code from webrev:
493 try {
494 return (ClassBoundMethodHandle>)
495 Class.forName("java.lang.invoke.BoundMethodHandle$Species_" +
LambdaForm.shortenSignature(types));
496 } catch (ClassNotFoundException cnf) {
497 // Not pregenerated, generate the class
498 return generateConcreteBMHClass(types);
499 }
...note that the function passed to CLASS_CACHE.computeIfAbsent is
executed just once per distinct 'types' argument. Even if you put the
generated switch between a call to getConcreteBMHClass and
CLASS_CACHE.computeIfAbsent, getConcreteBMHClass(String types) is
executed just once per distinct 'types' argument (except in rare
occasions when VM can not initialize the loaded class).
In this respect a successful Class.forName() is not any worse than
static resolving. It's just that unsuccessful Class.forName()
represents some overhead for classes that are not pre-generated. So an
alternative way to get rid of that overhead is to have a HashSet of
'types' strings for pre-generated classes at hand in order to decide
whether to call Class.forName or generateConcreteBMHClass.
What's easier to support is another question.
Regards, Peter
to have something to compare with I built a version which, like you
suggest,
generates a HashSet with the set of generated classes here:
http://cr.openjdk.java.net/~redestad/8152641/webrev.02/
This adds a fair bit of complexity to the plugin and requires we add a
nested
class in BoundMethodHandle that we can replace. Using the anonymous
compute Function for this seems like the best choice for this.
I've not been able to measure any statistical difference in real startup
terms,
though, and not figured out a smart way to benchmark the overhead of the
CNFE in relation to the class generation (my guess it adds a fraction to
the
total cost) and since this adds ever so little footprint and an extra
lookup to the
fast path it would seem that this is the wrong trade-off to do here.
All-in-all I lean towards moving forward with the first, simpler
revision of this
patch[1] and then evaluate if webrev.02 or a String-switch+static resolve
as a follow-up.
A compromise would be to keep the SpeciesLookup class introduced here
to allow removing all overhead in case the plugin is disabled.
Mandy: I've not found any test (under jdk/test/tools/jlink or elsewhere)
which
has to be updated when adding a plugin like this.
Thanks!
/Claes
[1] http://cr.openjdk.java.net/~redestad/8152641/webrev.01/
RFR: 8152704: jlink command line output/help message improvement
Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8152704 The suggested change is located at: http://cr.openjdk.java.net/~naoto/8152704/webrev.01/ Naoto
Re: Please review 8148491: Revisit jlink --genbom
On 29/03/2016 16:38, Sundararajan Athijegannathan wrote: Hi, Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8148491 This looks to me. A minor nit in TaskHelper.getPluginsConfig where removing genbom leaves a ) in mid air. -Alan
Re: modulepath and classpath mixture
Hi Stephen, Why do you need any kind of friend access? It seems to me that this is making things harder than they need to be. The tests can simply run with the production code on the class path, and then there are no module issues at all. I think a larger problem is that you can do what I just said with the jars, even a jar which has been designated as a module by virtue of having a module-info.class in it. That means that, when users are up taking jars, they are not prevented from accessing module internals. They can put the jars on the module path, of course, but they can still use them on the class path! - Russ > > On 28 March 2016 at 11:13, Remi Forax wrote: >> Hi Stephen, Hi all, >> I think that delivering tests as a separated module is a bad idea. >> >> I see that from the point of a developer, seeing the code and the test as >> different modules can be attractive because everything seems to be put at >> the right place but there is a big drawback. Because modules are reified at >> runtime, it means that the runtime environment of the tests will be >> different from the production environment. > > This last sentence doesn't make sense to me - tests are not run in a > production environment. > > Tests have all the qualities of modules - code, dependencies, > compilation phase, deployment. The only special part is the need for > special "friend-like" access, which Jigsaw already has for other cases > (the export...to clause). > > Put simply, I consider that module = > deployment-artifact-with-dependencies. With that mental model, putting > tests inside the module is just not acceptable, because tests should > not be deployed with the main application and they have different > dependencies. If we disagree that module = > deployment-artifact-with-dependencies, then perhaps we have bigger > problems to solve here. > > Stephen > (And to Paul Benedict, the classpath is going to die over time, so any > solution that uses that is flawed IMO). > > >> So as Alan said, from the jigsaw point of view at runtime, the tests and the >> code should be in the same module. >> >> So the building tools have to come with a way to support to have 2 different >> module-info.java in two different folders and package them as one module, >> maybe javac should help by providing a way to merge 2 module-info at compile >> time. >> >> Rémi >> >> - Mail original - >>> De: "Alan Bateman" >>> À: "Stephen Colebourne" , "jigsaw-dev" >>> >>> Envoyé: Mercredi 23 Mars 2016 16:18:50 >>> Objet: Re: modulepath and classpath mixture >>> >>> >>> On 23/03/2016 14:42, Stephen Colebourne wrote: : I don't particularly care what the mechanism is for this, but at the requirements level: - there are two modules - main and test - each has its own source tree - each has its own dependencies - each is released separately - each could be hosted on a central repo - the test module needs to be able to contain the same packages as the main module - the test module needs to be able to invoke package-scoped code in the same package in the main module To clarify further consider 4 modules, A, B, A-test and B-test where B depends on A. Module A-test may have a method foo() that uses package scope to access something in A. Module B-test will depend on A-test and rely on foo() to get access to that internal object. >>> To your list, I would add the ability to make use of testing frameworks >>> like TestNG and JUnit. >>> >>> In any case, and as things currently stand, you've got most of the >>> above. One differences is that the tests are not a separate module, they >>> are instead compiled and run in a way that patches the main module. The >>> second difference is that they don't have their own module declaration, >>> instead the compilation or run augments the dependences with any >>> additional dependences that the tests have. As I said, if they tools >>> makes it easy then I don't think it's too bad. >>> (Note that I view the thread discussion of references to test classes on the classpath as another hack. >>> Packages can't be split between modules and classpath so there is no >>> support for that. >>> >>> -Alan >>>
RE: argsfile problem
For you gradle experts, the syntax below is obviously wrong. options.compilerArgs << '@/argsfile' Maybe we can get the gradle folks to recognize @filename and expand it into their argsfile? -Original Message- From: Stephen Felts Sent: Tuesday, March 29, 2016 12:33 PM To: jigsaw-dev Subject: argsfile problem Here’s an interesting problem. I have a lot of JDK9-specific command line options. I decided to try to put them into an argsfile. I then tried to use the @argsfile in a gradle script using something like options.compilerArgs=’@/argsfile’ I was getting a ‘javac: invalid flag: @/argsfile’ and couldn’t figure out why. The answer is that gradle is using an argsfile so I ended up with an argsfile within an argsfile.
argsfile problem
Here’s an interesting problem. I have a lot of JDK9-specific command line options. I decided to try to put them into an argsfile. I then tried to use the @argsfile in a gradle script using something like options.compilerArgs=’@/argsfile’ I was getting a ‘javac: invalid flag: @/argsfile’ and couldn’t figure out why. The answer is that gradle is using an argsfile so I ended up with an argsfile within an argsfile.
Re: modulepath and classpath mixture
Paul, you can give a different version to your module but you don't have to. Test can use the very same module name along with the same version. Rémi - Mail original - > De: "Paul Benedict" > À: "Remi Forax" > Cc: "Stephen Colebourne" , "jigsaw-dev" > > Envoyé: Mardi 29 Mars 2016 17:55:10 > Objet: Re: modulepath and classpath mixture > Remi, it's really untenable to give tests a different version. Tests are > currently built under the same version as the main project under one master > parent project. Split packages are still going to be a necessary because > that's the world of thousands of existing projects. So that might be against > jigsaw canon but hopefully a compromise can be found. > Cheers, > Paul > On Tue, Mar 29, 2016 at 10:41 AM, Remi Forax < fo...@univ-mlv.fr > wrote: > > - Mail original - > > > > De: "Stephen Colebourne" < scolebou...@joda.org > > > > > À: "jigsaw-dev" < jigsaw-dev@openjdk.java.net > > > > > Envoyé: Mardi 29 Mars 2016 15:24:15 > > > > Objet: Re: modulepath and classpath mixture > > > > > > > > On 28 March 2016 at 11:13, Remi Forax < fo...@univ-mlv.fr > wrote: > > > > > Hi Stephen, Hi all, > > > > > I think that delivering tests as a separated module is a bad idea. > > > > > > > > > > I see that from the point of a developer, seeing the code and the test > > > > as > > > > > different modules can be attractive because everything seems to be put > > > > at > > > > > the right place but there is a big drawback. Because modules are > > > > reified > > > > > at runtime, it means that the runtime environment of the tests will be > > > > > different from the production environment. > > > > > > > > This last sentence doesn't make sense to me - tests are not run in a > > > > production environment. > > > yes, you just want your tests to run in a runtime which is as close as > > possible to the runtime of the production environment. > > > It's like when a test fails because JUnit calls the test concurrently when > > in > > production the code always run under a giant lock. > > > > > > > > Tests have all the qualities of modules - code, dependencies, > > > > compilation phase, deployment. The only special part is the need for > > > > special "friend-like" access, which Jigsaw already has for other cases > > > > (the export...to clause). > > > You also need to support split packages or a kind of export...to that > > allows > > to export package private method as public. > > > These are two major deviations from the jigsaw canon. > > > Instead of considering tests as a separated module, i prefer to consider > > them > > as a separated version (1.0 vs 1.0-test), > > > the test version includes the code, the tests, and have several more > > dependencies on JUnit like modules. > > > > > > > > Put simply, I consider that module = > > > > deployment-artifact-with-dependencies. With that mental model, putting > > > > tests inside the module is just not acceptable, because tests should > > > > not be deployed with the main application and they have different > > > > dependencies. If we disagree that module = > > > > deployment-artifact-with-dependencies, then perhaps we have bigger > > > > problems to solve here. > > > We agree that a module = deployment-artifact-with-dependencies, but we > > disagree because for me the test should be a module with the same name but > > a > > different version (by example with a test suffix) while you think it should > > be a different module. > > > > > > > > Stephen > > > > (And to Paul Benedict, the classpath is going to die over time, so any > > > > solution that uses that is flawed IMO). > > > I don't think the classpath will die but if you want to use things like > > jlink, it will not work if you have jars in the a classpath. > > > Rémi > > > > > > > > > > > > > So as Alan said, from the jigsaw point of view at runtime, the tests > > > > and > > > > > the code should be in the same module. > > > > > > > > > > So the building tools have to come with a way to support to have 2 > > > > > different module-info.java in two different folders and package them as > > > > > one module, > > > > > maybe javac should help by providing a way to merge 2 module-info at > > > > > compile time. > > > > > > > > > > Rémi > > > > > > > > > > - Mail original - > > > > >> De: "Alan Bateman" < alan.bate...@oracle.com > > > > > >> À: "Stephen Colebourne" < scolebou...@joda.org >, "jigsaw-dev" > > > > >> < jigsaw-dev@openjdk.java.net > > > > > >> Envoyé: Mercredi 23 Mars 2016 16:18:50 > > > > >> Objet: Re: modulepath and classpath mixture > > > > >> > > > > >> > > > > >> On 23/03/2016 14:42, Stephen Colebourne wrote: > > > > >> > : > > > > >> > > > > > >> > I don't particularly care what the mechanism is for this, but at the > > > > >> > requirements level: > > > > >> > - there are two modules - main and test > > > > >> > - each has its own source tree > > > > >>
Re: modulepath and classpath mixture
Remi, it's really untenable to give tests a different version. Tests are currently built under the same version as the main project under one master parent project. Split packages are still going to be a necessary because that's the world of thousands of existing projects. So that might be against jigsaw canon but hopefully a compromise can be found. Cheers, Paul On Tue, Mar 29, 2016 at 10:41 AM, Remi Forax wrote: > > > - Mail original - > > De: "Stephen Colebourne" > > À: "jigsaw-dev" > > Envoyé: Mardi 29 Mars 2016 15:24:15 > > Objet: Re: modulepath and classpath mixture > > > > On 28 March 2016 at 11:13, Remi Forax wrote: > > > Hi Stephen, Hi all, > > > I think that delivering tests as a separated module is a bad idea. > > > > > > I see that from the point of a developer, seeing the code and the test > as > > > different modules can be attractive because everything seems to be put > at > > > the right place but there is a big drawback. Because modules are > reified > > > at runtime, it means that the runtime environment of the tests will be > > > different from the production environment. > > > > This last sentence doesn't make sense to me - tests are not run in a > > production environment. > > yes, you just want your tests to run in a runtime which is as close as > possible to the runtime of the production environment. > It's like when a test fails because JUnit calls the test concurrently when > in production the code always run under a giant lock. > > > > > Tests have all the qualities of modules - code, dependencies, > > compilation phase, deployment. The only special part is the need for > > special "friend-like" access, which Jigsaw already has for other cases > > (the export...to clause). > > You also need to support split packages or a kind of export...to that > allows to export package private method as public. > These are two major deviations from the jigsaw canon. > > Instead of considering tests as a separated module, i prefer to consider > them as a separated version (1.0 vs 1.0-test), > the test version includes the code, the tests, and have several more > dependencies on JUnit like modules. > > > > > Put simply, I consider that module = > > deployment-artifact-with-dependencies. With that mental model, putting > > tests inside the module is just not acceptable, because tests should > > not be deployed with the main application and they have different > > dependencies. If we disagree that module = > > deployment-artifact-with-dependencies, then perhaps we have bigger > > problems to solve here. > > We agree that a module = deployment-artifact-with-dependencies, but we > disagree because for me the test should be a module with the same name but > a different version (by example with a test suffix) while you think it > should be a different module. > > > > > Stephen > > (And to Paul Benedict, the classpath is going to die over time, so any > > solution that uses that is flawed IMO). > > I don't think the classpath will die but if you want to use things like > jlink, it will not work if you have jars in the a classpath. > > Rémi > > > > > > > > So as Alan said, from the jigsaw point of view at runtime, the tests > and > > > the code should be in the same module. > > > > > > So the building tools have to come with a way to support to have 2 > > > different module-info.java in two different folders and package them as > > > one module, > > > maybe javac should help by providing a way to merge 2 module-info at > > > compile time. > > > > > > Rémi > > > > > > - Mail original - > > >> De: "Alan Bateman" > > >> À: "Stephen Colebourne" , "jigsaw-dev" > > >> > > >> Envoyé: Mercredi 23 Mars 2016 16:18:50 > > >> Objet: Re: modulepath and classpath mixture > > >> > > >> > > >> On 23/03/2016 14:42, Stephen Colebourne wrote: > > >> > : > > >> > > > >> > I don't particularly care what the mechanism is for this, but at the > > >> > requirements level: > > >> > - there are two modules - main and test > > >> > - each has its own source tree > > >> > - each has its own dependencies > > >> > - each is released separately > > >> > - each could be hosted on a central repo > > >> > - the test module needs to be able to contain the same packages as > the > > >> > main module > > >> > - the test module needs to be able to invoke package-scoped code in > > >> > the same package in the main module > > >> > > > >> > To clarify further consider 4 modules, A, B, A-test and B-test > where B > > >> > depends on A. Module A-test may have a method foo() that uses > package > > >> > scope to access something in A. Module B-test will depend on A-test > > >> > and rely on foo() to get access to that internal object. > > >> To your list, I would add the ability to make use of testing > frameworks > > >> like TestNG and JUnit. > > >> > > >> In any case, and as things currently stand, you've got most of the > > >> above. One differences is that the tests are not a separate module, > they > > >> are instead
Re: Please review 8148491: Revisit jlink --genbom
+1 > On Mar 29, 2016, at 12:38 PM, Sundararajan Athijegannathan > wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8148491 > > Thanks, > -Sundar
Re: modulepath and classpath mixture
- Mail original - > De: "Stephen Colebourne" > À: "jigsaw-dev" > Envoyé: Mardi 29 Mars 2016 15:24:15 > Objet: Re: modulepath and classpath mixture > > On 28 March 2016 at 11:13, Remi Forax wrote: > > Hi Stephen, Hi all, > > I think that delivering tests as a separated module is a bad idea. > > > > I see that from the point of a developer, seeing the code and the test as > > different modules can be attractive because everything seems to be put at > > the right place but there is a big drawback. Because modules are reified > > at runtime, it means that the runtime environment of the tests will be > > different from the production environment. > > This last sentence doesn't make sense to me - tests are not run in a > production environment. yes, you just want your tests to run in a runtime which is as close as possible to the runtime of the production environment. It's like when a test fails because JUnit calls the test concurrently when in production the code always run under a giant lock. > > Tests have all the qualities of modules - code, dependencies, > compilation phase, deployment. The only special part is the need for > special "friend-like" access, which Jigsaw already has for other cases > (the export...to clause). You also need to support split packages or a kind of export...to that allows to export package private method as public. These are two major deviations from the jigsaw canon. Instead of considering tests as a separated module, i prefer to consider them as a separated version (1.0 vs 1.0-test), the test version includes the code, the tests, and have several more dependencies on JUnit like modules. > > Put simply, I consider that module = > deployment-artifact-with-dependencies. With that mental model, putting > tests inside the module is just not acceptable, because tests should > not be deployed with the main application and they have different > dependencies. If we disagree that module = > deployment-artifact-with-dependencies, then perhaps we have bigger > problems to solve here. We agree that a module = deployment-artifact-with-dependencies, but we disagree because for me the test should be a module with the same name but a different version (by example with a test suffix) while you think it should be a different module. > > Stephen > (And to Paul Benedict, the classpath is going to die over time, so any > solution that uses that is flawed IMO). I don't think the classpath will die but if you want to use things like jlink, it will not work if you have jars in the a classpath. Rémi > > > > So as Alan said, from the jigsaw point of view at runtime, the tests and > > the code should be in the same module. > > > > So the building tools have to come with a way to support to have 2 > > different module-info.java in two different folders and package them as > > one module, > > maybe javac should help by providing a way to merge 2 module-info at > > compile time. > > > > Rémi > > > > - Mail original - > >> De: "Alan Bateman" > >> À: "Stephen Colebourne" , "jigsaw-dev" > >> > >> Envoyé: Mercredi 23 Mars 2016 16:18:50 > >> Objet: Re: modulepath and classpath mixture > >> > >> > >> On 23/03/2016 14:42, Stephen Colebourne wrote: > >> > : > >> > > >> > I don't particularly care what the mechanism is for this, but at the > >> > requirements level: > >> > - there are two modules - main and test > >> > - each has its own source tree > >> > - each has its own dependencies > >> > - each is released separately > >> > - each could be hosted on a central repo > >> > - the test module needs to be able to contain the same packages as the > >> > main module > >> > - the test module needs to be able to invoke package-scoped code in > >> > the same package in the main module > >> > > >> > To clarify further consider 4 modules, A, B, A-test and B-test where B > >> > depends on A. Module A-test may have a method foo() that uses package > >> > scope to access something in A. Module B-test will depend on A-test > >> > and rely on foo() to get access to that internal object. > >> To your list, I would add the ability to make use of testing frameworks > >> like TestNG and JUnit. > >> > >> In any case, and as things currently stand, you've got most of the > >> above. One differences is that the tests are not a separate module, they > >> are instead compiled and run in a way that patches the main module. The > >> second difference is that they don't have their own module declaration, > >> instead the compilation or run augments the dependences with any > >> additional dependences that the tests have. As I said, if they tools > >> makes it easy then I don't think it's too bad. > >> > >> > > >> > (Note that I view the thread discussion of > >> > references to test classes on the classpath as another hack. > >> > > >> Packages can't be split between modules and classpath so there is no > >> support for that. > >> > >> -Alan > >> >
Please review 8148491: Revisit jlink --genbom
Hi, Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8148491 Thanks, -Sundar
Re: Jigsaw + Web Start
Hi Alan, >> Hi Alan, >> Thanks for your quick reply. >> Yes, we have code (and depend on libraries) that use, approximately: >> com.sun.java.swing.plaf > Are you sure you are using classes in this package directly? The L&F is > usually specified as a String. We have also a product wich use Java WebStart and we use classes from com.sun.java.swing.plaf. We use in our product JGoodies Looks. And JGoodies Windows L&F extends some classes from this package. Here is one example: http://grepcode.com/file/repo1.maven.org/maven2/com.jgoodies/jgoodies-looks/2.5.3/com/jgoodies/looks/windows/WindowsLookAndFeel.java?av=f#71 Best regards, Andrej Golovnin
Re: modulepath and classpath mixture
On 28 March 2016 at 11:13, Remi Forax wrote: > Hi Stephen, Hi all, > I think that delivering tests as a separated module is a bad idea. > > I see that from the point of a developer, seeing the code and the test as > different modules can be attractive because everything seems to be put at the > right place but there is a big drawback. Because modules are reified at > runtime, it means that the runtime environment of the tests will be different > from the production environment. This last sentence doesn't make sense to me - tests are not run in a production environment. Tests have all the qualities of modules - code, dependencies, compilation phase, deployment. The only special part is the need for special "friend-like" access, which Jigsaw already has for other cases (the export...to clause). Put simply, I consider that module = deployment-artifact-with-dependencies. With that mental model, putting tests inside the module is just not acceptable, because tests should not be deployed with the main application and they have different dependencies. If we disagree that module = deployment-artifact-with-dependencies, then perhaps we have bigger problems to solve here. Stephen (And to Paul Benedict, the classpath is going to die over time, so any solution that uses that is flawed IMO). > So as Alan said, from the jigsaw point of view at runtime, the tests and the > code should be in the same module. > > So the building tools have to come with a way to support to have 2 different > module-info.java in two different folders and package them as one module, > maybe javac should help by providing a way to merge 2 module-info at compile > time. > > Rémi > > - Mail original - >> De: "Alan Bateman" >> À: "Stephen Colebourne" , "jigsaw-dev" >> >> Envoyé: Mercredi 23 Mars 2016 16:18:50 >> Objet: Re: modulepath and classpath mixture >> >> >> On 23/03/2016 14:42, Stephen Colebourne wrote: >> > : >> > >> > I don't particularly care what the mechanism is for this, but at the >> > requirements level: >> > - there are two modules - main and test >> > - each has its own source tree >> > - each has its own dependencies >> > - each is released separately >> > - each could be hosted on a central repo >> > - the test module needs to be able to contain the same packages as the >> > main module >> > - the test module needs to be able to invoke package-scoped code in >> > the same package in the main module >> > >> > To clarify further consider 4 modules, A, B, A-test and B-test where B >> > depends on A. Module A-test may have a method foo() that uses package >> > scope to access something in A. Module B-test will depend on A-test >> > and rely on foo() to get access to that internal object. >> To your list, I would add the ability to make use of testing frameworks >> like TestNG and JUnit. >> >> In any case, and as things currently stand, you've got most of the >> above. One differences is that the tests are not a separate module, they >> are instead compiled and run in a way that patches the main module. The >> second difference is that they don't have their own module declaration, >> instead the compilation or run augments the dependences with any >> additional dependences that the tests have. As I said, if they tools >> makes it easy then I don't think it's too bad. >> >> > >> > (Note that I view the thread discussion of >> > references to test classes on the classpath as another hack. >> > >> Packages can't be split between modules and classpath so there is no >> support for that. >> >> -Alan >>
hg: jigsaw/jake/jdk: Drop support for old style -XaddExports and -XaddReads
Changeset: a7a44ba9e6d8 Author:alanb Date: 2016-03-29 13:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a7a44ba9e6d8 Drop support for old style -XaddExports and -XaddReads ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh ! test/tools/launcher/modules/patch/PatchTest.java
hg: jigsaw/jake/langtools: Drop support for old style -XaddExports and -XaddReads
Changeset: 496a2a78b2a4 Author:alanb Date: 2016-03-29 13:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/496a2a78b2a4 Drop support for old style -XaddExports and -XaddReads ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/platform/PlatformProviderTest.java
Re: Jigsaw + Web Start
> On 29 Mar 2016, at 12:15, Alan Bateman wrote: > >> On 29/03/2016 11:03, Robert Gibson wrote: >> : >> Hi Alan, >> Thanks for your quick reply. >> Yes, we have code (and depend on libraries) that use, approximately: >> com.sun.java.swing.plaf > Are you sure you are using classes in this package directly? The L&F is > usually specified as a String. Our historical preference for compile-time type errors gives rise to code like if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel) [Various other packages snipped] > >> >> We will at some point get around to re-writing the code that we have control >> over but would like to have flexibility over when we do this, and not have >> it as a precondition for upgrading our clients to Java 9. Currently it seems >> that -XaddExports doesn't have any effect in a JNLP file and I assumed that >> was a whitelisting issue with VM arguments and Web Start - but maybe it is >> supposed to work at this point? > -XaddExports has not been added to the options allowed to be specified with > the java-vm-args attribute. It probably should be considered so as to have > consistency with the command line (within reason of course, anything allowed > to be specified via java-vm-args requires thinking about security). > > -Alan Like I said, we will get around to rewriting what absolutely needs to be tweaked where we can, but being able to use the escape hatch like a command-line app (along with fixes for 8152838 and 8152839) will allow us to continue our testing. Thanks, Robert
Re: Jigsaw + Web Start
On 29/03/2016 11:03, Robert Gibson wrote: : Hi Alan, Thanks for your quick reply. Yes, we have code (and depend on libraries) that use, approximately: com.sun.java.swing.plaf Are you sure you are using classes in this package directly? The L&F is usually specified as a String. com.sun.org.apache.xerces com.sun.jmx.remote.util com.sun.management com.sun.management is a supported/documented API, exported by the jdk.management module, so you should be okay here, unless you are making use of some of its internal types. com.sun.jndi.ldap Are you making direct use of types in this package? Just curious as creating the initial context specifies the provider name as String. Also all the configuration is Strings too. com.sun.crypto.provider I'm also curious about this one. We will at some point get around to re-writing the code that we have control over but would like to have flexibility over when we do this, and not have it as a precondition for upgrading our clients to Java 9. Currently it seems that -XaddExports doesn't have any effect in a JNLP file and I assumed that was a whitelisting issue with VM arguments and Web Start - but maybe it is supposed to work at this point? -XaddExports has not been added to the options allowed to be specified with the java-vm-args attribute. It probably should be considered so as to have consistency with the command line (within reason of course, anything allowed to be specified via java-vm-args requires thinking about security). -Alan
Re: Jigsaw + Web Start
> On 29 Mar 2016, at 11:39, Alan Bateman wrote: > >> On 29/03/2016 10:10, Robert Gibson wrote: >> Hi all, >> We have a number of applications launched over Web Start. Unfortunately none >> of them work with the latest JDK build, it looks like the closed-source Web >> Start implementation is not a testing priority for Oracle, so I put my >> shoulder to the wheel and filed a few bugs. >> >> Anyway, I haven't seen any mention of Web Start in the various Jigsaw >> documents, can I assume that there is a plan to add the "emergency hatch" VM >> options to the java-vm-args whitelist? Without it we are dead in the water, >> and I assume we are not alone! > There was a huge effort behind the scenes to get Web Start working as > modules. I'm only aware of one issue so far. That issue is that transitive > closure of the jdk.javaws module is limit the modules that can be read by > applications launched in the same VM as the javaws launcher. A fix for this > is in progress. > > So what issues are you running into that requires changing the java-vm-args > whitelist? Are these applications using JDK-internal APIs? > > -Alan Hi Alan, Thanks for your quick reply. Yes, we have code (and depend on libraries) that use, approximately: com.sun.java.swing.plaf com.sun.org.apache.xerces com.sun.jmx.remote.util com.sun.management com.sun.jndi.ldap com.sun.crypto.provider We will at some point get around to re-writing the code that we have control over but would like to have flexibility over when we do this, and not have it as a precondition for upgrading our clients to Java 9. Currently it seems that -XaddExports doesn't have any effect in a JNLP file and I assumed that was a whitelisting issue with VM arguments and Web Start - but maybe it is supposed to work at this point? Regards, Robert
Re: trouble with java -Xpatch
On 29/03/2016 10:14, Michael Rasmussen wrote: With the new -Xpatch format, are there any plans to add support for adding (or modifying) these from JVMTI in the OnLoad phase? /Michael Not specifically but you can use -Xpatch in conjunction with -agentlib/-agentpath. Also if enable the new can_generate_early_vmstart capability then you can use the ClassFileLoadHook to patch classes loaded early in the startup. In previous threads I think you mentioned this was something you were looking to do. -Alan
Re: Jigsaw + Web Start
On 29/03/2016 10:10, Robert Gibson wrote: Hi all, We have a number of applications launched over Web Start. Unfortunately none of them work with the latest JDK build, it looks like the closed-source Web Start implementation is not a testing priority for Oracle, so I put my shoulder to the wheel and filed a few bugs. Anyway, I haven't seen any mention of Web Start in the various Jigsaw documents, can I assume that there is a plan to add the "emergency hatch" VM options to the java-vm-args whitelist? Without it we are dead in the water, and I assume we are not alone! There was a huge effort behind the scenes to get Web Start working as modules. I'm only aware of one issue so far. That issue is that transitive closure of the jdk.javaws module is limit the modules that can be read by applications launched in the same VM as the javaws launcher. A fix for this is in progress. So what issues are you running into that requires changing the java-vm-args whitelist? Are these applications using JDK-internal APIs? -Alan
Re: trouble with java -Xpatch
With the new -Xpatch format, are there any plans to add support for adding (or modifying) these from JVMTI in the OnLoad phase? /Michael On 28 March 2016 at 20:30, Alan Bateman wrote: > > Sorry, it is a bit confusing as we aren't quite done with the transition > from an older form of a -Xpatch to the new form. > > The syntax you see in JEP 261 and in the java -X usage output is the new > form. That works for modules defined to the platform or application class > loaders but doesn't work for modules (like java.base) that are defined to > the boot loader. Lois is working on the missing piece in hotspot, it is > tracked by JDK-8146448. All the other pieces (in javac and the runtime) are > in place. > > In the mean-time, the old form still works. The old syntax is > -Xpatch:(:*) where is a directory of exploded patches. If > you want to override CHM then you would run with -Xpatch:jsr166 where jsr166 > contains: > > java.base/java/util/concurrent/ConcurrentHashMap.class > > You can use the old syntax with the first usage of -Xpatch, not second or > subsequent usages. That is why you see a difference in the -Xpatch:junk > behavior when you specify it more than once. > > -Alan.
Jigsaw + Web Start
Hi all, We have a number of applications launched over Web Start. Unfortunately none of them work with the latest JDK build, it looks like the closed-source Web Start implementation is not a testing priority for Oracle, so I put my shoulder to the wheel and filed a few bugs. Anyway, I haven't seen any mention of Web Start in the various Jigsaw documents, can I assume that there is a plan to add the "emergency hatch" VM options to the java-vm-args whitelist? Without it we are dead in the water, and I assume we are not alone! Thanks, Robert
