Re: Some suggested patches and improvements

[Alan Bateman]

On 18/05/2017 01:29, Gregg Wonderly wrote:




I understand that you might feel this is an excessive rant.  But, practically I 
know of Java applications around the world which all use things like Spring.
Spring seems to be making great progress, here's a recent write-up from 
Juergen Hoeller:


  https://spring.io/blog/2017/05/08/spring-framework-5-0-goes-rc1




  I know of many others which are using reflection and all kinds of 
.setAccessible() behaviors to manage “serialization” and other tasks for 
foreign classes.  As someone who doesn’t use Java-EE or any other “well used” 
platform, but rather uses many things I created myself well before those things 
existed, I suspect that I will find breakage in my larger apps simply because 
of setAccessible() which I use for introspection in tools (via Introspector 
etc.) and other things (like serialization).
Java serialization works as before. Custom serialization libraries is a 
challenge of course as it is fundamentally incompatible with 
encapsulation. This is why sun.reflect.ReflectionFactory has not been 
encapsulation (see JEP 260) and furthermore extended to allow custom 
serialization libraries work with a modular platform. That support went 
into a JDK 8 update too.




Maven seems to be something that the Jigsaw team had no real knowledge about.  
It just suddenly introduced a flurry of conversation on the list as something 
that was unimportant for modularization and jar reference issues.   Another 
pointer to the lack of foresight the Jigsaw team seemed to have into the 
realities of how Java is actually used around the world.
We have been working with the Maven maintainers for a long time (since 
2015). Here's the wiki page that Robert Scholte, Hervé Boutemy, and 
others have been using the track status:


  https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw

I also note a recent tweet from Robert, I can only guess that he's been 
asked a lot about this too.


  https://twitter.com/rfscholte/status/864560567767498752






JavaFX wasn’t much of a concern here on the list for some time.  There was no 
conversation about anything regarding compatibility.  It’s supposed to be a big 
part of the evolution of the desktop environment, and you’d think that Oracle 
employees would be working together, across the company.  It’s that kind of 
neglect of the “impact” on the platform which makes me feel like everything 
about JigSaw is a closed room idea
I think this is insulting to Kevin Rushforth and others in the OpenJFX 
project that we have been working with to ensure that JavaFX works great 
on JDK 9. The JDK downloads have included a fully modularized JavaFX for 
over year.


-Alan

Re: How to load resources from base module

[wzberger]

Here is a simple example which demonstrates the issue - still something 
missing?


// MODULE A
module com.a {
  exports com.a;
}

package com.a;

public class ClassA{
  public ClassA() {
//success
System.out.println(getClass().getResource("/com/b/resources/test.txt"));

//fail - null
System.out.println(ClassA.class.getResource("/com/b/resources/test.txt"));
  }
}

// MODULE B
module com.b {
  requires com.a;
  exports com.b;
  opens com.b.resources to com.a;
}

package com.b;

import com.a.ClassA;

public class ClassB extends ClassA{
  public ClassB(){
  }
}

// MODULE C
module com.c {
  requires com.a;
  requires com.b;
}

package com.c;

import com.b.ClassB;

public class ModuleTest{
  public static void main(String[] args){
new ClassB();
  }
}

-Wolfgang


On 17/05/2017 18:22, wzberger wrote:

The resources are mainly images and XML files, located in separate 
packages. By adding the opens clause it works fine for Class B 
(called from module a) - however, it does not work for Class A 
(returns null). I wonder if this is the intended behavior?
I'm not aware of any bugs in this area. Can you expand a bit more on 
"returns null" case. If the packages are open as you say then code in 
both `a` and `b` should be able to locate the resources in `b`.


-Alan

Re: How to load resources from base module

[Alan Bateman]

On 18/05/2017 08:16, wzberger wrote:


:

public class ClassA{
  public ClassA() {
//success
System.out.println(getClass().getResource("/com/b/resources/test.txt"));
The test creates an instance of ClassB (extends ClassA) and so 
getClass() returns ClassB here, not ClassA. So when constructing a 
ClassB then this is equivalent to ClassB.class.getResource(...).




//fail - null
System.out.println(ClassA.class.getResource("/com/b/resources/test.txt")); 

Right, as this resource is not in the com.a module. Change this to 
ClassB.class.getResource(...) and it should work.


-Alan

Re: How to load resources from base module

[Peter Levart]

Hi Wolfgang,

You are using instance method Class#getResource(String) which states in 
javadoc:


   /If this class is in a named Module then this method will attempt to
   find the resource *in the module*./

"this class" is the class represented by the Class object which is the 
receiver of the instance method invocation. In your below case, when you 
invoke getClass().getResource(), "this class" represents the runtime 
class of "this" object (ClassB in your case, since you create an 
instance of ClassB), but when you invoke ClassA.class.getResource(), 
"this class" represents ClassA.


So 1st attempt succeeds, bacause you are looking for a resource in the 
correct module (which contains it), while the 2nd attempt fails, because 
you are looking into the wrong module which doesn't contain the resource.


Class#getResource(String) instance method, in case of "this class" being 
in a named module, delegates to special (new in JDK 9) module's class 
loader method:


   /This is done by delegating to the module's class loader
   findResource(String,String) method, invoking it with the module name
   and the absolute name of the resource./

In addition to looking for resource "only" in a particular module, 
standard resource encapsulation rules apply:

//

   /Resources in named modules are subject to the rules for
   encapsulation specified in the Module getResourceAsStream method and
   so this method returns null when the resource is a non-".class"
   resource in a package that is not open to the caller's module./

So you are correctly opening the com.b.resources package to module com.a 
(which is the caller's module - the module containing the class with 
code invoking the Class::getResource(String) method). You just have to 
look up into the correct module too. Or if you don't want to bother with 
identifying the module where the resource lives but just with the 
"resource path" of the resource, then you can still use the 
ClassLoader#getResource(String) method, which will look up the resource 
in the class loader (with parents 1st delegation order) regardless of in 
which module the resource lives. Standard resource encapsulation rules 
still apply though.


Regards, Peter

On 05/18/2017 09:16 AM, wzberger wrote:
Here is a simple example which demonstrates the issue - still 
something missing?


// MODULE A
module com.a {
  exports com.a;
}

package com.a;

public class ClassA{
  public ClassA() {
//success
System.out.println(getClass().getResource("/com/b/resources/test.txt"));

//fail - null
System.out.println(ClassA.class.getResource("/com/b/resources/test.txt")); 


  }
}

// MODULE B
module com.b {
  requires com.a;
  exports com.b;
  opens com.b.resources to com.a;
}

package com.b;

import com.a.ClassA;

public class ClassB extends ClassA{
  public ClassB(){
  }
}

// MODULE C
module com.c {
  requires com.a;
  requires com.b;
}

package com.c;

import com.b.ClassB;

public class ModuleTest{
  public static void main(String[] args){
new ClassB();
  }
}

-Wolfgang


On 17/05/2017 18:22, wzberger wrote:

The resources are mainly images and XML files, located in separate 
packages. By adding the opens clause it works fine for Class B 
(called from module a) - however, it does not work for Class A 
(returns null). I wonder if this is the intended behavior?
I'm not aware of any bugs in this area. Can you expand a bit more on 
"returns null" case. If the packages are open as you say then code in 
both `a` and `b` should be able to locate the resources in `b`.


-Alan

Re: An alternative to "restricted keywords" + helping automatic modules

[Stephan Herrmann]

Remi,

I see your proposal as a minimal compromise, avoiding the worst
of difficulties, but I think we can do better.

Trade-off:
In all posts I could not find a real reason against escaping,
aside from aesthetics. I don't see this as sufficient motivation
for a less-then-perfect solution.


Clarity:
I'm still not completely following your explanations, partly because
of the jargon you are using. I'll leave it to Alex to decide if he
likes the idea that JLS would have to explain terms like dotted
production.

Compare this to just adding a few more rules to the grammar,
where no hand-waving is needed for an explanation.
No, I did not say that escaping is a pervasive change.
I never said that the grammar for ordinary compilation units
should be changed.
If you like we only need to extend one rule for the scope of
modular compilation units: Identifier. It can't get simpler.


Completeness:
I understand you as saying, module names cannot start with
"transitive". Mind you, that every modifier that will be added
to the grammar for modules in the future will cause conflicts for
names that are now legal, and you won't have a means to resolve this.

By contrast, we can use the escaping approach even to solve one
more problem that has been briefly touched on this list before:

Automatic modules suffer from the fact that some artifact names may
have Java keywords in their name, which means that these artifacts
simply cannot be used as automatic modules, right?
Why not apply escaping also here? *Any* dot-separated sequence
of words could be used as module name, as long as module references
have a means to escape any keywords in that sequence.


Suitability for implementation:
As said, your proposal resolves one problem, but still IDE
functionality suffers from restricted keywords, because scanning
and parsing need more context information than normal.
- Recovery after a syntax error will regress.
- Scanning arbitrary regions of code is not possible.
Remember:
In an IDE code with syntax errors is the norm, not an exception,
as the IDE provides functionality to work on incomplete code.


Stephan


On 18.05.2017 00:34, Remi Forax wrote:

I want to answer this before we start the meetings because i really think that 
restricted keyword as i propose solve the issues Stephan raised.


- Mail original -

De: "Stephan Herrmann" 
À: jigsaw-dev@openjdk.java.net
Envoyé: Mardi 16 Mai 2017 11:49:45
Objet: Re: An alternative to "restricted keywords"



Thanks, Remi, for taking this to the EG list.

Some collected responses:


Remi: "from the user point of view, '^' looks like a hack"

This is, of course, a subjective statement. I don't share this view
and in years of experience with Xtext-languages (where this concept
is used by default) I never heard any user complain about this.

More importantly, I hold that such aesthetic considerations are of
much lesser significance than the question, whether we can explain
- unambiguously explain - the concept in a few simple sentences.
Explaining must be possible at two levels: in a rigorous specification
and in simple words for users of the language.


I'm not against ^, or ` as it has already asked to escape an identifier, but as 
you said it's a pervasive change that applies on the whole grammar while i 
think that with restricted keyword (that really should be called local 
keywords) the changes only impact the grammar that specifies a module-info.java



Remi: "a keyword which is activated if you are at a position in the
 grammar where it can be recognized".

I don't think 'being at a position in the grammar' is a good way of
explaining. Parsing doesn't generally have one position in a grammar,
multiple productions can be active in the same parser state.
Also speaking of a "loop" for modifiers seems to complicate matters
more than necessary.

Under these considerations I still see '^' as the clearest of all
solutions. Clear as a specification, simple to explain to users.


Eclipse uses a LR parser, for a LR parser, position == dotted production as i 
have written earlier, so no problem because it corresponds to only one parser 
state.  Note that even if one do not use an LR or a LL parser, most hand 
written parser i've seen, javac is one of them, also refers to dotted 
production in the comments of the corresponding methods.





Peter spoke about module names vs. package names.

I think we agree, that module names cannot use "module words",
whereas package names should be expected to contain them.


yes, that the main issue, package names may contains unqualified name like 
'transitive, ''with' or 'to'.
but i think people will also want to use existing package or more exactly 
prefix of existing package as module name, so we should also support having 
restricted keyword name as part of a module name.

The grammar is:

  open? module module_name {
requires (transitive | static)* module_name;
exports package_name;
exports package_name to module_name1, module_name2

Re: Some suggested patches and improvements

[dalibor topic]

On 18.05.2017 02:29, Gregg Wonderly wrote:

I understand that you might feel this is an excessive rant.

[snip]

I will be looking at Swift and/or Go and just moving on.


All the best on your future technological adventures, in any case, 
whether they are with Java, or something else!


Please do keep in mind that this list is for "Technical discussion about 
Project Jigsaw", per 
http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev .


If you find that the technical focus poses a challenge for you, please 
try to finding a more suitable outlet for your writings.


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

Add-Reads and Add-Modules manifest attributes?

[Andrew Guibert]

I was happy to see that a resolution was reached for #AddExportsInManifest,
but why did this stop at Add-Exports and Add-Opens?  In order to cover all
use cases (for unnamed modules), we would need two more manifest
attributes:

# Equivalent to: --add-reads=java.base=ALL-UNNAMED
--add-reads=java.sql=ALL-UNNAMED
Add-Reads: java.base, java.sql

# Equivalent to --add-modules=java.se.ee
Add-Modules: java.se.ee

Based on my experience with JPMS so far, manifest attributes are a much
cleaner way of specifying the JPMS workaround options.  Mainly because on
older JDKs they are silently ignored so I don't have to add conditionally
apply the new Java 9 args in my launch commands.

- Andy

Re: Add-Reads and Add-Modules manifest attributes?

[Alan Bateman]

On 18/05/2017 14:40, Andrew Guibert wrote:



I was happy to see that a resolution was reached for #AddExportsInManifest,
but why did this stop at Add-Exports and Add-Opens?  In order to cover all
use cases (for unnamed modules), we would need two more manifest
attributes:

# Equivalent to: --add-reads=java.base=ALL-UNNAMED
--add-reads=java.sql=ALL-UNNAMED
Add-Reads: java.base, java.sql


Unnamed modules read all modules so you don't need this.

-Alan.

Re: Add-Reads and Add-Modules manifest attributes?

[Reto Merz]

Yes that would be great and I have also asked for that, see this thread:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012138.html

Regards
Reto


> -Ursprüngliche Nachricht-
> Von: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] Im Auftrag
> von Andrew Guibert
> Gesendet: Donnerstag, 18. Mai 2017 15:41
> An: jigsaw-dev
> Betreff: Add-Reads and Add-Modules manifest attributes?
> 
> 
> 
> I was happy to see that a resolution was reached for #AddExportsInManifest,
> but why did this stop at Add-Exports and Add-Opens?  In order to cover all
> use cases (for unnamed modules), we would need two more manifest
> attributes:
> 
> # Equivalent to: --add-reads=java.base=ALL-UNNAMED
> --add-reads=java.sql=ALL-UNNAMED
> Add-Reads: java.base, java.sql
> 
> # Equivalent to --add-modules=java.se.ee
> Add-Modules: java.se.ee
> 
> Based on my experience with JPMS so far, manifest attributes are a much
> cleaner way of specifying the JPMS workaround options.  Mainly because on
> older JDKs they are silently ignored so I don't have to add conditionally
> apply the new Java 9 args in my launch commands.
> 
> - Andy

Re: Add-Reads and Add-Modules manifest attributes?

[Andrew Guibert]

> From: Alan Bateman 
> To: Andrew Guibert , jigsaw-dev  d...@openjdk.java.net>
> Date: 05/18/2017 08:44 AM
> Subject: Re: Add-Reads and Add-Modules manifest attributes?
>
> On 18/05/2017 14:40, Andrew Guibert wrote:
>
> >
> > I was happy to see that a resolution was reached for
#AddExportsInManifest,
> > but why did this stop at Add-Exports and Add-Opens?  In order to cover
all
> > use cases (for unnamed modules), we would need two more manifest
> > attributes:
> >
> > # Equivalent to: --add-reads=java.base=ALL-UNNAMED
> > --add-reads=java.sql=ALL-UNNAMED
> > Add-Reads: java.base, java.sql
> >
> Unnamed modules read all modules so you don't need this.

Regarding Add-Reads:
You're reading it backwards I'm afraid =)  This example is saying
"java.base needs to read ALL-UNNAMED modules"
But regardless of what example was given, it is a valid use case right?

Regarding Add-Modules:
I see that Reto made a similar request last week for --add-modules as a
manifest attribute. You mentioned that there is no equivalent to
`--add-modules` in executable JARs along with some backing evidence that it
needs to be used in conjunction with `--module-path` and such.  However,
couldn't the JVM make a best effort to read and process an `Add-Modules`
attr?  I would argue that a vast majority of cases will be adding one of
basic values (i.e. java.se.ee or ALL-SYSTEM) which do not need to be used
in conjunction with `--module-path`.

Attaching to a JVM image that does not include java.instrument

[Rafael Winterhalter]

Hei,

I found that it is impossible to dynamically attach to a JVM that does not
include the java.instrument module when built with jlink. This is a result
of the instrumentation API and its infrastructure missing from the image.

rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java
-javaagent:/home/rafael/.m2/repository/sample-agent/sample-agent/1.0-SNAPSHOT/sample-agent-1.0-SNAPSHOT.jar
-m com.greetings/com.greetings.Main
Error occurred during initialization of VM

Could not find agent library instrument on the library path, with error:
libinstrument.so: cannot open shared object file: No such file or directory

It is of course neither possible to attach an agent to the JVM on the
command line. This problem resolves when explicitly including the
java.instrumentation module what does however render an unused warning in
most IDEs.

I understand that one target of the jlink tool is to reduce the JVM's size.
For the example greetings app, the size different is however minimal:

rafael@rafc:~/jdk9-test$ du -sh greetingsapp-instrument
45M greetingsapp-instrument
rafael@rafc:~/jdk9-test$ du -sh greetingsapp
44M greetingsapp

I would therefore suggest to always include the instrumentation module when
building with jlink.I would find it rather confusing to end users not being
able to attach an agent more or less all existing tooling demands this
ability, especially since users of Java applications are not always
responsible for building applications.

At a minimum, I would suggest a better error message and the rejection of
the javaagent parameter on the bundled command java executable. However, I
strongly suggest to not go for this solution as the instrumentation module
is unlikely to be included by any main application what would result in
such images never being compatible with agents, this breaking compatibility
of jlink built images to basically any Java tooling including that provided
by Oracle.

Best regards, Rafael

Re: Evidence of incompatibility (was Some suggested patches and improvements)

[Russell Gold]

Maven support and tool support in general for MR Jars is very poor at the 
moment - including the bundle plugin. I do have a working example 
 you could 
look at that includes OSGi support. The key here is that I delete the java9 
classes before computing the OSGi manifest, and only compile them before 
building the jar. 

Russ

> On May 17, 2017, at 11:28 PM, Ralph Goers  wrote:
> 
> I am afraid I have to echo these sentiments to some degree. In trying to get 
> Log4j to support Java 9 I first tried to use a multi-release jar. This failed 
> miserably when the OSGi build tool failed over finding java classes under 
> META-INF.  Then it proceeded to complain about the module-info.java files. 
> Why these are java syntax instead of json or something more sensible for 
> something that only contains declarations is a mystery to me. FWIW - the OSGi 
> people don’t seem interested in supporting these new features - 
> https://issues.apache.org/jira/browse/FELIX-5592 
> .
> 
> I have been able to work around some of these issues but it has made the 
> Log4j build very fragile and I haven’t really begun to see what happens when 
> log4j is actually modularized or runs in an application that is. 
> 
> Ralph
> 
>> On May 17, 2017, at 10:26 AM, Eric Johnson  wrote:
>> 
>> On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn  wrote:
>> 
>>> On 16/05/17 19:11, Gregg Wonderly wrote:
>>> 
>>> 
>>> 
 If we really cannot actually keep from breaking 90% of existing Java
 in the market place when this new JDK release goes out, how valuable
 is JigSaw really?
>>> 
>>> citation needed?
>>> 
>> 
>> I mostly ignore jigsaw, and check in every now and then.
>> 
>> I have a few co-workers that have poked at migrating their products to Java
>> 9. So far as I know, nobody has succeeded yet.
>> 
>> With significant regularity, I see issues pop up on this list that have odd
>> problems, or persist in being unresolved. One of my favorites at the moment
>> is automatic module names - a problem that Jigsaw caused for itself. Maybe
>> that one is resolved for now, but I'm pretty certain that questions will
>> come flooding back once Java 9 GAs.
>> 
>> As near as I can tell, applications that compile and run under Java 8 will
>> mostly *not* "just work" with Java 9 JRE. And that seems to be the lived
>> experience of my co-workers. If a project is lucky, the only changes
>> necessary will involve command line parameters. If a team is unlucky, they
>> will need to rebuild for Java 9. If a team is really unlucky, they will
>> need to partially or fully modularize. At which point some even more
>> juggling is required to continue to support Java 7 & 8, if that's required
>> by customers.
>> 
>> My overall concerns for Jigsaw:
>> https://medium.com/@one.eric.johnson/java-9-jigsaw-troubles-4fc406ef41e0
>> 
>> I'm not sure what citations you expect to see. There's probably nobody out
>> there who can afford to pre-flight an EA build of Java 9 against all their
>> products to see what the actual costs are going to be. Based on anecdotal
>> evidence from this mailing list, significant players in the Java ecosystem
>> - build tools, IDEs, critical libraries - have all had to fix unexpected
>> breakages with Java 9. Obviously, the ones that don't break don't typically
>> show up, so this is a self-selecting example, but an important one.
>> 
>> However, even something as simple as requiring changes to command line
>> parameters in order to launch a program compiled for Java 8 is a breaking
>> change. The Jigsaw team seems to be taking this as a mere complaint, rather
>> than as a genuine compatibility issue.
>> 
>> Here's a challenge back to the Jigsaw team. Can I still do java -jar ...
>> every existing Java application (without recompile!) that currently
>> launches that way? I'm even willing to cut some slack and ignore
>> applications that use com.sun APIs that have been "private" for years. Will
>> that still work? The Jigsaw community should be able to provide evidence
>> that's still possible, not that we should be required to provide evidence
>> that it isn't.
>> 
>> Eric.
>> 
>> 
>>> regards,
>>> 
>>> 
>>> Andrew Dinn
>>> ---
>>> 
>> 
> 

Re: Add-Reads and Add-Modules manifest attributes?

[Alan Bateman]

On 18/05/2017 15:14, Andrew Guibert wrote:


:

Regarding Add-Reads:
You're reading it backwards I'm afraid =) This example is saying 
"java.base needs to read ALL-UNNAMED modules"

