RE: Issue with an automatic module

[charbel yazbeck]

hi,


most of the open sources jars  have classes with unnamed package, like 
nar-maven-plugin.

Any idea how can i solve this? Do i have to implement my own version of 
ModuleFinder?

Some examples:  D:\.m2\jdom\jdom\1.0\jdom-1.0.jar, 
D:\.m2\net\java\dev\javacc\javacc\5.0\javacc-5.0.jar, 
D:\.m2\hsqldb\hsqldb\1.8.0.7\hsqldb-1.8.0.7.jar


thank you





De : Alan Bateman 
Envoyé : lundi 1 août 2016 22:00
À : charbel yazbeck; jigsaw-dev@openjdk.java.net
Objet : Re: Issue with an automatic module


On 01/08/2016 12:01, charbel yazbeck wrote:

hi


I was just trying the following sample:


ModuleFinder finder = ModuleFinder.of(path);   //path points to the 
location of a jar with an unnamed module
finder.findAll().forEach(System.out::println);

I see nar-maven-plugin-3.0.0.jar has a class HelpMojo.class, do you know if 
this is supposed to be in this JAR file?

In any case, it is as I said, named modules can not contain types in the 
unnamed package so this is why ModuleFinder fails. In this javadoc where it 
describes automatic it has the following "If a .class file that corresponds to 
a class in an unnamed package is encountered then FindException is thrown."

-Alan

Re: Issue with an automatic module

[Paul Benedict]

Charbel, have you looked into the Maven Shade Plugin? I wonder if you could
shade what's in the unnamed package so as to put it in some other named
package?

Cheers,
Paul

On Tue, Aug 2, 2016 at 2:21 AM, charbel yazbeck  wrote:

> hi,
>
>
> most of the open sources jars  have classes with unnamed package, like
> nar-maven-plugin.
>
> Any idea how can i solve this? Do i have to implement my own version of
> ModuleFinder?
>
> Some examples:  D:\.m2\jdom\jdom\1.0\jdom-1.0.jar,
> D:\.m2\net\java\dev\javacc\javacc\5.0\javacc-5.0.jar,
> D:\.m2\hsqldb\hsqldb\1.8.0.7\hsqldb-1.8.0.7.jar
>
>
> thank you
>
>
>
>
> 
> De : Alan Bateman 
> Envoyé : lundi 1 août 2016 22:00
> À : charbel yazbeck; jigsaw-dev@openjdk.java.net
> Objet : Re: Issue with an automatic module
>
>
> On 01/08/2016 12:01, charbel yazbeck wrote:
>
> hi
>
>
> I was just trying the following sample:
>
>
> ModuleFinder finder = ModuleFinder.of(path);   //path points to
> the location of a jar with an unnamed module
> finder.findAll().forEach(System.out::println);
>
> I see nar-maven-plugin-3.0.0.jar has a class HelpMojo.class, do you know
> if this is supposed to be in this JAR file?
>
> In any case, it is as I said, named modules can not contain types in the
> unnamed package so this is why ModuleFinder fails. In this javadoc where it
> describes automatic it has the following "If a .class file that corresponds
> to a class in an unnamed package is encountered then FindException is
> thrown."
>
> -Alan
>

Re: Exporting - the wrong default?

[dalibor topic]

On 01.08.2016 16:04, David M. Lloyd wrote:

With my proposal, if there are any
doubts about a class, you make it non-public (regardless of what package
it is in), which is a very simple criterion.  In addition, you make the
public/non-public choice on a per-class basis, not a per-package basis,
which is also useful as well as intuitive.


How do I make a single class non-public in a third party component?

cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: Issue with an automatic module

[Andrew Dinn]

On 02/08/16 08:21, charbel yazbeck wrote:
> most of the open sources jars  have classes with unnamed package, like 
> nar-maven-plugin.

Hmm, citation needed for that I think.

In my experience it is extremely rare for production code to place
classes in the unnamed module. It is extremely bad practice to do so
because it invites name space clashes. I'm astonished that someone
thought it was ok to do this in a maven plugin. But then again ...

> Any idea how can i solve this? Do i have to implement my own version of 
> ModuleFinder?

Getting the owner of the jar to release a new jar with the class in a
sensible package is a far better solution.

