Re: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

[Mandy Chung]

> On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline 
>  wrote:
> 
> Hi,
> 
> Can you please take a look on:
> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
> ?

Looks okay to me.

Mandy

Re: Accessing class files for named modules

[Alan Bateman]

On 02/05/2016 13:51, Rafael Winterhalter wrote:

:

I am aware that the idea of project Jigsaw is encapsulation but for
scenarios like the above, it is often required to break module bondaries.
In general, I think that project Jigsaw solved this problem elegantly but
changing this single method's contract broke all 26 projects that I looked
into before giving this feedback. Note that I only changed runtime as this
contract change also affects "old" code running on a Java 9 VM as the JVM
classes are now contained in runtime modules where

This is #ClassFilesAsResources [1], or more generally 
#ResourceEncapsulation [2], on the JSR issues list. In due course then 
I'm sure Mark will bring a proposal to the jpms-spec-experts list on 
these issues. We don't want to make any changes to the API or 
implementation in this area before then.


-Alan.

[1] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources
[2] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#ResourceEncapsulation

Accessing class files for named modules

[Rafael Winterhalter]

Hello everybody,

after I gave feedback a while ago I recently revisited how to port code
generation libraries to Java 9 and unfortunately, this still does not seem
possible with the current implementation. I am speaking based on experience
with Javassist and Byte Buddy which are both broadly used within the Java
ecosystem (several million downloads a year). I think I am competent to
speak on this topic as I wrote Byte Buddy and work as a consultant in the
field of code generation what gives me insight into many open- and
closed-source code bases that depend heavily on the API.

Code instrumentation libraries are often used for creating Java agents. One
challange with defining Java agents is the inavailability of "rich type
descriptions" similar to the Java reflection API which could be used to
gather information about the type that is supplied to a class file
transformer. To overcome this, both Javassist and Byte Buddy offer means of
investigating information about unloaded types and their referred types.
For this purpose, type information is extracted manually from class files
which are read from the class loader that is provided to the
ClassFileTransformer as an argument. A class file is located by calling
ClassLoader::getResource with an argument of "binaryTypeName.replace('.',
'/') + ".class". This includes classes that are defined by the VM (which
are now contained within runtime modules).

In Java 9, the latter method is overloaded by another method that accepts a
module name as a second parameter. The javadoc of the preexisting
getResource(String) now says:

"Resources in a named module are private to that module. This method does
not find resources in named modules defined to this class loader."

Of course, this includes resources that represent class file which are no
longer returned for named modules.

This is the API-change that I struggle with. To explain why, consider this
scenario: I want to create a ClassFileTransformer to instrument any class
that implements Interface A. Doing so, the ClassFileTransformer is notified
of some type Z being loaded. In order to find out if Z implements A, I am
looking at all the interface types that are stored in the class file that
the ClassFileTransformer provides. If any of these interfaces represents A,
I am done. Otherwise, as a next stept, I need to look into the interfaces
that Z does implement, Let's say, Z implements B. I now parse the class
files of B to see if this interface implements A. Before Java 9, I could
call "getResource" on the class loader that the ClassFileTransformer
provides. While I cannot generally assume that a class loader provides the
raw class file, this tactic works surprisingly well as most implementors of
custom class loaders are aware of this convention and stick to it.

With Java 9, this is no longer possible as I cannot determine what module -
if any - the above interface B is defined within. What I really require is
the previous behavior: I just want to get the class file independently of a
module similar to somebody wanting to load a class by name without knowing
what module this class will be defined within.

I am aware that the idea of project Jigsaw is encapsulation but for
scenarios like the above, it is often required to break module bondaries.
In general, I think that project Jigsaw solved this problem elegantly but
changing this single method's contract broke all 26 projects that I looked
into before giving this feedback. Note that I only changed runtime as this
contract change also affects "old" code running on a Java 9 VM as the JVM
classes are now contained in runtime modules where

assert
ClassLoader.getSystemClassLoader().getResourceAsAStram("java/lang/Object.class")
!= null

fails on Java 9 (but not on Java 8) whereas the following behavior is as
expected:

assert
Object.class.getModule().getResourceAsStream("java/lang/Object.class") !=
null;
assert
MyCustomClass.class.getModule().getResourceAsStream("java/lang/Object.class")
== null