But regardless of what example was given, it is a valid use case right?


I assumed you had transposed them in your mail :-)

In any case, it's not clear that you need this, at least not for the 
platform modules. Core reflection assumes readability so there shouldn't 
be any issues with code in either module reflecting into code on the 
class path. Maybe you are spinning bytecode? If so then you have a 
visibility issue as the types on the class path are not visible to boot 
or platform loaders. At a stretch then maybe are spinning bytecode that 
uses method handles, that's the only scenario that I can think of where 
you might need to add a read edge at runtime, in which case you can just 
call the reflective APIs. So maybe you could help by giving a specific 
example where you need this.


-Alan

Proposal: Allow illegal reflective access by default in JDK 9

[mark . reinhold]

Over time, as we've gotten closer and closer to the JDK 9 GA date, more
and more developers have begun paying attention the actual changes in
this release.  The strong encapsulation of JDK-internal APIs has, in
particular, triggered many worried expressions of concern that code that
works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
warning of this change was given in JDK 8.

To help the entire ecosystem migrate to the modular Java platform at a
more relaxed pace I hereby propose to allow illegal reflective access
from code on the class path by default in JDK 9, and to disallow it in
a future release.

In short, the existing "big kill switch" of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings.  The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release.  Nothing will
change at compile time.

In detail, the recently-introduced `--permit-illegal-access` option will
be replaced by a more-general option, `--illegal-access`.  This option
will take a single keyword parameter, as follows:

  `--illegal-access=permit`

This will be the default mode for JDK 9.  It opens every package in
every explicit module to code in all unnamed modules, i.e., code on
the class path, just as `--permit-illegal-access` does today.

The first illegal reflective-access operation causes a warning to be
issued, as with `--permit-illegal-access`, but no warnings are issued
after that point.  This single warning will describe how to enable
further warnings.

  `--illegal-access=warn`

This causes a warning message to be issued for each illegal
reflective-access operation.  This is equivalent to the current
`--permit-illegal-access` option.

  `--illegal-access=debug`

This causes both a warning message and a stack trace to be shown
for each illegal reflective-access operation.  This is equivalent
to combining today's `--permit-illegal-access` option with
`-Dsun.reflect.debugModuleAccessChecks`.

  `--illegal-access=deny`

This disables all illegal reflective-access operations except for
those enabled by other command-line options, such as `--add-opens`.
This will become the default mode in a future release.

Notes:

  - The proposed default mode enables the run-time system to issue a
warning message, possibly at some time long after startup, without
having been explicitly requested to do so.  This may be a surprise
in production environments, since it's extremely unusual for the
run-time system to issue any warning messages at all.  If the default
mode permits illegal reflective access, however, then it's essential
to make that known so that people aren't surprised when this is no
longer the default mode in a future release.

  - Warning messages in any mode can be avoided, as before, by the
judicious use of the `--add-exports` and `--add-opens` options.

  - This proposal will, if adopted, require adjustments to JEP 260,
"Encapsulate Most Internal APIs" [2].  APIs that are internal to the
JDK will still be strongly encapsulated from the standpoint of code
in modules, whether those modules are automatic or explicit, but they
will not appear to be encapsulated at run time from the standpoint of
code on the class path.

  - When `deny` becomes the default mode then I expect `permit` to remain
supported for at least one release, so that developers can continue
to migrate their code.  The `permit`, `warn`, and `debug` modes will,
over time, be removed, as will the `--illegal-access` option itself.
(For launch-script compatibility the unsupported modes will most
likely just be ignored, after issuing a warning to that effect.)

  - This change will not magically solve every JDK 9 adoption problem.
The concrete types of the built-in class loaders are still different,
`rt.jar` is still gone, the layout of a system image is still not the
same, and the version string still has a new format.

Comments?

- Mark


[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
[2] http://openjdk.java.net/jeps/260

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Andrew Haley]

On 18/05/17 15:48, mark.reinh...@oracle.com wrote:

> - The proposed default mode enables the run-time system to issue a
>   warning message, possibly at some time long after startup, without
>   having been explicitly requested to do so.  This may be a surprise
>   in production environments, since it's extremely unusual for the
>   run-time system to issue any warning messages at all.  If the default
>   mode permits illegal reflective access, however, then it's essential
>   to make that known so that people aren't surprised when this is no
>   longer the default mode in a future release.