If you really have to use such a jar then I guess you can always use the
maven shade plugin to generate a variant that has contains the offending
class(es) in a suitably named module. But that's probably not going to
be a great solution when you are trying to use the maven plugin from
maven (chicken and egg issues?) -- I guess you will need to deploy your
own fixed variant in a suitable repo before consuming it in your project.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file

[Sundararajan Athijegannathan]

Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8159487

OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
fix. Just adding "JAVA_VERSION" and a test change to check these
properties exist in release file.

Thanks

-Sundar

Re: Exporting - the wrong default?

[dalibor topic]

On 01.08.2016 16:04, David M. Lloyd wrote:

On 08/01/2016 05:40 AM, dalibor topic wrote:

Is it safe to assume that all such involuntarily headache inducing
Slings and Stones are also kept under lock in non-public classes?


Of course not, no more than it is safe to assume that such will be kept
hidden in non-exported packages under the existing regime.


Great - I think we can agree that some inadvertently headache inducing 
classes might be public and some might be not.


Let's now consider two different scenarios, in which Sling and Stone are 
either public, or not, and denote the variants with a P or N prefix - 
PSling is a public Sling, while NStone is a non-public Stone, for example.


Let's also consider two defaults: permissive (i.e. all packages are 
exported) and fail safe (i.e. no packages are exported).


Permissive:
PSling + PStone can induce a headache, while the other three cases 
fortunately can not. So a mere 25% opportunity for a headache.


Fail safe:
none of the four cases induce a headache.

Let's now add reflection & setAccessible to the mix.

To make the example more plastic, let's hypothetically assume that the 
Sling is some kind of a universal reflector utility class, which has a 
method that kindly performs a reflective operation upon polite request, 
using setAccessible if necessary to access otherwise inaccessible 
members, while violating SEC05-J [0]. Let's also assume that the Stone 
has some other potentially headache inducing problem.


Again, no headache occurs in the Failsafe case, because no packages are 
exported, while at the same time in the Permissive case, both the 
PSling+PStone and PSling+NStone cases now can induce a headache.


Fortunately, the other two cases still do not, so that's a mere 50% 
opportunity for headache.


A coin toss, in other words.

Now let's consider the Fail safe default with developers optionally 
exporting packages containing Sling and Stone. Let's mark classes 
contained in an exported package with an X prefix, while those that 
aren't get an O.


The headache inducing cases are

XPSling+XPStone and XPSling+XNStone

while the other 14 cases are not.

While headaches can no longer be excluded, that's quite a bit better 
than a coin toss, or even just the initial permissive scenario without 
use of reflection & setAccessible in the Sling.


Of course, you can get to the same cases starting with a Permissive 
default and then restricting exports of the packages in question.


Yet, there is an interesting difference between the two scenarios:

a) in the fail safe default case you start at no risk of headache 
inducing combinations of Slings and Stones, and then can increase your 
risk of a headache occurring to a certain level by adding exports, while 
in the permissive case you start at a coin toss level of headache risk 
and have to remove exports to decrease it to the same level, and


b) regardless of how many Slings and Stones there are in the mix, you 
always start at no risk of headache inducing combinations of Stones and 
Slings in the fail safe default case, while adding further Slings and 
Stones to the mix makes your initial headache risk significantly greater 
than a coin toss in the permissive case.


cheers,
dalibor topic

[0] 
https://www.securecoding.cert.org/confluence/display/java/SEC05-J.+Do+not+use+reflection+to+increase+accessibility+of+classes,+methods,+or+fields


--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file

[Jim Laskey (Oracle)]

+1

> On Aug 2, 2016, at 8:39 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8159487
> 
> OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
> fix. Just adding "JAVA_VERSION" and a test change to check these
> properties exist in release file.
> 
> Thanks
> 
> -Sundar
> 

Re: Issue with an automatic module

[Alan Bateman]

On 02/08/2016 00:21, charbel yazbeck wrote:


hi,


most of the open sources jars  have classes with unnamed package, like 
nar-maven-plugin.


Any idea how can i solve this? Do i have to implement my own version 
of ModuleFinder?


Some examples:  D:\.m2\jdom\jdom\1.0\jdom-1.0.jar, 
D:\.m2\net\java\dev\javacc\javacc\5.0\javacc-5.0.jar, 
D:\.m2\hsqldb\hsqldb\1.8.0.7\hsqldb-1.8.0.7.jar