This leads me to the suggestion I want to make. Did you consider to simply
retain the ClassLoader's behavior to not respect module boundaries? In the
end, a class loader exists on a level above modules. If I wanted to read a
module-scoped resource I would expect a user to read a resource via a
particular module or via a Class instance. It would be possible to
introduce an interface like:

interface ResourceAware {
  URL getResource(String name);
  InputStream getResourceAsStram(String name);
}

which could be implemented by the ClassLoader, Class and Module classes
where a class loader represents a Module-agnostic view whereas Class and
Module respect the new encapsulation rules. Doing so, the implementation of
Class could rather delegate to its Module rather then to its ClassLoader
such that

assert Object.class.getResourceAsStream("Object.class") != null;

holds again which currently fails on Java 9 but works on Java 8. I think
this outcome is intuitive and it would not 

Re: 8154956: Module system implementation refresh (4/2016)

[Chris Hegarty]

> On 29 Apr 2016, at 13:38, Alan Bateman  wrote:
> 
> The webrevs, all repos are here:
>  http://cr.openjdk.java.net/~alanb/8154956/1/

The updated changes look good to me.

-Chris.

Re: 8154956: Module system implementation refresh (4/2016)

[Peter Levart]

On 05/02/2016 08:24 AM, Alan Bateman wrote:


ModuleReader:
- the default method read(String name) should close the InputStream 
after reading from it, shouldn't it?
Yes it should, just hasn't been noticed because each of the 
implementations implement this method. I don't know if you mean to put 
the try on the same line but I'll make that a bit more readable before 
pushing the patch.


Good, it's more readable this way.

JmodModuleReader and JarModuleReader use this method, but this hasn't 
presented a problem since all those streams are closed when the JarFile 
is closed. But if there were any custom ModuleReaders (it's a public 
API) not overriding the default method, there would be a possible leak.


Regards, Peter

hg: jigsaw/jake/jdk: More clean-up

[alan . bateman]

Changeset: 294fcc1ae09f
Author:alanb
Date:  2016-05-02 08:34 +0100
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/294fcc1ae09f

More clean-up
Contributed-by: peter.lev...@gmail.com

! src/java.base/share/classes/java/lang/module/ModulePath.java
! src/java.base/share/classes/java/lang/module/ModuleReader.java
! src/java.base/share/classes/java/lang/module/ModuleReferences.java

Re: 8154956: Module system implementation refresh (4/2016)

[Alan Bateman]

On 02/05/2016 06:52, Andrej Golovnin wrote:

:

I don't know how often the method #deriveModuleDescriptor(JarFile)
is executed. But compiling regular expressions over and over doesn't really
helps from the performance standpoint of view:

  400 Matcher matcher = Pattern.compile("-(\\d+(\\.|$))").matcher(mn);

  415 mn =  mn.replaceAll("[^A-Za-z0-9]", ".")  // replace
non-alphanumeric
  416 .replaceAll("(\\.)(\\1)+", ".")   // collapse
repeating dots
  417 .replaceAll("^\\.", "")   // drop leading dots
  418 .replaceAll("\\.$", "");  // drop trailing dots

Maybe the regular expressions in the above lines should be precompiled
in static final fields (Pattern objects are immutable and thread safe)
to improve
the performance of the #deriveModuleDescriptor(JarFile)-method.

This is the pattern matching to derive the module name for an automatic 
module. You are right that this is inefficient, we should only need to 
compile the pattern once. Probably not a static field though as it also 
has to be lazy. I think we have enough in this update so if you don't 
mind, I would prefer to leave this until another refresh.


-Alan

Re: Speeding up jmod

[Alan Bateman]

On 01/05/2016 17:02, Chris Hegarty wrote:

On 1 May 2016, at 14:50, Andrej Golovnin  wrote:

Hi Alan,

If you would like to improve the performance a little bit more,
you can make additional changes (see the patch) to JmodTask
and maybe Claes can rerun his tests to see if it helps.

These look good too, even as general clean ups, but it would
be good to get some numbers on them.

Andrej - aside from the micro benchmarks, the real test is `make jmods` 
where the tool runs N times (N = number of modules) to create the 
packaged modules. Short lived tools have always been the JDK's Achilles 
heel. It may be that we will eventually need a "jmod server", like the 
sjavac server in the build today. Alternative it could be wrapped in 
another tool that capable of creating several packaged modules. There is 
a balance here as we also don't want to over complicated things.


-Alan