Mmm.  There are many scripts which parse the output of java,and many
would break.  Might '--illegal-access=permit,quiet' be worth
considering?

Andrew.

Re: Attaching to a JVM image that does not include java.instrument

[Alan Bateman]

On 18/05/2017 15:20, Rafael Winterhalter wrote:


Hei,

I found that it is impossible to dynamically attach to a JVM that does not
include the java.instrument module when built with jlink. This is a result
of the instrumentation API and its infrastructure missing from the image.

rafael@rafc:~/jdk9-test/greetingsapp$ ./bin/java
-javaagent:/home/rafael/.m2/repository/sample-agent/sample-agent/1.0-SNAPSHOT/sample-agent-1.0-SNAPSHOT.jar
-m com.greetings/com.greetings.Main
Error occurred during initialization of VM

Could not find agent library instrument on the library path, with error:
libinstrument.so: cannot open shared object file: No such file or directory
Ugh, when -javaagent is specified then it is supposed to work as if 
`--add-modules java.instrument` is also on the command line. This 
ensures that the java.instrument module is resolved. The intention was 
also to get a useful error if the run-time image doesn't contain 
java.instrument.


Another example is `-Dcom.sun.management.*` which should work as if 
`--add-modules jdk.management.agent` is specified on the command line. 
Also `-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI` which is 
supposed to add `--add-modules jdk.internal.vm.ci`. I just checked both 
of these and the error is helpful as I expected.


As regards the attach mechanism then it will work when it is compiled in 
and enabled in the target VM. When I say "compiled in" then I mean the 
support is in libjvm. When using jlink when you can select the minimal 
VM to get a much smaller VM that doesn't have the serviceability 
features. That won't be typical of course so assume it is libjvm then 
you should be able to attach and troubleshooting tools such as `jcmd` 
will work. If you attempt to load a java agent then the target VM will 
attempt to resolve and load the java.instrument module and so will fail 
if the run-time image doesn't have the module.


You are right that java.instrument is small but it's always been a goal 
to be able to create run-time images that only contain java.base.


I didn't understand your comment about an "unused warnings" in the IDE. 
Do you mean `requires java.instrument` rather than specifying 
java.instrument to the `jlink --add-modules` option?


-Alan

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Cédric Champeau]

This looks like a very reasonable proposal, +1

2017-05-18 16:48 GMT+02:00 :

> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
> and more developers have begun paying attention the actual changes in
> this release.  The strong encapsulation of JDK-internal APIs has, in
> particular, triggered many worried expressions of concern that code that
> works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
> warning of this change was given in JDK 8.
>
> To help the entire ecosystem migrate to the modular Java platform at a
> more relaxed pace I hereby propose to allow illegal reflective access
> from code on the class path by default in JDK 9, and to disallow it in
> a future release.
>
> In short, the existing "big kill switch" of the `--permit-illegal-access`
> option [1] will become the default behavior of the JDK 9 run-time system,
> though without as many warnings.  The current behavior of JDK 9, in which
> illegal reflective-access operations from code on the class path are not
> permitted, will become the default in a future release.  Nothing will
> change at compile time.
>
> In detail, the recently-introduced `--permit-illegal-access` option will
> be replaced by a more-general option, `--illegal-access`.  This option
> will take a single keyword parameter, as follows:
>
>   `--illegal-access=permit`
>
> This will be the default mode for JDK 9.  It opens every package in
> every explicit module to code in all unnamed modules, i.e., code on
> the class path, just as `--permit-illegal-access` does today.
>
> The first illegal reflective-access operation causes a warning to be
> issued, as with `--permit-illegal-access`, but no warnings are issued
> after that point.  This single warning will describe how to enable
> further warnings.
>
>   `--illegal-access=warn`
>
> This causes a warning message to be issued for each illegal
> reflective-access operation.  This is equivalent to the current
> `--permit-illegal-access` option.
>
>   `--illegal-access=debug`
>
> This causes both a warning message and a stack trace to be shown
> for each illegal reflective-access operation.  This is equivalent
> to combining today's `--permit-illegal-access` option with
> `-Dsun.reflect.debugModuleAccessChecks`.
>
>   `--illegal-access=deny`
>
> This disables all illegal reflective-access operations except for
> those enabled by other command-line options, such as `--add-opens`.
> This will become the default mode in a future release.
>
> Notes:
>
>   - The proposed default mode enables the run-time system to issue a
> warning message, possibly at some time long after startup, without
> having been explicitly requested to do so.  This may be a surprise
> in production environments, since it's extremely unusual for the
> run-time system to issue any warning messages at all.  If the default
> mode permits illegal reflective access, however, then it's essential
> to make that known so that people aren't surprised when this is no
> longer the default mode in a future release.
>
>   - Warning messages in any mode can be avoided, as before, by the
> judicious use of the `--add-exports` and `--add-opens` options.
>
>   - This proposal will, if adopted, require adjustments to JEP 260,
> "Encapsulate Most Internal APIs" [2].  APIs that are internal to the
> JDK will still be strongly encapsulated from the standpoint of code
> in modules, whether those modules are automatic or explicit, but they
> will not appear to be encapsulated at run time from the standpoint of
> code on the class path.
>
>   - When `deny` becomes the default mode then I expect `permit` to remain
> supported for at least one release, so that developers can continue
> to migrate their code.  The `permit`, `warn`, and `debug` modes will,
> over time, be removed, as will the `--illegal-access` option itself.
> (For launch-script compatibility the unsupported modes will most
> likely just be ignored, after issuing a warning to that effect.)
>
>   - This change will not magically solve every JDK 9 adoption problem.
> The concrete types of the built-in class loaders are still different,
> `rt.jar` is still gone, the layout of a system image is still not the
> same, and the version string still has a new format.
>
> Comments?
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
> March/011763.html
> [2] http://openjdk.java.net/jeps/260
>

Re: Evidence of incompatibility (was Some suggested patches and improvements)

[Ralph Goers]

Yes, I had to do something similar. But this is fragile if you don’t always do 
a clean or explicitly include a clean step that runs to clean up those items 
even if you didn’t specify it.

Ralph

> On May 18, 2017, at 7:20 AM, Russell Gold  wrote:
> 
> Maven support and tool support in general for MR Jars is very poor at the 
> moment - including the bundle plugin. I do have a working example 
>  you could 
> look at that includes OSGi support. The key here is that I delete the java9 
> classes before computing the OSGi manifest, and only compile them before 
> building the jar. 
> 
> Russ
> 
>> On May 17, 2017, at 11:28 PM, Ralph Goers > > wrote:
>> 
>> I am afraid I have to echo these sentiments to some degree. In trying to get 
>> Log4j to support Java 9 I first tried to use a multi-release jar. This 
>> failed miserably when the OSGi build tool failed over finding java classes 
>> under META-INF.  Then it proceeded to complain about the module-info.java 
>> files. Why these are java syntax instead of json or something more sensible 
>> for something that only contains declarations is a mystery to me. FWIW - the 
>> OSGi people don’t seem interested in supporting these new features - 
>> https://issues.apache.org/jira/browse/FELIX-5592 
>>  
>> > >.
>> 
>> I have been able to work around some of these issues but it has made the 
>> Log4j build very fragile and I haven’t really begun to see what happens when 
>> log4j is actually modularized or runs in an application that is. 
>> 
>> Ralph
>> 
>>> On May 17, 2017, at 10:26 AM, Eric Johnson >> > wrote:
>>> 
>>> On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn >> > wrote:
>>> 
 On 16/05/17 19:11, Gregg Wonderly wrote:
 
 
 
> If we really cannot actually keep from breaking 90% of existing Java
> in the market place when this new JDK release goes out, how valuable
> is JigSaw really?
 
 citation needed?
 
>>> 
>>> I mostly ignore jigsaw, and check in every now and then.
>>> 
>>> I have a few co-workers that have poked at migrating their products to Java
>>> 9. So far as I know, nobody has succeeded yet.
>>> 
>>> With significant regularity, I see issues pop up on this list that have odd
>>> problems, or persist in being unresolved. One of my favorites at the moment
>>> is automatic module names - a problem that Jigsaw caused for itself. Maybe
>>> that one is resolved for now, but I'm pretty certain that questions will
>>> come flooding back once Java 9 GAs.
>>> 
>>> As near as I can tell, applications that compile and run under Java 8 will
>>> mostly *not* "just work" with Java 9 JRE. And that seems to be the lived
>>> experience of my co-workers. If a project is lucky, the only changes
>>> necessary will involve command line parameters. If a team is unlucky, they
>>> will need to rebuild for Java 9. If a team is really unlucky, they will
>>> need to partially or fully modularize. At which point some even more
>>> juggling is required to continue to support Java 7 & 8, if that's required
>>> by customers.
>>> 
>>> My overall concerns for Jigsaw:
>>> https://medium.com/@one.eric.johnson/java-9-jigsaw-troubles-4fc406ef41e0 
>>> 
>>> 
>>> I'm not sure what citations you expect to see. There's probably nobody out
>>> there who can afford to pre-flight an EA build of Java 9 against all their
>>> products to see what the actual costs are going to be. Based on anecdotal
>>> evidence from this mailing list, significant players in the Java ecosystem
>>> - build tools, IDEs, critical libraries - have all had to fix unexpected
>>> breakages with Java 9. Obviously, the ones that don't break don't typically
>>> show up, so this is a self-selecting example, but an important one.
>>> 
>>> However, even something as simple as requiring changes to command line
>>> parameters in order to launch a program compiled for Java 8 is a breaking
>>> change. The Jigsaw team seems to be taking this as a mere complaint, rather
>>> than as a genuine compatibility issue.
>>> 
>>> Here's a challenge back to the Jigsaw team. Can I still do java -jar ...
>>> every existing Java application (without recompile!) that currently
>>> launches that way? I'm even willing to cut some slack and ignore
>>> applications that use com.sun APIs that have been "private" for years. Will
>>> that still work? The Jigsaw community should be able to provide evidence
>>> that's still possible, not that we should be required to provide evidence
>>> that it isn't.
>>> 
>>> Eric.
>>> 
>>> 
 regards,
 
 
 Andrew Dinn
 ---
 
>>> 
>> 
> 

Re: Add-Reads and Add-Modules manifest attributes?

[Andrew Guibert]

> From: Alan Bateman 
> To: Andrew Guibert 
> Cc: jigsaw-dev 
> Date: 05/18/2017 09:27 AM
> Subject: Re: Add-Reads and Add-Modules manifest attributes?
>
> On 18/05/2017 15:14, Andrew Guibert wrote:
>
> Regarding Add-Reads:
> You're reading it backwards I'm afraid =) This example is saying
> "java.base needs to read ALL-UNNAMED modules"
> But regardless of what example was given, it is a valid use case right?
> I assumed you had transposed them in your mail :-)
>
> In any case, it's not clear that you need this, at least not for the
> platform modules. Core reflection assumes readability so there
> shouldn't be any issues with code in either module reflecting into
> code on the class path. Maybe you are spinning bytecode? If so then
> you have a visibility issue as the types on the class path are not
> visible to boot or platform loaders. At a stretch then maybe are
> spinning bytecode that uses method handles, that's the only scenario
> that I can think of where you might need to add a read edge at
> runtime, in which case you can just call the reflective APIs. So
> maybe you could help by giving a specific example where you need this.

A concrete use case for an `Add-Reads` manifest attr is beside the point.
Since we have the command line option, why can't we have the equivalent
functionality as a manifest attribute (especially since it seems trivial to
implement)? As long as use cases exist for `--add-reads`, use cases will
exist for the manifest attribute.  If no use cases exist for the
`--add-reads` command line option, can it be removed entirely?

Also, I don't want to forget about the discussion for `Add-Modules`.  I
understand that it may pose a significant technical challenge, but for code
launched via `java -jar` which depends on `java.se.ee` specific modules it
is a must for compatibility.

Re: Evidence of incompatibility (was Some suggested patches and improvements)

[Russell Gold]

No, the cleanup of the java 9 classes is bound to the compile step. Therefore, 
you don’t need to do a clean first. That would have been very aggravating.

> On May 18, 2017, at 11:38 AM, Ralph Goers  wrote:
> 
> Yes, I had to do something similar. But this is fragile if you don’t always 
> do a clean or explicitly include a clean step that runs to clean up those 
> items even if you didn’t specify it.
> 
> Ralph
> 
>> On May 18, 2017, at 7:20 AM, Russell Gold > > wrote:
>> 
>> Maven support and tool support in general for MR Jars is very poor at the 
>> moment - including the bundle plugin. I do have a working example 
>>  you 
>> could look at that includes OSGi support. The key here is that I delete the 
>> java9 classes before computing the OSGi manifest, and only compile them 
>> before building the jar. 
>> 
>> Russ
>> 
>>> On May 17, 2017, at 11:28 PM, Ralph Goers >> > wrote:
>>> 
>>> I am afraid I have to echo these sentiments to some degree. In trying to 
>>> get Log4j to support Java 9 I first tried to use a multi-release jar. This 
>>> failed miserably when the OSGi build tool failed over finding java classes 
>>> under META-INF.  Then it proceeded to complain about the module-info.java 
>>> files. Why these are java syntax instead of json or something more sensible 
>>> for something that only contains declarations is a mystery to me. FWIW - 
>>> the OSGi people don’t seem interested in supporting these new features - 
>>> https://issues.apache.org/jira/browse/FELIX-5592 
>>>  
>>> >> >.
>>> 
>>> I have been able to work around some of these issues but it has made the 
>>> Log4j build very fragile and I haven’t really begun to see what happens 
>>> when log4j is actually modularized or runs in an application that is. 
>>> 
>>> Ralph
>>> 
 On May 17, 2017, at 10:26 AM, Eric Johnson >>> > wrote:
 
 On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn >>> > wrote:
 