thank you


HelpMojo seems to be something to do with Maven Plugin Plugin. It 
doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0


$ java --module-path nar-maven-plugin-3.5.0.jar --list-modules 
nar.maven.plugin

nar.maven.plugin@3.5.0 (file:///d/nar-maven-plugin-3.5.0.jar)
  requires mandated java.base
  exports com.github.maven_nar
  exports com.github.maven_nar.cpptasks
  exports com.github.maven_nar.cpptasks.apple
  exports com.github.maven_nar.cpptasks.arm
  :

We have tried out hundreds of libraries as automatic modules (to test 
the derivation comes up with sensible module names etc.) and haven't 
seen too many issues. I did come across javacc, not the others you mention.


The summary is that if you have libraries with types in the unnamed 
package then they will need to remain on the class path. This means that 
nobody will be able to use `requires` to name them as a dependence in 
their module declaration.


-Alan.

Re: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file

[Alan Bateman]

On 02/08/2016 04:39, Sundararajan Athijegannathan wrote:


Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8159487

OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another
fix. Just adding "JAVA_VERSION" and a test change to check these
properties exist in release file.

This seems to put the value of the "java.version" property into the 
release file, I don't think you want that. Consider the cross targeting 
case where jlink is running on 9 but the modules for the target image 
are 9.1. So it needs to come from the java.base module for the target 
run-time image.


-Alan

Re: Exporting - the wrong default?

[Stephen Colebourne]

On 2 August 2016 at 12:49, dalibor topic  wrote:
> Let's now consider two different scenarios, in which Sling and Stone are
> either public, or not, and denote the variants with a P or N prefix - PSling
> is a public Sling, while NStone is a non-public Stone, for example.
>
> Let's also consider two defaults: permissive (i.e. all packages are
> exported) and fail safe (i.e. no packages are exported).
>
> Permissive:
> PSling + PStone can induce a headache, while the other three cases
> fortunately can not. So a mere 25% opportunity for a headache.
>
> Fail safe:
> none of the four cases induce a headache.

Er, now no-one can use the library.

The purpose of a library is to provide public types for applications
to use. That these have bugs and/or security issues is a fact of life
in software. Developers are not going to suddenly stop using external
OSS libraries.

> Let's now add reflection & setAccessible to the mix.
> ...
> Again, no headache occurs in the Failsafe case, because no packages are
> exported,

Er, now no-one can use the library because it can't operate without
reflection+setAccessible.

I again draw attention to the fact that many many OSS libraries use
reflection+setAccessible, and that the ecosystem relies on it pretty
much everywhere [1], at least in part because beans+properties has
never been addressed.

> Of course, you can get to the same cases starting with a Permissive default
> and then restricting exports of the packages in question.
>
> Yet, there is an interesting difference between the two scenarios:
>
> a) in the fail safe default case you start at no risk of headache inducing
> combinations of Slings and Stones, and then can increase your risk of a
> headache occurring to a certain level by adding exports, while in the
> permissive case you start at a coin toss level of headache risk and have to
> remove exports to decrease it to the same level, and
>
> b) regardless of how many Slings and Stones there are in the mix, you always
> start at no risk of headache inducing combinations of Stones and Slings in
> the fail safe default case, while adding further Slings and Stones to the
> mix makes your initial headache risk significantly greater than a coin toss
> in the permissive case.

Er, but this is such a straw man. There is no "initial headache risk".
The packages have to be exported to actually use the library, and are
today. The vast majority of libraries porting to Java 9 will have to
export all packages because nothing else will work. In virtually no
cases, is the end-user developer going to be changing the exported
packages of the libraries they depend on.

To get any benefit from the new modular scope, existing OSS projects
will require significant backward-incompatible reworking - to take
existing public classes and methods and move them to different
packages. This is major work, and far less likely than just exporting
everything (how many years has it taken to do this in the JDK?).

What I want from jigsaw is a *new* ability, not alteration of the
status quo. ie. to allow developers to *opt-in* to selectively hide
things at the module level *going forward*. Ideally I also want to
hide individual classes, methods and fields, because packages are far
too coarse grained for this.

IMO, we need to get existing OSS libraries migrated to modules ASAP to
maintain the ecosystem, which requires the migration to be really
simple. Get this wrong, and we'll all just carry on using the
classpath, and the last 5+ years of effort in the JDK will have little
value.

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008855.html

hg: jigsaw/jake/jdk: javax/smartcardio/TerminalFactorySpiTest.java failing

[alan . bateman]

Changeset: 8e042568422f
Author:alanb
Date:  2016-08-02 05:56 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e042568422f

javax/smartcardio/TerminalFactorySpiTest.java failing

! test/javax/smartcardio/TerminalFactorySpiTest.java

Re: Issue with an automatic module

[Andrew Dinn]

On 02/08/16 13:01, Alan Bateman wrote:
> HelpMojo seems to be something to do with Maven Plugin Plugin. It
> doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0

HelpMojo is indeed something to do with the Maven Plugin Plugin. The
latter will generate a class called HelpMojo on demand to provide
automatic help output to guide configuration and use of a Maven plugin
built using the Plugin Plugin.

However, a generated HelpMojo definition is not normally generated in
the empty package since it is usually generated in the same package as
the XXXMojo that implements the XXX plugin behaviour. Of course it can
also be implemented by hand. Looking at the 3.0.0 source jar file

  com/github/maven_nar/HelpMojo.java

contains a definition for class HelpMojo which appears to have been
hand-code and does not have a package declaration. The package
declaration appears to have been added in 3.2.0. In 3.3.0 the file
appears to have been removed -- I assume the class been auto-generated
by this stage.

So, the solution here is to use the fixed version of the plugin.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: Issue with an automatic module

[Peter Levart]

Hi,

Top-package (unnamed package) classes can not be referenced from classes 
in named packages anyway, so they usually represent just reflective 
entry points (such as Main class with main() method). If a jar is used 
as an automatic module, it would probably be safe to just ignore any 
classes that appear in the jar at the top-level. Maybe this way there 
would be less grief in trying to use such jars as automatic modules than 
by rejecting them.


Regards, Peter


On 08/02/2016 02:59 PM, Andrew Dinn wrote:

On 02/08/16 13:01, Alan Bateman wrote:

HelpMojo seems to be something to do with Maven Plugin Plugin. It
doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0

HelpMojo is indeed something to do with the Maven Plugin Plugin. The
latter will generate a class called HelpMojo on demand to provide
automatic help output to guide configuration and use of a Maven plugin
built using the Plugin Plugin.

However, a generated HelpMojo definition is not normally generated in
the empty package since it is usually generated in the same package as
the XXXMojo that implements the XXX plugin behaviour. Of course it can
also be implemented by hand. Looking at the 3.0.0 source jar file

   com/github/maven_nar/HelpMojo.java

contains a definition for class HelpMojo which appears to have been
hand-code and does not have a package declaration. The package
declaration appears to have been added in 3.2.0. In 3.3.0 the file
appears to have been removed -- I assume the class been auto-generated
by this stage.

So, the solution here is to use the fixed version of the plugin.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: RFR(L) 8136930: Simplify use of module-system options by custom launchers

[harold seigel]

Hi Lois,

Thanks for the review.  Please see comments in-line.

Harold


On 8/1/2016 8:40 PM, Lois Foltan wrote:


On 7/17/2016 7:05 PM, harold seigel wrote:

Hi,

Please review these Hotspot VM only changes to process the seven 
module-specific options that have been renamed to have gnu-like 
names.  JDK changes for this bug will be reviewed separately.


Descriptions of these options are here 
. For these six options, 
--module-path, --upgrade-module-path, --add-modules, --limit-modules, 
--add-reads, and --add-exports, the JVM just sets a system property.  
For the --patch-module option, the JVM sets a system property and 
then processes the option in the same way as when it was named -Xpatch.


Additionally, the JVM now checks properties specified on the command 
line.  If a property matches one of the properties used by one of the 
above options then the JVM ignores the property. This forces users to 
use the explicit option when wanting to do things like add a module 
or a package export.


The RFR contains two new tests.  Also, many existing tests were 
changed to use the new option names.


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

Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/


Hi Harold,

Overall looks good.  A couple of comments:

src/share/vm/prims/jvmtiEnv.cpp
- line #3428 - The if statement is incorrect.  There are internal 
properties, like jdk.boot.class.path.append, whose value if non-null 
should be returned.
This code will be reworked in the next version of these changes because 
of multiple issues.


src/share/vm/runtime/arguments.cpp
- Arguments::append_to_addmods_property was added before the VM 
starting to process --add-modules.  So with this fix, it seems like it 
could be simply changed to:


bool Arguments::append_to_addmods_property(const char* module_name) {
  PropertyList_unique_add(&_system_properties,
Arguments::get_property("jdk.module.addmods"),
   module_name,
AppendProperty, UnwriteableProperty, InternalProperty);
}

Please consider making this change since currently it contains a lot 
of duplicated code that is now unnecessary.
The one difference is that append_to_addmods_property() returns a status 
but PropertyList_unique_add() does not.  I'll look into this a bit further.


- line #3171, should the comment be "--add-modules=java.sql" instead 
of "--add-modules java.sql"?

yes.

The changes suggested by you, Coleen, and Dan will be in the next 
version of this webrev.


Thanks, Harold


Thanks,
Lois















The changes were tested with the JCK lang and VM tests, the JTreg 
hotspot tests, and the RBT hotspot nightlies.


Thanks, Harold

RE: Issue with an automatic module

[charbel yazbeck]

hi,


i would vote for that...


thank u


De : Peter Levart 
Envoyé : mardi 2 août 2016 13:19
À : Andrew Dinn; Alan Bateman; charbel yazbeck; jigsaw-dev@openjdk.java.net
Objet : Re: Issue with an automatic module

Hi,

Top-package (unnamed package) classes can not be referenced from classes
in named packages anyway, so they usually represent just reflective
entry points (such as Main class with main() method). If a jar is used
as an automatic module, it would probably be safe to just ignore any
classes that appear in the jar at the top-level. Maybe this way there
would be less grief in trying to use such jars as automatic modules than
by rejecting them.

Regards, Peter


On 08/02/2016 02:59 PM, Andrew Dinn wrote:
> On 02/08/16 13:01, Alan Bateman wrote:
>> HelpMojo seems to be something to do with Maven Plugin Plugin. It
>> doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0
> HelpMojo is indeed something to do with the Maven Plugin Plugin. The
> latter will generate a class called HelpMojo on demand to provide
> automatic help output to guide configuration and use of a Maven plugin
> built using the Plugin Plugin.
>
> However, a generated HelpMojo definition is not normally generated in
> the empty package since it is usually generated in the same package as
> the XXXMojo that implements the XXX plugin behaviour. Of course it can
> also be implemented by hand. Looking at the 3.0.0 source jar file
>
>com/github/maven_nar/HelpMojo.java
>
> contains a definition for class HelpMojo which appears to have been
> hand-code and does not have a package declaration. The package
> declaration appears to have been added in 3.2.0. In 3.3.0 the file
> appears to have been removed -- I assume the class been auto-generated
> by this stage.
>
> So, the solution here is to use the fixed version of the plugin.
>
> regards,
>
>
> Andrew Dinn
> ---
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Re: Issue with an automatic module

[Alan Bateman]

On 02/08/2016 06:19, Peter Levart wrote:


Hi,

Top-package (unnamed package) classes can not be referenced from 
classes in named packages anyway, so they usually represent just 
reflective entry points (such as Main class with main() method). If a 
jar is used as an automatic module, it would probably be safe to just 
ignore any classes that appear in the jar at the top-level. Maybe this 
way there would be less grief in trying to use such jars as automatic 
modules than by rejecting them.
The concern is that it gives the impression that a module can have a 
type in the unnamed package. If it is the main class then `java -m 
nar.maven.plugin/HelpMojo` will fail for example.  I concede of course 
that at some cases will be just mistakes where someone has included some 
classes in the top-level directory by accident.


(Note that the main class scenario has an another issue where it's 
possible for a JAR file to have a Main-Class attribute that named a 
class in the unnamed package as the main class. Known problem that will 
resolve itself once the builder API is overhauled).


-Alan

Re: Issue with an automatic module

[Remi Forax]

Seems to be a reasonable idea :)

Rem