> On 16/05/17 19:11, Gregg Wonderly wrote:
> 
> 
> 
>> If we really cannot actually keep from breaking 90% of existing Java
>> in the market place when this new JDK release goes out, how valuable
>> is JigSaw really?
> 
> citation needed?
> 
 
 I mostly ignore jigsaw, and check in every now and then.
 
 I have a few co-workers that have poked at migrating their products to Java
 9. So far as I know, nobody has succeeded yet.
 
 With significant regularity, I see issues pop up on this list that have odd
 problems, or persist in being unresolved. One of my favorites at the moment
 is automatic module names - a problem that Jigsaw caused for itself. Maybe
 that one is resolved for now, but I'm pretty certain that questions will
 come flooding back once Java 9 GAs.
 
 As near as I can tell, applications that compile and run under Java 8 will
 mostly *not* "just work" with Java 9 JRE. And that seems to be the lived
 experience of my co-workers. If a project is lucky, the only changes
 necessary will involve command line parameters. If a team is unlucky, they
 will need to rebuild for Java 9. If a team is really unlucky, they will
 need to partially or fully modularize. At which point some even more
 juggling is required to continue to support Java 7 & 8, if that's required
 by customers.
 
 My overall concerns for Jigsaw:
 https://medium.com/@one.eric.johnson/java-9-jigsaw-troubles-4fc406ef41e0 
 
 
 I'm not sure what citations you expect to see. There's probably nobody out
 there who can afford to pre-flight an EA build of Java 9 against all their
 products to see what the actual costs are going to be. Based on anecdotal
 evidence from this mailing list, significant players in the Java ecosystem
 - build tools, IDEs, critical libraries - have all had to fix unexpected
 breakages with Java 9. Obviously, the ones that don't break don't typically
 show up, so this is a self-selecting example, but an important one.
 
 However, even something as simple as requiring changes to command line
 parameters in order to launch a program compiled for Java 8 is a breaking
 change. The Jigsaw team seems to be taking this as a mere complaint, rather
 than as a genuine compatibility issue.
 
 Here's a challenge back to the Jigsaw team. Can I still do java -jar ...
 every existing Java application (without recompile!) that currently
 launches that way? I'm even willing to cut some slack and ignore
 applications that use com.sun APIs that have been "privat

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Uwe Schindler]

Hi Mark,

To me this proposal is a Desaster. I'd not do this. Buggy software may use the 
big kill switch.

Sorry Red Hat guys: that's what you triggered with your "no". Bravo! I am 
impressed!

Sorry Gradle, the worst design in software about environment variables made the 
whole world again as unsafe as before. We will again see ongoing security 
updates in Java just fix fix holes that are opened by default. When I have read 
the mails yesterday, I thought: do you really want to build your software with 
such a broken tool and it's ecosystem? Can you not just tell the plug-in 
authors to fix their shit and fix your API to work correct?

Amazon S3 software dilettantes: Fix your EC2 security software to not undermine 
the Java security system! I can bring many more: Don't do that in security 
relevant tools or build systems many people rely on!

Today is the worst day in Java history.

Uwe

Am 18. Mai 2017 16:48:40 MESZ schrieb mark.reinh...@oracle.com:
>Over time, as we've gotten closer and closer to the JDK 9 GA date, more
>and more developers have begun paying attention the actual changes in
>this release.  The strong encapsulation of JDK-internal APIs has, in
>particular, triggered many worried expressions of concern that code
>that
>works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
>warning of this change was given in JDK 8.
>
>To help the entire ecosystem migrate to the modular Java platform at a
>more relaxed pace I hereby propose to allow illegal reflective access
>from code on the class path by default in JDK 9, and to disallow it in
>a future release.
>
>In short, the existing "big kill switch" of the
>`--permit-illegal-access`
>option [1] will become the default behavior of the JDK 9 run-time
>system,
>though without as many warnings.  The current behavior of JDK 9, in
>which
>illegal reflective-access operations from code on the class path are
>not
>permitted, will become the default in a future release.  Nothing will
>change at compile time.
>
>In detail, the recently-introduced `--permit-illegal-access` option
>will
>be replaced by a more-general option, `--illegal-access`.  This option
>will take a single keyword parameter, as follows:
>
>  `--illegal-access=permit`
>
>This will be the default mode for JDK 9.  It opens every package in
>every explicit module to code in all unnamed modules, i.e., code on
>the class path, just as `--permit-illegal-access` does today.
>
>   The first illegal reflective-access operation causes a warning to be
>  issued, as with `--permit-illegal-access`, but no warnings are issued
>after that point.  This single warning will describe how to enable
>further warnings.
>
>  `--illegal-access=warn`
>
>This causes a warning message to be issued for each illegal
>reflective-access operation.  This is equivalent to the current
>`--permit-illegal-access` option.
>
>  `--illegal-access=debug`
>
>This causes both a warning message and a stack trace to be shown
>for each illegal reflective-access operation.  This is equivalent
>to combining today's `--permit-illegal-access` option with
>`-Dsun.reflect.debugModuleAccessChecks`.
>
>  `--illegal-access=deny`
>
>This disables all illegal reflective-access operations except for
>those enabled by other command-line options, such as `--add-opens`.
>This will become the default mode in a future release.
>
>Notes:
>
>  - The proposed default mode enables the run-time system to issue a
>warning message, possibly at some time long after startup, without
>having been explicitly requested to do so.  This may be a surprise
>in production environments, since it's extremely unusual for the
>  run-time system to issue any warning messages at all.  If the default
>   mode permits illegal reflective access, however, then it's essential
>to make that known so that people aren't surprised when this is no
>longer the default mode in a future release.
>
>  - Warning messages in any mode can be avoided, as before, by the
>judicious use of the `--add-exports` and `--add-opens` options.
>
>  - This proposal will, if adopted, require adjustments to JEP 260,
>   "Encapsulate Most Internal APIs" [2].  APIs that are internal to the
>JDK will still be strongly encapsulated from the standpoint of code
>  in modules, whether those modules are automatic or explicit, but they
>  will not appear to be encapsulated at run time from the standpoint of
>code on the class path.
>
>- When `deny` becomes the default mode then I expect `permit` to remain
>supported for at least one release, so that developers can continue
>  to migrate their code.  The `permit`, `warn`, and `debug` modes will,
>   over time, be removed, as will the `--illegal-access` option itself.
>(For launch-script compatibility the unsupported modes will most
>likely just be ignored, after issuing a warning to that effect.)
>
>  - This change will not magically solve every J

Re: Add-Reads and Add-Modules manifest attributes?

[Alan Bateman]

On 18/05/2017 16:47, Andrew Guibert wrote:


:

A concrete use case for an `Add-Reads` manifest attr is beside the 
point.  Since we have the command line option, why can't we have the 
equivalent functionality as a manifest attribute (especially since it 
seems trivial to implement)? As long as use cases exist for 
`--add-reads`, use cases will exist for the manifest attribute.  If no 
use cases exist for the `--add-reads` command line option, can it be 
removed entirely?


`--add-reads` is important on the command line, esp. for testing when a 
module is patched at compile-time and run-time to includes tests in the 
same module as the module under test.


An equivalent Add-Reads in the manifest that updates an explicit module 
to read all unnamed modules is less clear and it would be useful to have 
an example or two. You are right that it would be trivial to add but 
that isn't a good reason to add it.





Also, I don't want to forget about the discussion for `Add-Modules`. 
 I understand that it may pose a significant technical challenge, but 
for code launched via `java -jar` which depends on `java.se.ee` 
specific modules it is a must for compatibility.



It has come up a few times.

-Alan

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Mario Torre]

2017-05-18 18:08 GMT+02:00 Uwe Schindler :
> Hi Mark,
>
> To me this proposal is a Desaster. I'd not do this. Buggy software may use 
> the big kill switch.
>
> Sorry Red Hat guys: that's what you triggered with your "no". Bravo! I am 
> impressed!
>
> Sorry Gradle, the worst design in software about environment variables made 
> the whole world again as unsafe as before. We will again see ongoing security 
> updates in Java just fix fix holes that are opened by default. When I have 
> read the mails yesterday, I thought: do you really want to build your 
> software with such a broken tool and it's ecosystem? Can you not just tell 
> the plug-in authors to fix their shit and fix your API to work correct?
>
> Amazon S3 software dilettantes: Fix your EC2 security software to not 
> undermine the Java security system! I can bring many more: Don't do that in 
> security relevant tools or build systems many people rely on!
>
> Today is the worst day in Java history.

Hello Uwe,

I appreciate your enthusiasm, but please let's try to keep this
discussion focused.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Michael Nascimento]

Sounds like a well thought compromise, Mark. Real world applications need
this and it's a very welcome move.

Regards,
Michael

On Thu, May 18, 2017 at 11:48 AM,  wrote:

> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
> and more developers have begun paying attention the actual changes in
> this release.  The strong encapsulation of JDK-internal APIs has, in
> particular, triggered many worried expressions of concern that code that
> works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
> warning of this change was given in JDK 8.
>
> To help the entire ecosystem migrate to the modular Java platform at a
> more relaxed pace I hereby propose to allow illegal reflective access
> from code on the class path by default in JDK 9, and to disallow it in
> a future release.
>
> In short, the existing "big kill switch" of the `--permit-illegal-access`
> option [1] will become the default behavior of the JDK 9 run-time system,
> though without as many warnings.  The current behavior of JDK 9, in which
> illegal reflective-access operations from code on the class path are not
> permitted, will become the default in a future release.  Nothing will
> change at compile time.
>
> In detail, the recently-introduced `--permit-illegal-access` option will
> be replaced by a more-general option, `--illegal-access`.  This option
> will take a single keyword parameter, as follows:
>
>   `--illegal-access=permit`
>
> This will be the default mode for JDK 9.  It opens every package in
> every explicit module to code in all unnamed modules, i.e., code on
> the class path, just as `--permit-illegal-access` does today.
>
> The first illegal reflective-access operation causes a warning to be
> issued, as with `--permit-illegal-access`, but no warnings are issued
> after that point.  This single warning will describe how to enable
> further warnings.
>
>   `--illegal-access=warn`
>
> This causes a warning message to be issued for each illegal
> reflective-access operation.  This is equivalent to the current
> `--permit-illegal-access` option.
>
>   `--illegal-access=debug`
>
> This causes both a warning message and a stack trace to be shown
> for each illegal reflective-access operation.  This is equivalent
> to combining today's `--permit-illegal-access` option with
> `-Dsun.reflect.debugModuleAccessChecks`.
>
>   `--illegal-access=deny`
>
> This disables all illegal reflective-access operations except for
> those enabled by other command-line options, such as `--add-opens`.
> This will become the default mode in a future release.
>
> Notes:
>
>   - The proposed default mode enables the run-time system to issue a
> warning message, possibly at some time long after startup, without
> having been explicitly requested to do so.  This may be a surprise
> in production environments, since it's extremely unusual for the
> run-time system to issue any warning messages at all.  If the default
> mode permits illegal reflective access, however, then it's essential
> to make that known so that people aren't surprised when this is no
> longer the default mode in a future release.
>
>   - Warning messages in any mode can be avoided, as before, by the
> judicious use of the `--add-exports` and `--add-opens` options.
>
>   - This proposal will, if adopted, require adjustments to JEP 260,
> "Encapsulate Most Internal APIs" [2].  APIs that are internal to the
> JDK will still be strongly encapsulated from the standpoint of code
> in modules, whether those modules are automatic or explicit, but they
> will not appear to be encapsulated at run time from the standpoint of
> code on the class path.
>
>   - When `deny` becomes the default mode then I expect `permit` to remain
> supported for at least one release, so that developers can continue
> to migrate their code.  The `permit`, `warn`, and `debug` modes will,
> over time, be removed, as will the `--illegal-access` option itself.
> (For launch-script compatibility the unsupported modes will most
> likely just be ignored, after issuing a warning to that effect.)
>
>   - This change will not magically solve every JDK 9 adoption problem.
> The concrete types of the built-in class loaders are still different,
> `rt.jar` is still gone, the layout of a system image is still not the
> same, and the version string still has a new format.
>
> Comments?
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
> March/011763.html
> [2] http://openjdk.java.net/jeps/260
>

-Xdiag:resolver

[Paul Deitel]

In earlier JDK 9-ea releases, there was the -Xdiag:resolver option to the java 
command so you could view the module resolution process at app startup. 

Has this been removed and replaced with --show-module-resolition option? The 
outputs don’t seem to be the same with this new option, so I am just confirming 
that I did not miss something.

Re: -Xdiag:resolver

[Alan Bateman]

On 18/05/2017 18:35, Paul Deitel wrote:


In earlier JDK 9-ea releases, there was the -Xdiag:resolver option to the java 
command so you could view the module resolution process at app startup.

Has this been removed and replaced with --show-module-resolition option? The 
outputs don’t seem to be the same with this new option, so I am just confirming 
that I did not miss something.

Yes, this was cleaned up recently and -Xdiag:resolver was temporarily an 
alias for `--show-module-resolution`. The reason for the clean-up is to 
make it easy to see why service provider modules are resolved, also to 
make the output easy to grep.


-Alan

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Markus Keller]

The command-line argument and the default mode sound good.

`--illegal-access=quiet` could be added for use by clients that cannot 
cope with additional warning messages.

The second ingredient for broad compatibility with Java 8 would be an 
automatic --add-modules=ALL-SYSTEM.
This could be implemented as an automatic compatibility mode in Java 9 
that would only be active as long as there's no --modulepath on the 
command line.

An alternative to automatic compatibility would be another sub-option for 
--illegal-access, so that affected end users only have one command-line 
argument for all accessibility concerns, e.g.:

  `--illegal-access=permit-all`

Equivalent to `--illegal-access=permit --add-modules=ALL-SYSTEM`