On August 2, 2016 6:19:45 AM PDT, Peter Levart  wrote:
>Hi,
>
>Top-package (unnamed package) classes can not be referenced from
>classes 
>in named packages anyway, so they usually represent just reflective 
>entry points (such as Main class with main() method). If a jar is used 
>as an automatic module, it would probably be safe to just ignore any 
>classes that appear in the jar at the top-level. Maybe this way there 
>would be less grief in trying to use such jars as automatic modules
>than 
>by rejecting them.
>
>Regards, Peter
>
>
>On 08/02/2016 02:59 PM, Andrew Dinn wrote:
>> On 02/08/16 13:01, Alan Bateman wrote:
>>> HelpMojo seems to be something to do with Maven Plugin Plugin. It
>>> doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0
>> HelpMojo is indeed something to do with the Maven Plugin Plugin. The
>> latter will generate a class called HelpMojo on demand to provide
>> automatic help output to guide configuration and use of a Maven
>plugin
>> built using the Plugin Plugin.
>>
>> However, a generated HelpMojo definition is not normally generated in
>> the empty package since it is usually generated in the same package
>as
>> the XXXMojo that implements the XXX plugin behaviour. Of course it
>can
>> also be implemented by hand. Looking at the 3.0.0 source jar file
>>
>>com/github/maven_nar/HelpMojo.java
>>
>> contains a definition for class HelpMojo which appears to have been
>> hand-code and does not have a package declaration. The package
>> declaration appears to have been added in 3.2.0. In 3.3.0 the file
>> appears to have been removed -- I assume the class been
>auto-generated
>> by this stage.
>>
>> So, the solution here is to use the fixed version of the plugin.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> ---
>> Senior Principal Software Engineer
>> Red Hat UK Ltd
>> Registered in England and Wales under Company Registration No.
>03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

[Masayoshi Okutsu]

Hi Peter,

Thanks for bringing up the semantics issue of clearCache. You are right. 
There's some semantics change in clearCache(ClassLoader). Let me look 
into it.


The format field-related changes look good to me.

Thanks,
Masayoshi

On 8/1/2016 11:10 PM, Peter Levart wrote:

Hi Masayosh, Alan,

Thanks for looking at the change.

I suppose application containers are already accustomed to invoke 
ResourceBundle.clearCache(ClassLoader) when undeploying an application 
so that the corresponding ClassLoader can get GCed right away. But 
there's a change in the semantics of this method that Jigsaw 
introduced...


Before Jigsaw, this method was specified to:

 * Removes all resource bundles from the cache that have been loaded
 * using the given class loader.

After Jigsaw, this method is specified to:

 * Removes all resource bundles from the cache that have been loaded
 * by the caller's module using the given class loader.


Now suppose that the "caller's module" that loads the bundle is the 
application's module and the module that clears the cache is the 
container's module. The app's cache won't get cleared. I understand 
that the change in semantics was an attempt to "isolate" modules among 
themselves so that one module could not clear the cache of another 
module if they happen to map to the same class loader, but this also 
means that an application container can't easily clear the cache of 
the application it wishes to undeploy unless it uses the new 
ResourceBundle.clearCache(Module) method on each application's module 
before undeploying it.


I also wonder if the change of the semantics of this method is 
backwards compatible. Suppose that some container is using this method 
to clear the cache of the application loaded by say "classloaderA" 
before undeploying it. It calls 
ResourceBundle.clearCache(classloaderA). Now suppose the container 
code is loaded by some other class loader (say "classloaderC") which 
is usually the case in today's containers. Both container and 
application classes are part of the unnamed modules of their 
corresponding class loaders. With the change in the semantics of this 
method introduced by jigsaw, the container will not clear the cache of 
the application any more since the container module is not the same as 
the application module (they are distinct unnamed modules).


Anyway, I noticed an inconsistency in my webrev.04 immediately after 
posting it a week ago. I was off for a week then, so now that I'm 
back, here's the corrected webrev of my proposed change:


http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.05/ 



The only real change of logic compared to webrev.04 is that I moved 
the "format" field from the LoadSession (previous CacheKey) to 
ResourceBundle itself. This field is needed to hold the bundle's 
format for invoking the Control.needsReload() method. It is not 
semantically correct to use the value from the LoadSession as done in 
webrev.04. This has to be the value that the bundle was created with, 
so it belongs to the bundle itself. In original code it was taken from 
the cloned CacheKey that was attached to the bundle.


All other changes from webrev.04 are limited to ResourceBundle.java 
file and include some comments and nits that don't change the overall 
logic. All ResourceBundle tests still pass.


The diff from webrev.04 is the following:

*** ResourceBundle.webrev.04.java   2016-08-01 15:33:49.408565452 
+0200

--- ResourceBundle.java 2016-08-01 14:43:59.875401697 +0200
***
*** 40,55 

  package java.util;

- import jdk.internal.misc.JavaUtilResourceBundleAccess;
- import jdk.internal.misc.SharedSecrets;
- import jdk.internal.reflect.CallerSensitive;
- import jdk.internal.reflect.Reflection;
- import jdk.internal.util.concurrent.AbstractClassLoaderValue;
- import jdk.internal.util.concurrent.ClassLoaderValue;
- import sun.util.locale.BaseLocale;
- import sun.util.locale.LocaleObjectCache;
- import sun.util.locale.provider.ResourceBundleProviderSupport;
-
  import java.io.IOException;
  import java.io.InputStream;
  import java.lang.ref.ReferenceQueue;
--- 40,45 
***
*** 69,74 
--- 59,73 
  import java.util.spi.ResourceBundleControlProvider;
  import java.util.spi.ResourceBundleProvider;

+ import jdk.internal.misc.JavaUtilResourceBundleAccess;
+ import jdk.internal.misc.SharedSecrets;
+ import jdk.internal.reflect.CallerSensitive;
+ import jdk.internal.reflect.Reflection;
+ import jdk.internal.util.concurrent.AbstractClassLoaderValue;
+ import jdk.internal.util.concurrent.ClassLoaderValue;
+ import sun.util.locale.BaseLocale;
+ import sun.util.locale.LocaleObjectCache;
+ import sun.util.locale.provider.ResourceBundleProviderSupport;
  import static 
sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION;