FYI: In the Eclipse launcher for the Oxygen (4.7) release, we've added 
forward-compatibility handling for --permit-illegal-access. Our deadline 
to revert/adjust that is May 30 ( https://bugs.eclipse.org/516911 ).

Regards,
Markus


"jigsaw-dev"  wrote on 2017-05-18 
16:48:40:

> From: mark.reinh...@oracle.com
> To: jigsaw-dev@openjdk.java.net
> Date: 2017-05-18 16:49
> Subject: Proposal: Allow illegal reflective access by default in JDK 9
> Sent by: "jigsaw-dev" 
> 
> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
> and more developers have begun paying attention the actual changes in
> this release.  The strong encapsulation of JDK-internal APIs has, in
> particular, triggered many worried expressions of concern that code that
> works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
> warning of this change was given in JDK 8.
> 
> To help the entire ecosystem migrate to the modular Java platform at a
> more relaxed pace I hereby propose to allow illegal reflective access
> from code on the class path by default in JDK 9, and to disallow it in
> a future release.
> 
> In short, the existing "big kill switch" of the 
`--permit-illegal-access`
> option [1] will become the default behavior of the JDK 9 run-time 
system,
> though without as many warnings.  The current behavior of JDK 9, in 
which
> illegal reflective-access operations from code on the class path are not
> permitted, will become the default in a future release.  Nothing will
> change at compile time.
> 
> In detail, the recently-introduced `--permit-illegal-access` option will
> be replaced by a more-general option, `--illegal-access`.  This option
> will take a single keyword parameter, as follows:
> 
>   `--illegal-access=permit`
> 
> This will be the default mode for JDK 9.  It opens every package in
> every explicit module to code in all unnamed modules, i.e., code on
> the class path, just as `--permit-illegal-access` does today.
> 
> The first illegal reflective-access operation causes a warning to be
> issued, as with `--permit-illegal-access`, but no warnings are 
issued
> after that point.  This single warning will describe how to enable
> further warnings.
> 
>   `--illegal-access=warn`
> 
> This causes a warning message to be issued for each illegal
> reflective-access operation.  This is equivalent to the current
> `--permit-illegal-access` option.
> 
>   `--illegal-access=debug`
> 
> This causes both a warning message and a stack trace to be shown
> for each illegal reflective-access operation.  This is equivalent
> to combining today's `--permit-illegal-access` option with
> `-Dsun.reflect.debugModuleAccessChecks`.
> 
>   `--illegal-access=deny`
> 
> This disables all illegal reflective-access operations except for
> those enabled by other command-line options, such as `--add-opens`.
> This will become the default mode in a future release.
> 
> Notes:
> 
>   - The proposed default mode enables the run-time system to issue a
> warning message, possibly at some time long after startup, without
> having been explicitly requested to do so.  This may be a surprise
> in production environments, since it's extremely unusual for the
> run-time system to issue any warning messages at all.  If the 
default
> mode permits illegal reflective access, however, then it's essential
> to make that known so that people aren't surprised when this is no
> longer the default mode in a future release.
> 
>   - Warning messages in any mode can be avoided, as before, by the
> judicious use of the `--add-exports` and `--add-opens` options.
> 
>   - This proposal will, if adopted, require adjustments to JEP 260,
> "Encapsulate Most Internal APIs" [2].  APIs that are internal to the
> JDK will still be strongly encapsulated from the standpoint of code
> in modules, whether those modules are automatic or explicit, but 
they
> will not appear to be encapsulated at run time from the standpoint 
of
> code on the class path.
> 
>   - When `deny` becomes the default mode then I expect `permit` to 
remain
> supported for at least one release, so that developers can continue
> 

hg: jigsaw/jake: 16 new changesets

[mandy . chung]

Changeset: 7583288d0802
Author:ihse
Date:  2017-05-10 09:02 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/7583288d0802

8178278: Move Standard Algorithm Names document to specs directory
Reviewed-by: erikj

! make/Javadoc.gmk

Changeset: 4635fa3adac6
Author:erikj
Date:  2017-05-10 18:27 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4635fa3adac6

8179867: JDK9 b167: demos exist in JDK bundles
Reviewed-by: ihse

! make/Bundles.gmk
! make/Main.gmk

Changeset: e50b2825a070
Author:tbell
Date:  2017-05-10 14:55 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/e50b2825a070

8180129: Bundles.gmk:181: *** unterminated call to function 'filter-out': 
missing ')'. Stop.
Reviewed-by: erikj

! make/Bundles.gmk

Changeset: d045961bbd5c
Author:ihse
Date:  2017-05-11 08:56 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/d045961bbd5c

8179105: Respect "include_in_docs" property from imported modules.
Reviewed-by: mchung, erikj

! make/common/Modules.gmk

Changeset: 4dfb05777cb6
Author:erikj
Date:  2017-05-11 18:41 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4dfb05777cb6

8180083: Adjust Jib and JDL configurations for 9 to support new generation Mach 
5
Reviewed-by: tbell, ihse

! common/conf/jib-profiles.js

Changeset: 503670294c7d
Author:lana
Date:  2017-05-11 18:10 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/503670294c7d

Merge


Changeset: f1ca22ebd70f
Author:iignatyev
Date:  2017-05-11 13:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f1ca22ebd70f

8180037: move jdk.test.lib.InMemoryJavaCompiler to a separate package
Reviewed-by: mseledtsov, vlivanov

! test/lib/RedefineClassHelper.java
- test/lib/jdk/test/lib/InMemoryJavaCompiler.java
+ test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java

Changeset: 52fd3ed2536f
Author:iignatyev
Date:  2017-05-11 13:58 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/52fd3ed2536f

8180004: jdk.test.lib.DynamicVMOption should be moved to jdk.test.lib.management
Reviewed-by: mseledtsov, vlivanov

- test/lib/jdk/test/lib/DynamicVMOption.java
+ test/lib/jdk/test/lib/management/DynamicVMOption.java

Changeset: 69879afbd98f
Author:ihse
Date:  2017-05-12 19:09 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/69879afbd98f

8175825: Stop including pubs repo
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/bin/hgforest.sh
! common/doc/building.html
! common/doc/testing.html
+ make/Docs.gmk
- make/Javadoc.gmk
! make/Main.gmk

Changeset: f6e365a5e489
Author:ihse
Date:  2017-05-12 19:11 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/f6e365a5e489

8180281: --with-jtreg is broken for many use cases
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4
! make/RunTests.gmk

Changeset: c569c88b7650
Author:mchung
Date:  2017-05-12 13:29 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/c569c88b7650

8180208: Provide a new docs bundle page
Reviewed-by: ihse, jjg

! make/Docs.gmk
! make/Main.gmk

Changeset: 2878d95ace72
Author:ihse
Date:  2017-05-15 16:34 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/2878d95ace72

8180342: Fixup path for jtreg
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: 9f46e4fbae64
Author:ihse
Date:  2017-05-16 14:13 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/9f46e4fbae64

8180420: Set PATH for dot and pandoc in JIB
Reviewed-by: erikj

! common/conf/jib-profiles.js

Changeset: 4d163ec59d98
Author:ihse
Date:  2017-05-16 14:14 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/4d163ec59d98

8180328: Bad links in footer of all javadoc-generated pages
Reviewed-by: erikj

! make/Docs.gmk

Changeset: 30196d168c55
Author:lana
Date:  2017-05-18 14:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/30196d168c55

Added tag jdk-9+170 for changeset 4d163ec59d98

! .hgtags

Changeset: 38d57d90acbe
Author:mchung
Date:  2017-05-18 14:17 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/rev/38d57d90acbe

Merge

! .hgtags
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4
! common/bin/hgforest.sh
! common/conf/jib-profiles.js
! make/Docs.gmk
! make/Main.gmk
! make/common/Modules.gmk

hg: jigsaw/jake/corba: 4 new changesets

[mandy . chung]

Changeset: a3e210a93f90
Author:jjg
Date:  2017-05-10 15:24 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a3e210a93f90

8180041: Fix HTML 5 issues in java.corba
Reviewed-by: alanb, lancea

! src/java.corba/share/classes/com/sun/corba/se/spi/monitoring/package.html
! src/java.corba/share/classes/org/omg/CORBA/Any.java
! src/java.corba/share/classes/org/omg/CORBA/ORB.java
! src/java.corba/share/classes/org/omg/CORBA/doc-files/compliance.html
! src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html
! src/java.corba/share/classes/org/omg/CORBA/package.html
! src/java.corba/share/classes/org/omg/CORBA/portable/package.html
! src/java.corba/share/classes/org/omg/CORBA_2_3/package.html
! src/java.corba/share/classes/org/omg/PortableInterceptor/IOP.idl
! src/java.corba/share/classes/org/omg/PortableInterceptor/Interceptors.idl
! src/java.corba/share/classes/org/omg/PortableInterceptor/package.html
! src/java.corba/share/classes/org/omg/PortableServer/package.html

Changeset: 8a4ab3b0ab9a
Author:lana
Date:  2017-05-11 18:10 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/8a4ab3b0ab9a

Merge


Changeset: c62e5964cfcf
Author:lana
Date:  2017-05-18 14:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/c62e5964cfcf

Added tag jdk-9+170 for changeset 8a4ab3b0ab9a

! .hgtags

Changeset: bb3fec2e546e
Author:mchung
Date:  2017-05-18 14:18 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/corba/rev/bb3fec2e546e

Merge

! .hgtags
! src/java.corba/share/classes/org/omg/CORBA/ORB.java

hg: jigsaw/jake/hotspot: 8 new changesets

[mandy . chung]

Changeset: 830c73c1bd96
Author:ihse
Date:  2017-05-11 09:00 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/830c73c1bd96

8174848: Remove gpl templates from hotspot/make
Reviewed-by: erikj

- make/templates/gpl-cp-header
- make/templates/gpl-header

Changeset: cab132bfdaec
Author:lana
Date:  2017-05-11 18:11 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cab132bfdaec

Merge

- make/templates/gpl-cp-header
- make/templates/gpl-header

Changeset: bffc9b76c590
Author:iignatyev
Date:  2017-05-11 14:03 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bffc9b76c590

8180037: move jdk.test.lib.InMemoryJavaCompiler to a separate package
Reviewed-by: mseledtsov, vlivanov

! test/gc/metaspace/TestMetaspacePerfCounters.java
! test/runtime/BadObjectClass/BootstrapRedefine.java
! test/runtime/RedefineTests/ModifyAnonymous.java
! test/runtime/Unsafe/DefineClass.java
! test/runtime/Unsafe/NestedUnsafe.java
! test/runtime/defineAnonClass/NestedUnsafe.java
! test/runtime/defineAnonClass/NestedUnsafe2.java
! test/runtime/getSysPackage/GetSysPkgTest.java
! test/runtime/modules/ModuleStress/ModuleStress.java
! test/runtime/modules/PatchModule/PatchModule2Dirs.java
! test/runtime/modules/PatchModule/PatchModuleCDS.java
! test/runtime/modules/PatchModule/PatchModuleClassList.java
! test/runtime/modules/PatchModule/PatchModuleJavaBase.java
! test/runtime/modules/PatchModule/PatchModuleTest.java
! test/runtime/modules/PatchModule/PatchModuleTestJar.java
! test/runtime/modules/PatchModule/PatchModuleTestJarDir.java
! test/runtime/modules/PatchModule/PatchModuleTraceCL.java
! test/runtime/modules/Visibility/PatchModuleVisibility.java
! test/runtime/modules/Visibility/XbootcpNoVisibility.java
! test/runtime/modules/Visibility/XbootcpVisibility.java

Changeset: 434139d1c85b
Author:iignatyev
Date:  2017-05-11 14:13 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/434139d1c85b

8180004: jdk.test.lib.DynamicVMOption should be moved to jdk.test.lib.management
Reviewed-by: mseledtsov, vlivanov

! test/gc/arguments/TestDynMaxHeapFreeRatio.java
! test/gc/arguments/TestDynMinHeapFreeRatio.java
! test/gc/parallel/TestDynShrinkHeap.java
! test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java
! 
test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java
! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java

Changeset: d6d7e5caf497
Author:tschatzl
Date:  2017-05-15 12:20 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d6d7e5caf497

8180048: Interned string and symbol table leak memory during parallel unlinking
Summary: Make appending found dead BasicHashtableEntrys to the free list atomic.
Reviewed-by: ehelin, shade, coleenp

! src/share/vm/classfile/stringTable.cpp
! src/share/vm/classfile/stringTable.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/hashtable.cpp
! src/share/vm/utilities/hashtable.hpp

Changeset: 38a240fd58a2
Author:aph
Date:  2017-05-11 13:11 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/38a240fd58a2

8179954: AArch64: C1 and C2 volatile accesses are not sequentially consistent
Reviewed-by: roland

! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp
! src/cpu/aarch64/vm/templateTable_aarch64.cpp

Changeset: b3ee8ab233ed
Author:lana
Date:  2017-05-18 14:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b3ee8ab233ed

Added tag jdk-9+170 for changeset 38a240fd58a2

! .hgtags

Changeset: 89f282fd426d
Author:mchung
Date:  2017-05-18 14:18 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89f282fd426d

Merge

! .hgtags
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/hashtable.hpp
! test/gc/metaspace/TestMetaspacePerfCounters.java
! test/gc/parallel/TestDynShrinkHeap.java
! test/runtime/BadObjectClass/BootstrapRedefine.java
! test/runtime/Unsafe/DefineClass.java
! test/runtime/getSysPackage/GetSysPkgTest.java
! test/runtime/modules/PatchModule/PatchModule2Dirs.java
! test/runtime/modules/PatchModule/PatchModuleCDS.java
! test/runtime/modules/PatchModule/PatchModuleJavaBase.java
! test/runtime/modules/PatchModule/PatchModuleTest.java
! test/runtime/modules/PatchModule/PatchModuleTestJar.java
! test/runtime/modules/PatchModule/PatchModuleTestJarDir.java
! test/runtime/modules/PatchModule/PatchModuleTraceCL.java
! test/runtime/modules/Visibility/PatchModuleVisibility.java
! test/runtime/modules/Visibility/XbootcpNoVisibility.java
! test/runtime/modules/Visibility/XbootcpVisibility.java

hg: jigsaw/jake/nashorn: 3 new changesets

[mandy . chung]

Changeset: 550bfc15779f
Author:sdama
Date:  2017-05-12 12:12 +0530
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/550bfc15779f

8179891: JavaDoc for for..in is incorrect
Summary: Fixed javadoc typo error
Reviewed-by: sundar, hannesw, jlaskey
Contributed-by: srinivas.d...@oracle.com

! 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/ForOfLoopTree.java

Changeset: fc416270a776
Author:lana
Date:  2017-05-18 14:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fc416270a776

Added tag jdk-9+170 for changeset 550bfc15779f

! .hgtags

Changeset: ff58cb77610f
Author:mchung
Date:  2017-05-18 14:18 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ff58cb77610f

Merge

! .hgtags

hg: jigsaw/jake/jaxp: 5 new changesets

[mandy . chung]

Changeset: e79b44a9d2bd
Author:joehw
Date:  2017-05-09 18:26 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e79b44a9d2bd

8179868: Java API Docs of javax.xml.transform.stax contains TODOs
Reviewed-by: lancea, bpb

! src/java.xml/share/classes/javax/xml/transform/stax/package.html

Changeset: 8861f89ae4c0
Author:lana
Date:  2017-05-11 18:11 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8861f89ae4c0

Merge


Changeset: 6e78f902f477
Author:joehw
Date:  2017-05-15 20:27 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6e78f902f477

8180060: Examine copyright header for some files
Reviewed-by: lancea

! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/FeatureState.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/ParserConfigurationSettings.java
! 
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/PropertyState.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/Status.java
! 
src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLSimpleType.java

Changeset: a5a3ac31f306
Author:lana
Date:  2017-05-18 14:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a5a3ac31f306

Added tag jdk-9+170 for changeset 6e78f902f477

! .hgtags

Changeset: 95172f5d5391
Author:mchung
Date:  2017-05-18 14:18 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/95172f5d5391

Merge

! .hgtags

hg: jigsaw/jake/jdk: 28 new changesets

[mandy . chung]

Changeset: 3e92641a337d
Author:psandoz
Date:  2017-05-09 15:04 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3e92641a337d

8177153: LambdaMetafactory has default constructor
Reviewed-by: psandoz
Contributed-by: ron.press...@oracle.com

! src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java

Changeset: 2c7616c8b7d8
Author:ihse
Date:  2017-05-10 09:02 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2c7616c8b7d8

8178278: Move Standard Algorithm Names document to specs directory
Reviewed-by: erikj, wetmore, mullan

! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java
! src/java.base/share/classes/java/security/AlgorithmParameters.java
! src/java.base/share/classes/java/security/DrbgParameters.java
! src/java.base/share/classes/java/security/KeyFactory.java
! src/java.base/share/classes/java/security/KeyPairGenerator.java
! src/java.base/share/classes/java/security/KeyStore.java
! src/java.base/share/classes/java/security/MessageDigest.java
! src/java.base/share/classes/java/security/Policy.java
! src/java.base/share/classes/java/security/SecureRandom.java
! src/java.base/share/classes/java/security/SecureRandomSpi.java
! src/java.base/share/classes/java/security/Security.java
! src/java.base/share/classes/java/security/Signature.java
! src/java.base/share/classes/java/security/cert/CertPath.java
! src/java.base/share/classes/java/security/cert/CertPathBuilder.java
! src/java.base/share/classes/java/security/cert/CertPathValidator.java
! src/java.base/share/classes/java/security/cert/CertStore.java
! src/java.base/share/classes/java/security/cert/Certificate.java
! src/java.base/share/classes/java/security/cert/CertificateFactory.java
! src/java.base/share/classes/java/security/cert/CertificateFactorySpi.java
! src/java.base/share/classes/java/security/cert/package-info.java
! src/java.base/share/classes/java/security/package-info.java
! src/java.base/share/classes/java/security/spec/EncodedKeySpec.java
! src/java.base/share/classes/java/security/spec/PKCS8EncodedKeySpec.java
! src/java.base/share/classes/java/security/spec/X509EncodedKeySpec.java
! src/java.base/share/classes/javax/crypto/Cipher.java
! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java
! src/java.base/share/classes/javax/crypto/KeyAgreement.java
! src/java.base/share/classes/javax/crypto/KeyGenerator.java
! src/java.base/share/classes/javax/crypto/Mac.java
! src/java.base/share/classes/javax/crypto/SecretKeyFactory.java
! src/java.base/share/classes/javax/crypto/package-info.java
! src/java.base/share/classes/javax/net/ssl/SSLContext.java
! src/java.base/share/classes/javax/net/ssl/SSLEngine.java
! src/java.base/share/classes/javax/net/ssl/SSLParameters.java
! src/java.base/share/classes/javax/net/ssl/SSLServerSocket.java
! src/java.base/share/classes/javax/net/ssl/SSLServerSocketFactory.java
! src/java.base/share/classes/javax/net/ssl/SSLSocket.java
! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java
! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java
! src/java.base/share/classes/javax/net/ssl/package-info.java
! src/java.base/share/classes/javax/security/auth/login/Configuration.java
! src/java.base/share/classes/javax/security/auth/login/package-info.java
! src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java

Changeset: 81ae2abfb49f
Author:prappo
Date:  2017-05-10 12:36 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/81ae2abfb49f

8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo
Reviewed-by: dfuchs

! src/java.base/share/classes/module-info.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/HttpRequestImpl.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/PlainTunnelingConnection.java
! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/WebSocket.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/hpack/Decoder.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/hpack/HeaderTable.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/BuilderImpl.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/CooperativeHandler.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/Frame.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/FrameConsumer.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/OpeningHandshake.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/OutgoingMessage.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/Receiver.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/websocket/StatusCodes.java
! 
src/jdk.incubator.httpclient/share/classes/jdk/incubator/http

hg: jigsaw/jake/langtools: 7 new changesets

[mandy . chung]

Changeset: ee84b7d44339
Author:jjg
Date:  2017-05-09 17:20 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ee84b7d44339

8179479: Add new styles to enable HTML 5 tables
Reviewed-by: bpatel

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css

Changeset: d5c5150ad2d9
Author:lana
Date:  2017-05-11 18:11 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d5c5150ad2d9

Merge


Changeset: 6ffca66728a7
Author:ksrini
Date:  2017-05-11 15:12 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6ffca66728a7

8179632: Fix the old doclet documentation
Reviewed-by: jjg

! src/jdk.javadoc/share/classes/com/sun/javadoc/package-info.java
! src/jdk.javadoc/share/classes/com/sun/tools/doclets/package-info.java
+ src/jdk.javadoc/share/classes/com/sun/tools/doclets/standard/package-info.java

Changeset: 77a2d6c1f321
Author:jlahoda
Date:  2017-05-12 06:42 +0200
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/77a2d6c1f321

8178152: Handling of incubating modules, the jdk.unsupported module and 
--add-exports with --release 
Summary: --release 9 should only allow documented modules; 
--add-exports/--add-reads/--patch-module should not be allowed on system 
modules when --release 9 is used.
Reviewed-by: jjg, erikj, ihse

! make/gendata/Gendata-jdk.compiler.gmk
+ make/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/AddExportsWithRelease.java
+ test/tools/javac/diags/examples/AddReadsWithRelease.java
+ 
test/tools/javac/diags/examples/PatchModuleWithRelease/PatchModuleWithRelease.java
+ 
test/tools/javac/diags/examples/PatchModuleWithRelease/patchmodule/java.base/java/lang/Test.java
! test/tools/javac/options/release/ReleaseOptionClashes.java
+ test/tools/javac/options/release/ReleaseOptionUnsupported.java

Changeset: 18355c879c69
Author:bpatel
Date:  2017-05-12 18:05 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/18355c879c69

8178043: Support grouping modules in unified javadoc
Reviewed-by: jjg, ksrini

! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Group.java
! test/jdk/javadoc/doclet/testModules/TestModules.java

Changeset: aae59039c1f5
Author:lana
Date:  2017-05-18 14:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/aae59039c1f5

Added tag jdk-9+170 for changeset 18355c879c69

! .hgtags

Changeset: a543a82a77b7
Author:mchung
Date:  2017-05-18 14:18 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a543a82a77b7

Merge

! .hgtags
! make/gendata/Gendata-jdk.compiler.gmk
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! 
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! 
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! test/jdk/javadoc/doclet/testModules/TestModules.java
! test/tools/javac/options/release/ReleaseOptionClashes.java

hg: jigsaw/jake/jaxws: 2 new changesets

[mandy . chung]

Changeset: 139e7c786ee4
Author:lana
Date:  2017-05-18 14:54 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/139e7c786ee4

Added tag jdk-9+170 for changeset e75d3abe579a

! .hgtags

Changeset: eb19676ed32f
Author:mchung
Date:  2017-05-18 14:18 -0700
URL:   http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/eb19676ed32f

Merge

! .hgtags

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Nicolai Parlog]

 Hi!

I like the flag per se and think a "quiet" argument would be helpful. I
also understand that there is pressure to improve the spec and that many
observers will see this change as progress[1].

But I think making the lenient option the default is a bad decision,
needlessly prolonging a proper clean-up of the ecosystem without any
practical benefit!

Java's stewards have been warning against using internal APIs for 20
years. Jigsaw announced to make them inaccessible for nigh two years
now. Java 8 will be supported until at least July 2018 and even after
that all that is needed to get around this specific Java 9 compatibility
problem is to add `--permit-illegal-access`.

All that is not enough, though? Even adding that single flag is too
hard? If spending an hour or two reading up on JPMS and then adding that
flag is too much to ask, then how can one expect the same people to
clean up their code?

With illegal access being permitted by default much fewer developers
will be aware of the problem and much less pressure will be put on
library and framework maintainers as well as on project management to
invest into paying back this particular form of technical debt. So we
get much less momentum to make the necessary changes in exchange for...
not having to add a flag? That's ridiculous, an Armutszeugnis[2] for the
Java community!

 so long ... Nicolai


[1](where in fact it only creates the appearance thereof)
[2]
https://krautblog-ulrich.blogspot.de/2012/07/word-of-month-armutszeugnis.html