***
*** 346,354 
   */
  public abstract class ResourceBundle {

- /** initial size of the bundle cache */
- pr

Re: Issue with an automatic module

[Jochen Theodorou]

On 02.08.2016 15:19, Peter Levart wrote:

Hi,

Top-package (unnamed package) classes can not be referenced from classes
in named packages anyway, so they usually represent just reflective
entry points (such as Main class with main() method).


In Java that is you mean. The JVM does not care about the package as 
long as the class can be found, nor does a class loader. It is a java 
compiler restriction, an intended one, but only for those wanting to be 
a java compiler.


bye Jochen

Re: Flag missing with "requires java.base"?

[Paul Benedict]

Correct me if wrong, but it seems there is no universal way to flag
something as compiler/tool generated. My take away from Alex's comments is
that ACC_SYNTHETIC is very much concerned with implicitness/explicitness...
but why? I still don't understand why it *must* be concerned anything like
that. I'd just like to state that definition sounds overloaded to me.

Furthermore, I think the definition of ACC_MANDATED is overloaded too. If
the JLS mandates a construct, it must be in the class file -- yet why does
the means matter? I prose the flag should mean no more than a mandate. It's
mandated so it must exist -- how it got there is irrelevant to me with
regard to this flag.

So doesn't anyone (Alex? Andrew?) find value in universally specifying
something was generated? That's what I thought ACC_SYNTHETIC could be used
for. If there is pushback on this idea, is there a universal way that I
have neglected to see?

Cheers,
Paul

On Mon, Aug 1, 2016 at 6:51 AM, Andrew Dinn  wrote:

>
>
> On 29/07/16 19:34, Alex Buckley wrote:
> > On 7/29/2016 12:48 AM, Andrew Dinn wrote:
> >> It might be worth pointing out at this stage in the discussion that
> >> ACC_SYNTHETIC was never given a hard and fast meaning whose logic
> >> transcends the vagaries of what javac decided to use it for -- citation,
> >> Neal Gafter in a thread I was involved in many years ago on the meaning
> >> of this term:
> >>
> >> Said definition:
> >>
> >>
> http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002257.html
> >>
> >>
> >> and explanation:
> >>
> >>
> http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002258.html
> >>
> >
> > On the contrary, Neal and I agree on the hard and fast meaning of
> > ACC_SYNTHETIC. The second link says:
>
>   ...
>
> Well, it's rather a moot point as to whether it is you and Neal or, as I
> phrased it, "the vagaries of what javac decided to use [SYNTHETIC] for"
> that constitutes the determining factor since obviously javac didn't
> really 'decide' anything except by way of proxy for those who informed
> it's construction as a piece of code.
>
> My point was not that ACC_SYNTHETIC did not have a determinate meaning
> (which is what you seem to take me as saying) rather that the decision
> as to what it means was made within the scope of what javac wanted to do
> with this property and that said meaning is not up for grabs for some
> external program to freight with its own semantic content. That is
> precisely (yes, I do mean precisely) what my exchange with Neal
> established.
>
> regards,
>
>
> Andrew Dinn
> ---
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>

Re: Exporting - the wrong default?

[Eric Johnson]

There's so much to tackle on this thread...

On 8/2/16 5:47 AM, Stephen Colebourne wrote:

IMO, we need to get existing OSS libraries migrated to modules ASAP to
maintain the ecosystem, which requires the migration to be really
simple. Get this wrong, and we'll all just carry on using the
classpath, and the last 5+ years of effort in the JDK will have little
value.
Indeed. Commercial vendors will have the same problem. And to the extent 
that we use open source libraries, we may need to fork said libraries. 
In working with OSGi, my company has had enormous issues with getting 
the metadata right for libraries - nothing obviously wrong with the 
code, but the metadata is a royal pain. It doesn't appear to transfer 
between platforms seamlessly. Potentially a huge cost with JDK 9 
modularization.


At the same time, I work on security issues. I want security by default. 
So I want both sides of this question to get the answer they want. Nasty 
conundrum we've found ourselves in.


One part of the split is simple - modules are a (presumably) useful 
compile time constraint. Giving Java the ability to hide public classes 
simply because the author didn't really want to expose them, but the 
language constraints didn't give them a choice, that seems like an 
improvement. This is not a security problem, just a language problem.


Bring module enforcement into the runtime, and it is now a security 
problem. All security problems are trade-offs. For one step, (as I've 
mentioned before) I'd really like someone to point at some security 
analysis document that goes through the threat model analysis (or its 
equivalent), so we can have a deeper discussion than "default to secure" 
as the only answer. Off the top of my head, I cannot think of any 
threats to something like Eclipse, which has already embraced the OSGi 
form of modularization. How will Jigsaw modularization enforcement at 
runtime can actually make Eclipse safer? I don't think it will. On the 
server side - much different question.


On the server side, without deep analysis, I suspect the default to 
enforce module boundaries makes sense. However, we also know, up front, 
that such a step will break things. To fix that breakage, will mean lots 
of changes to code, made by a lot of people, not all with lots of 
experience, across a lot of libraries. In other words, an opportunity to 
accidentally introduce new security bugs while trying to work within a 
new security framework. Again, wanting a threat model analysis, because 
helping those developers cross the chasm should be part of the threat 
equation that we're trying to solve.


So we really want a place where people can start using modules at 
compile time, and choose to opt into module boundary enforcement at 
runtime. I suspect it is probably an OK starting position if the JRE 
itself always benefits from boundary enforcement. But everything else - 
not sure that's a good idea, as it will blow-up the Java ecosystem.


Two possibilities - either a flag for the Java runtime to enforce module 
boundaries (default off?), or let individual modules choose whether they 
opt-in. Actually, both might be useful.


With the opt-in on a module basis, the open source project that needs to 
produce a module can produce one quickly, and opt-out of boundary 
enforcement. No source code changes besides module declarations, so 
minimal risk. That way, those developers can avoid all the hacking on 
code and changes that might be necessary by flipping to strict 
enforcement immediately. Over time, downstream users of those open 
source projects will be able to test those libraries by flipping a 
switch, and enforcing module boundaries for a given module, then testing 
to see if that caused problems. They can then go back to the open source 
project with definitive information, gleaned from actual use, about what 
is necessary to opt-in to full enforcement.


As for flags on the runtime, it might be good to have a flag which 
defaults to off. Other settings would be "warn", and "strict". SELinux, 
which seems closely analogous to this problem, has a similar model of 
"warn" vs. "enforce". So perhaps a good pattern to follow?


Eric