On 18.05.2017 16:48, mark.reinh...@oracle.com wrote:
> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
> and more developers have begun paying attention the actual changes in
> this release.  The strong encapsulation of JDK-internal APIs has, in
> particular, triggered many worried expressions of concern that code that
> works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
> warning of this change was given in JDK 8.
> 
> To help the entire ecosystem migrate to the modular Java platform at a
> more relaxed pace I hereby propose to allow illegal reflective access
> from code on the class path by default in JDK 9, and to disallow it in
> a future release.
> 
> In short, the existing "big kill switch" of the `--permit-illegal-access`
> option [1] will become the default behavior of the JDK 9 run-time system,
> though without as many warnings.  The current behavior of JDK 9, in which
> illegal reflective-access operations from code on the class path are not
> permitted, will become the default in a future release.  Nothing will
> change at compile time.
> 
> In detail, the recently-introduced `--permit-illegal-access` option will
> be replaced by a more-general option, `--illegal-access`.  This option
> will take a single keyword parameter, as follows:
> 
>   `--illegal-access=permit`
> 
> This will be the default mode for JDK 9.  It opens every package in
> every explicit module to code in all unnamed modules, i.e., code on
> the class path, just as `--permit-illegal-access` does today.
> 
> The first illegal reflective-access operation causes a warning to be
> issued, as with `--permit-illegal-access`, but no warnings are issued
> after that point.  This single warning will describe how to enable
> further warnings.
> 
>   `--illegal-access=warn`
> 
> This causes a warning message to be issued for each illegal
> reflective-access operation.  This is equivalent to the current
> `--permit-illegal-access` option.
> 
>   `--illegal-access=debug`
> 
> This causes both a warning message and a stack trace to be shown
> for each illegal reflective-access operation.  This is equivalent
> to combining today's `--permit-illegal-access` option with
> `-Dsun.reflect.debugModuleAccessChecks`.
> 
>   `--illegal-access=deny`
> 
> This disables all illegal reflective-access operations except for
> those enabled by other command-line options, such as `--add-opens`.
> This will become the default mode in a future release.
> 
> Notes:
> 
>   - The proposed default mode enables the run-time system to issue a
> warning message, possibly at some time long after startup, without
> having been explicitly requested to do so.  This may be a surprise
> in production environments, since it's extremely unusual for the
> run-time system to issue any warning messages at all.  If the default
> mode permits illegal reflective access, however, then it's essential
> to make that known so that people aren't surprised when this is no
> longer the default mode in a future release.
> 
>   - Warning messages in any mode can be avoided, as before, by the
> judicious use of the `--add-exports` and `--add-opens` options.
> 
>   - This proposal will, if adopted, require adjustments to JEP 260,
> "Encapsulate Most Internal APIs" [2].  APIs that are internal to the
> JDK will still be strongly encapsulated from the stan

Re: An alternative to "restricted keywords" + helping automatic modules

[John Rose]

On May 18, 2017, at 1:59 AM, Stephan Herrmann  
wrote:
> 
> In all posts I could not find a real reason against escaping,
> aside from aesthetics. I don't see this as sufficient motivation
> for a less-then-perfect solution.

So, by disregarding esthetics...
> 
> Clarity:
> I'm still not completely following your explanations, partly because
> of the jargon you are using. I'll leave it to Alex to decide if he
> likes the idea that JLS would have to explain terms like dotted
> production.
> 
> Compare this to just adding a few more rules to the grammar,
> where no hand-waving is needed for an explanation.
> No, I did not say that escaping is a pervasive change.
> I never said that the grammar for ordinary compilation units
> should be changed.
> If you like we only need to extend one rule for the scope of
> modular compilation units: Identifier. It can't get simpler.
> 
> 
> Completeness:
> I understand you as saying, module names cannot start with
> "transitive". Mind you, that every modifier that will be added
> to the grammar for modules in the future will cause conflicts for
> names that are now legal, and you won't have a means to resolve this.
> 
> By contrast, we can use the escaping approach even to solve one
> more problem that has been briefly touched on this list before:
> 
> Automatic modules suffer from the fact that some artifact names may
> have Java keywords in their name, which means that these artifacts
> simply cannot be used as automatic modules, right?
> Why not apply escaping also here? *Any* dot-separated sequence
> of words could be used as module name, as long as module references
> have a means to escape any keywords in that sequence.
> 
> 
> Suitability for implementation:
> As said, your proposal resolves one problem, but still IDE
> functionality suffers from restricted keywords, because scanning
> and parsing need more context information than normal.

…we obtain the freedom for IDEs to disregard abnormal
amounts of context, saving uncounted machine cycles,

> - Recovery after a syntax error will regress.

…and we make life easier for all ten writers of error recovery
functions,

> - Scanning arbitrary regions of code is not possible.

…we unleash the power of an army of grad students to study
bidirectional parsing of module files,

> Remember:
> In an IDE code with syntax errors is the norm, not an exception,
> as the IDE provides functionality to work on incomplete code.

…and ease the burdens of the thousands who must spend their
time looking at syntax errors for their broken module files.

Nope, not for me.  Give me esthetics, please.  Really.

— John

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Christoph Engelbert]

Hey,

I also think the new styled parameter is great and I would appreciate a fully
“quiet” mode for our customers. I don’t mandate it to be the default but I think
to make it the default for (and only for) Java 9 sounds meaningful.

The reason is simple: It is not just us (a few people, a few vendors) to set
this parameter but it will be tons of customers or users, running the actual
production workloads, to add it to their command line. I guess most of us
know the burden of making a change to the command line at some bigger
companies, such as banks.

On the other side, as a dev I want it to print as much warnings as possible,
when I’m working on fixing the actual “misbehaving” code fragment.

In general I’m ok with making users add it to their command line but would
like to see something like quiet as the default for Java 9.

PS: the `—illegal-access=permit` as default works for me though :)

Thanks for the revised proposal, good stuff!

Cheers,
Chris


> On 19. May 2017, at 01:17, Nicolai Parlog  wrote:
> 
> Hi!
> 
> I like the flag per se and think a "quiet" argument would be helpful. I
> also understand that there is pressure to improve the spec and that many
> observers will see this change as progress[1].
> 
> But I think making the lenient option the default is a bad decision,
> needlessly prolonging a proper clean-up of the ecosystem without any
> practical benefit!
> 
> Java's stewards have been warning against using internal APIs for 20
> years. Jigsaw announced to make them inaccessible for nigh two years
> now. Java 8 will be supported until at least July 2018 and even after
> that all that is needed to get around this specific Java 9 compatibility
> problem is to add `--permit-illegal-access`.
> 
> All that is not enough, though? Even adding that single flag is too
> hard? If spending an hour or two reading up on JPMS and then adding that
> flag is too much to ask, then how can one expect the same people to
> clean up their code?
> 
> With illegal access being permitted by default much fewer developers
> will be aware of the problem and much less pressure will be put on
> library and framework maintainers as well as on project management to
> invest into paying back this particular form of technical debt. So we
> get much less momentum to make the necessary changes in exchange for...
> not having to add a flag? That's ridiculous, an Armutszeugnis[2] for the
> Java community!
> 
> so long ... Nicolai
> 
> 
> [1](where in fact it only creates the appearance thereof)
> [2]
> https://krautblog-ulrich.blogspot.de/2012/07/word-of-month-armutszeugnis.html
> 
> 
> 
> On 18.05.2017 16:48, mark.reinh...@oracle.com wrote:
>> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
>> and more developers have begun paying attention the actual changes in
>> this release.  The strong encapsulation of JDK-internal APIs has, in
>> particular, triggered many worried expressions of concern that code that
>> works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
>> warning of this change was given in JDK 8.
>> 
>> To help the entire ecosystem migrate to the modular Java platform at a
>> more relaxed pace I hereby propose to allow illegal reflective access
>> from code on the class path by default in JDK 9, and to disallow it in
>> a future release.
>> 
>> In short, the existing "big kill switch" of the `--permit-illegal-access`
>> option [1] will become the default behavior of the JDK 9 run-time system,
>> though without as many warnings.  The current behavior of JDK 9, in which
>> illegal reflective-access operations from code on the class path are not
>> permitted, will become the default in a future release.  Nothing will
>> change at compile time.
>> 
>> In detail, the recently-introduced `--permit-illegal-access` option will
>> be replaced by a more-general option, `--illegal-access`.  This option
>> will take a single keyword parameter, as follows:
>> 
>>  `--illegal-access=permit`
>> 
>>This will be the default mode for JDK 9.  It opens every package in
>>every explicit module to code in all unnamed modules, i.e., code on
>>the class path, just as `--permit-illegal-access` does today.
>> 
>>The first illegal reflective-access operation causes a warning to be
>>issued, as with `--permit-illegal-access`, but no warnings are issued
>>after that point.  This single warning will describe how to enable
>>further warnings.
>> 
>>  `--illegal-access=warn`
>> 
>>This causes a warning message to be issued for each illegal
>>reflective-access operation.  This is equivalent to the current
>>`--permit-illegal-access` option.
>> 
>>  `--illegal-access=debug`
>> 
>>This causes both a warning message and a stack trace to be shown
>>for each illegal reflective-access operation.  This is equivalent
>>to combining today's `--permit-illegal-access` option with
>>`-Dsun.reflect.debugModuleAccessChecks`.
>> 
>>  `--illegal-access=deny`
>> 
>>

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Weijun Wang]

I don't like this default value, but I also know some people wanting it.

Is it possible to provide the default value in a file inside the conf 
directory and also make it overwrite-able on the command line? Maybe 
RedHat Linux can make it "permit" out-of-box and other vendors can 
choose different values.


Thanks
Max

On 05/18/2017 10:48 PM, mark.reinh...@oracle.com wrote:

Over time, as we've gotten closer and closer to the JDK 9 GA date, more
and more developers have begun paying attention the actual changes in
this release.  The strong encapsulation of JDK-internal APIs has, in
particular, triggered many worried expressions of concern that code that
works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
warning of this change was given in JDK 8.

To help the entire ecosystem migrate to the modular Java platform at a
more relaxed pace I hereby propose to allow illegal reflective access
from code on the class path by default in JDK 9, and to disallow it in
a future release.

In short, the existing "big kill switch" of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings.  The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release.  Nothing will
change at compile time.

In detail, the recently-introduced `--permit-illegal-access` option will
be replaced by a more-general option, `--illegal-access`.  This option
will take a single keyword parameter, as follows:

  `--illegal-access=permit`

This will be the default mode for JDK 9.  It opens every package in
every explicit module to code in all unnamed modules, i.e., code on
the class path, just as `--permit-illegal-access` does today.

The first illegal reflective-access operation causes a warning to be
issued, as with `--permit-illegal-access`, but no warnings are issued
after that point.  This single warning will describe how to enable
further warnings.

  `--illegal-access=warn`

This causes a warning message to be issued for each illegal
reflective-access operation.  This is equivalent to the current
`--permit-illegal-access` option.

  `--illegal-access=debug`

This causes both a warning message and a stack trace to be shown
for each illegal reflective-access operation.  This is equivalent
to combining today's `--permit-illegal-access` option with
`-Dsun.reflect.debugModuleAccessChecks`.

  `--illegal-access=deny`

This disables all illegal reflective-access operations except for
those enabled by other command-line options, such as `--add-opens`.
This will become the default mode in a future release.

Notes:

  - The proposed default mode enables the run-time system to issue a
warning message, possibly at some time long after startup, without
having been explicitly requested to do so.  This may be a surprise
in production environments, since it's extremely unusual for the
run-time system to issue any warning messages at all.  If the default
mode permits illegal reflective access, however, then it's essential
to make that known so that people aren't surprised when this is no
longer the default mode in a future release.

  - Warning messages in any mode can be avoided, as before, by the
judicious use of the `--add-exports` and `--add-opens` options.

  - This proposal will, if adopted, require adjustments to JEP 260,
"Encapsulate Most Internal APIs" [2].  APIs that are internal to the
JDK will still be strongly encapsulated from the standpoint of code
in modules, whether those modules are automatic or explicit, but they
will not appear to be encapsulated at run time from the standpoint of
code on the class path.

  - When `deny` becomes the default mode then I expect `permit` to remain
supported for at least one release, so that developers can continue
to migrate their code.  The `permit`, `warn`, and `debug` modes will,
over time, be removed, as will the `--illegal-access` option itself.
(For launch-script compatibility the unsupported modes will most
likely just be ignored, after issuing a warning to that effect.)

  - This change will not magically solve every JDK 9 adoption problem.
The concrete types of the built-in class loaders are still different,
`rt.jar` is still gone, the layout of a system image is still not the
same, and the version string still has a new format.

Comments?

- Mark


[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
[2] http://openjdk.java.net/jeps/260

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Tagir Valeev]

Regarding proposed "quiet" option: there's existing
non-standard -XX:-PrintWarnings JVM option. I wonder whether it will work
to suppress the illegal access warning as well. If yes, then no additional
"quite" mode is necessary.

With best regards,
Tagir Valeev.

On Fri, May 19, 2017 at 11:42 AM, Christoph Engelbert 
wrote:

> Hey,
>
> I also think the new styled parameter is great and I would appreciate a
> fully
> “quiet” mode for our customers. I don’t mandate it to be the default but I
> think
> to make it the default for (and only for) Java 9 sounds meaningful.
>
> The reason is simple: It is not just us (a few people, a few vendors) to
> set
> this parameter but it will be tons of customers or users, running the
> actual
> production workloads, to add it to their command line. I guess most of us
> know the burden of making a change to the command line at some bigger
> companies, such as banks.
>
> On the other side, as a dev I want it to print as much warnings as
> possible,
> when I’m working on fixing the actual “misbehaving” code fragment.
>
> In general I’m ok with making users add it to their command line but would
> like to see something like quiet as the default for Java 9.
>
> PS: the `—illegal-access=permit` as default works for me though :)
>
> Thanks for the revised proposal, good stuff!
>
> Cheers,
> Chris
>
>
> > On 19. May 2017, at 01:17, Nicolai Parlog  wrote:
> >
> > Hi!
> >
> > I like the flag per se and think a "quiet" argument would be helpful. I
> > also understand that there is pressure to improve the spec and that many
> > observers will see this change as progress[1].
> >
> > But I think making the lenient option the default is a bad decision,
> > needlessly prolonging a proper clean-up of the ecosystem without any
> > practical benefit!
> >
> > Java's stewards have been warning against using internal APIs for 20
> > years. Jigsaw announced to make them inaccessible for nigh two years
> > now. Java 8 will be supported until at least July 2018 and even after
> > that all that is needed to get around this specific Java 9 compatibility
> > problem is to add `--permit-illegal-access`.
> >
> > All that is not enough, though? Even adding that single flag is too
> > hard? If spending an hour or two reading up on JPMS and then adding that
> > flag is too much to ask, then how can one expect the same people to
> > clean up their code?
> >
> > With illegal access being permitted by default much fewer developers
> > will be aware of the problem and much less pressure will be put on
> > library and framework maintainers as well as on project management to
> > invest into paying back this particular form of technical debt. So we
> > get much less momentum to make the necessary changes in exchange for...
> > not having to add a flag? That's ridiculous, an Armutszeugnis[2] for the
> > Java community!
> >
> > so long ... Nicolai
> >
> >
> > [1](where in fact it only creates the appearance thereof)
> > [2]
> > https://krautblog-ulrich.blogspot.de/2012/07/word-of-
> month-armutszeugnis.html
> >
> >
> >
> > On 18.05.2017 16:48, mark.reinh...@oracle.com wrote:
> >> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
> >> and more developers have begun paying attention the actual changes in
> >> this release.  The strong encapsulation of JDK-internal APIs has, in
> >> particular, triggered many worried expressions of concern that code that
> >> works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
> >> warning of this change was given in JDK 8.
> >>
> >> To help the entire ecosystem migrate to the modular Java platform at a
> >> more relaxed pace I hereby propose to allow illegal reflective access
> >> from code on the class path by default in JDK 9, and to disallow it in
> >> a future release.
> >>
> >> In short, the existing "big kill switch" of the
> `--permit-illegal-access`
> >> option [1] will become the default behavior of the JDK 9 run-time
> system,
> >> though without as many warnings.  The current behavior of JDK 9, in
> which
> >> illegal reflective-access operations from code on the class path are not
> >> permitted, will become the default in a future release.  Nothing will
> >> change at compile time.
> >>
> >> In detail, the recently-introduced `--permit-illegal-access` option will
> >> be replaced by a more-general option, `--illegal-access`.  This option
> >> will take a single keyword parameter, as follows:
> >>
> >>  `--illegal-access=permit`
> >>
> >>This will be the default mode for JDK 9.  It opens every package in
> >>every explicit module to code in all unnamed modules, i.e., code on
> >>the class path, just as `--permit-illegal-access` does today.
> >>
> >>The first illegal reflective-access operation causes a warning to be
> >>issued, as with `--permit-illegal-access`, but no warnings are issued
> >>after that point.  This single warning will describe how to enable
> >>further warnings.
> >>
> >>  `--illegal-ac

Re: Proposal: Allow illegal reflective access by default in JDK 9

[Christoph Engelbert]

There was a bug report which is closed, but that was, obviously, before the 
changed proposal. I think it would be subject to reconsider: 
https://bugs.openjdk.java.net/browse/JDK-8177916 


Chris


> On 19. May 2017, at 07:18, Tagir Valeev  wrote:
> 
> Regarding proposed "quiet" option: there's existing non-standard 
> -XX:-PrintWarnings JVM option. I wonder whether it will work to suppress the 
> illegal access warning as well. If yes, then no additional "quite" mode is 
> necessary.
> 
> With best regards,
> Tagir Valeev.
> 
> On Fri, May 19, 2017 at 11:42 AM, Christoph Engelbert  > wrote:
> Hey,
> 
> I also think the new styled parameter is great and I would appreciate a fully
> “quiet” mode for our customers. I don’t mandate it to be the default but I 
> think
> to make it the default for (and only for) Java 9 sounds meaningful.
> 
> The reason is simple: It is not just us (a few people, a few vendors) to set
> this parameter but it will be tons of customers or users, running the actual
> production workloads, to add it to their command line. I guess most of us
> know the burden of making a change to the command line at some bigger
> companies, such as banks.
> 
> On the other side, as a dev I want it to print as much warnings as possible,
> when I’m working on fixing the actual “misbehaving” code fragment.
> 
> In general I’m ok with making users add it to their command line but would
> like to see something like quiet as the default for Java 9.
> 
> PS: the `—illegal-access=permit` as default works for me though :)
> 
> Thanks for the revised proposal, good stuff!
> 
> Cheers,
> Chris
> 
> 
> > On 19. May 2017, at 01:17, Nicolai Parlog  > > wrote:
> >
> > Hi!
> >
> > I like the flag per se and think a "quiet" argument would be helpful. I
> > also understand that there is pressure to improve the spec and that many
> > observers will see this change as progress[1].
> >
> > But I think making the lenient option the default is a bad decision,
> > needlessly prolonging a proper clean-up of the ecosystem without any
> > practical benefit!
> >
> > Java's stewards have been warning against using internal APIs for 20
> > years. Jigsaw announced to make them inaccessible for nigh two years
> > now. Java 8 will be supported until at least July 2018 and even after
> > that all that is needed to get around this specific Java 9 compatibility
> > problem is to add `--permit-illegal-access`.
> >
> > All that is not enough, though? Even adding that single flag is too
> > hard? If spending an hour or two reading up on JPMS and then adding that
> > flag is too much to ask, then how can one expect the same people to
> > clean up their code?
> >
> > With illegal access being permitted by default much fewer developers
> > will be aware of the problem and much less pressure will be put on
> > library and framework maintainers as well as on project management to
> > invest into paying back this particular form of technical debt. So we
> > get much less momentum to make the necessary changes in exchange for...
> > not having to add a flag? That's ridiculous, an Armutszeugnis[2] for the
> > Java community!
> >
> > so long ... Nicolai
> >
> >
> > [1](where in fact it only creates the appearance thereof)
> > [2]
> > https://krautblog-ulrich.blogspot.de/2012/07/word-of-month-armutszeugnis.html
> >  
> > 
> >
> >
> >
> > On 18.05.2017 16:48, mark.reinh...@oracle.com 
> >  wrote:
> >> Over time, as we've gotten closer and closer to the JDK 9 GA date, more
> >> and more developers have begun paying attention the actual changes in
> >> this release.  The strong encapsulation of JDK-internal APIs has, in
> >> particular, triggered many worried expressions of concern that code that
> >> works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
> >> warning of this change was given in JDK 8.
> >>
> >> To help the entire ecosystem migrate to the modular Java platform at a
> >> more relaxed pace I hereby propose to allow illegal reflective access
> >> from code on the class path by default in JDK 9, and to disallow it in
> >> a future release.
> >>
> >> In short, the existing "big kill switch" of the `--permit-illegal-access`
> >> option [1] will become the default behavior of the JDK 9 run-time system,
> >> though without as many warnings.  The current behavior of JDK 9, in which
> >> illegal reflective-access operations from code on the class path are not
> >> permitted, will become the default in a future release.  Nothing will
> >> change at compile time.
> >>
> >> In detail, the recently-introduced `--permit-illegal-access` option will
> >> be replaced by a more-general option, `--illegal-access`.  This option
> >> will take a single keyword parameter, as follows:
> >>
> >>  `--illegal-access=permit`
> >>
> >> 

Re: An alternative to "restricted keywords" + helping automatic modules

[forax]

- Mail original -
> De: "Stephan Herrmann" 
> À: "Remi Forax" , jigsaw-dev@openjdk.java.net
> Envoyé: Jeudi 18 Mai 2017 10:59:09
> Objet: Re: An alternative to "restricted keywords" + helping automatic modules

> Remi,

Stephan,

>
> I see your proposal as a minimal compromise, avoiding the worst
> of difficulties, but I think we can do better.

better is usually a bitter enemy

>
> Trade-off:
> In all posts I could not find a real reason against escaping,
> aside from aesthetics. I don't see this as sufficient motivation
> for a less-then-perfect solution.
>
>
> Clarity:
> I'm still not completely following your explanations, partly because
> of the jargon you are using. I'll leave it to Alex to decide if he
> likes the idea that JLS would have to explain terms like dotted
> production.

Sorry for the jargon, dotted production is the same thing as a LR parser item 
[1],
the dot mark the parsing position inside a production.
i used 'dotted production' instead of parser item because usually it's clearer 
for my students.

>
> Compare this to just adding a few more rules to the grammar,
> where no hand-waving is needed for an explanation.
> No, I did not say that escaping is a pervasive change.
> I never said that the grammar for ordinary compilation units
> should be changed.
> If you like we only need to extend one rule for the scope of
> modular compilation units: Identifier. It can't get simpler.
>

I do not like ^ because
- as John said, esthetics is important
- it pushes the burden to the developers and not to the guys that implements 
the grammar.
  I'm Ok to makes your life and the life of people that implement the Java 
grammar (me included) less fun if for all other Java developers it just works, 
given the scale of the Java community, it seems to be a good compromise.
- ^ has to be a pervasive change, i mean it can be specified as a change only 
for module-info but from the developers point of view, it will be weird if you 
introduce ^ in module-info and not introduce it in the whole grammar
  so it's a global solution to local problem.  

so in my opinion, it's not that ^ does not work, as you said, it works in 
Xtend, it's that ^ is a escape hatch, it's better to use it when all other 
solutions do not work.

>
> Completeness:
> I understand you as saying, module names cannot start with
> "transitive". Mind you, that every modifier that will be added
> to the grammar for modules in the future will cause conflicts for
> names that are now legal, and you won't have a means to resolve this.
>
> By contrast, we can use the escaping approach even to solve one
> more problem that has been briefly touched on this list before:
>
> Automatic modules suffer from the fact that some artifact names may
> have Java keywords in their name, which means that these artifacts
> simply cannot be used as automatic modules, right?
> Why not apply escaping also here? *Any* dot-separated sequence
> of words could be used as module name, as long as module references
> have a means to escape any keywords in that sequence.
>
>
> Suitability for implementation:
> As said, your proposal resolves one problem, but still IDE
> functionality suffers from restricted keywords, because scanning
> and parsing need more context information than normal.
> - Recovery after a syntax error will regress.

Error recovery will not regress in all existing java file because restricted 
keyword only works when parsing the module-info.
And technically, there is no regression possible because the module-info was 
not existing before.
So error recovery after a syntax error in a module-info may be less fun to 
handle, as i said above, i'm ok with that.


> - Scanning arbitrary regions of code is not possible.

Scanning an arbitrary region is not easy in general, by example, you have if 
you are inside or outside a string, so you have to keep some information to be 
able to scan a region, why not trying to keep the parser state when necessary.
As John said, it seems to be a nice problem for grad students and at worst, you 
can use the existing code, it will display a restricted keyword in bold in the 
middle of a package name, that's all. 

> Remember:
> In an IDE code with syntax errors is the norm, not an exception,
> as the IDE provides functionality to work on incomplete code.
>
>
> Stephan

Rémi

[1] https://en.wikipedia.org/wiki/Canonical_LR_parser

>
>
> On 18.05.2017 00:34, Remi Forax wrote:
>> I want to answer this before we start the meetings because i really think 
>> that
>> restricted keyword as i propose solve the issues Stephan raised.
>>
>>
>> - Mail original -
>>> De: "Stephan Herrmann" 
>>> À: jigsaw-dev@openjdk.java.net
>>> Envoyé: Mardi 16 Mai 2017 11:49:45
>>> Objet: Re: An alternative to "restricted keywords"
>>
>>> Thanks, Remi, for taking this to the EG list.
>>>
>>> Some collected responses:
>>>
>>>
>>> Remi: "from the user point of view, '^' looks like a hack"
>>>
>>> This is, of course, a subjective state