Re: Code review for jigsaw/jake -> jdk9/dev sync up

Thanks for going through the changes, a few comment/replies below. On 28/11/2016 22:22, Paul Sandoz wrote: : What happens if you pass a primitive array? I think you need to specify what happens if an array class is passed and how the target class is obtained, and an IAE if the "element

Migrating to uses from an existing module system

I have a usecase where I am attempting to map an existing module system's class loaders to JPMS modules by using the Layer API. In this case the existing module system is OSGi. I have run into an issue when an existing OSGi bundle contains code that uses the ServiceLoader. For the sake of

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Thanks Lois. I removed the blank line. Mandy > On Nov 28, 2016, at 6:32 AM, Lois Foltan wrote: > > Hi Alan, > > I have reviewed the hotspot changes and they look good. Minor nit, > src/share/vm/classfile/javaClasses.cpp only differs by the addition of a > blank

hg: jigsaw/jake/hotspot: Remove blank line - review comment from Lois

Changeset: 85448216fe28 Author:mchung Date: 2016-11-29 13:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/85448216fe28 Remove blank line - review comment from Lois ! src/share/vm/classfile/javaClasses.cpp

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Karen, Sorry for delay. I was on vacation last week. I plan to review the changes tomorrow. -Dmitry On 2016-11-28 17:47, Karen Kinnear wrote: > Alan, > > I reviewed all the hotspot runtime changes > - except the tests (Christian will review those) > - and jvmti - which Dmitry Samersoff will

testing for a class having been loaded

Prior to JDK 9, it was possible (using setAccessible) to ask a ClassLoader whether a class with a given name had been loaded without actually forcing it to be loaded. This hack will not work in JDK9, so I am wondering if there is a way to do this? If not, can someone explain why it would be a

RE: Code review for jigsaw/jake -> jdk9/dev sync up

Hi Alan, I've reviewed the test changes for Hotspot and they look good. Thanks, Christian -Original Message- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-boun...@openjdk.java.net] On Behalf Of Alan Bateman Sent: Thursday, November 24, 2016 10:25 AM To: jigsaw-dev

Services and Bindings - expected usage scenarios

Another best practices question. I am aware that the ServiceLoader API is not new to Java. What's new in Java 9 is that is has been put forward to the front of the stage and it is now very easy for a service provider to register a service. The thing is that up until now, the ServiceLoader was

hg: jigsaw/jake/hotspot: JVMTI AddModuleExports/AddModuleOpens should not intern strings

Changeset: 6f8d3c3028bb Author:sspitsyn Date: 2016-11-29 09:18 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6f8d3c3028bb JVMTI AddModuleExports/AddModuleOpens should not intern strings ! src/share/vm/prims/jvmtiEnv.cpp

RE: Services and Bindings - expected usage scenarios

Remi, good point on the Class.forName. I guess that the main difference is that Class.forName requires the concrete type - it is up to the consumer to specify (and know) the serviceprovider, whereas the SL resolves a request for an interface and the consumer remains oblivious of the identity

hg: jigsaw/jake/langtools: disentangle exports and opens in javac

Changeset: 55e9018d9f89 Author:jjg Date: 2016-11-29 17:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/55e9018d9f89 disentangle exports and opens in javac ! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java !

RE: Services and Bindings - expected usage scenarios

What about the intent behind how are developers supposed to use this tool? For example, when Optional was introduced in Java 8, it was specified that it is intended to be used as a methods return type. And people should not use it as class member or method argument, even though the compiler

Re: Services and Bindings - expected usage scenarios

On 29/11/2016 11:35, Pisarev, Vitaliy wrote: Another best practices question. I am aware that the ServiceLoader API is not new to Java. What's new in Java 9 is that is has been put forward to the front of the stage and it is now very easy for a service provider to register a service. The

Re: Services and Bindings - expected usage scenarios

On 29/11/2016 13:13, Pisarev, Vitaliy wrote: What about the intent behind how are developers supposed to use this tool? For example, when Optional was introduced in Java 8, it was specified that it is intended to be used as a methods return type. And people should not use it as class member

Re: Services and Bindings - expected usage scenarios

I am not of the expert group, but I would like to give a partial answer. Let us think of a kind of plugin architecture. There is a public interface from your framework and there are other modules that are going to provide plugins by implementing that interface. Now assume the framework will

RE: Services and Bindings - expected usage scenarios

Yes I have. In fact I've watched the entire series and am following this very closely for a time now. The lecture clearly explains the mechanics and how this works and what we *can* do with it, but less about what we *should* (and shouldn’t) do with it. I am a System Architect in a very large

Re: Services and Bindings - expected usage scenarios

Hi Vitaliy, > Is it the intent of project Jigsaw that the service loader becomes a central > and > ubiquitous mechanism in the day to day work of plain old java developers? You make my day with that sentence :) More seriously, there are two parts in a dependency injection (DI) mechanism. The

Re: Services and Bindings - expected usage scenarios

2016/11/29 6:54:35 -0800, vitaliy.pisa...@hpe.com: > ... > > I am looking at the great features in Java 9 and I know that we are > going to "jump" on the new module system with all the encapsulation it > gives us. But I and my fellow Architects are very unsure what to > think of the

hg: jigsaw/jake/jdk: 3 new changesets

Changeset: 364508692927 Author:alanb Date: 2016-11-29 13:59 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/364508692927 jar --print-module-descriptor should handle open module/packages ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java Changeset: 471f9aaac991

hg: jigsaw/jake/jdk: Add --{help, help-extra, version, full-version, show-version} launcher options to print to stdout

Changeset: 9e5ecc1ee202 Author:mr Date: 2016-11-29 07:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9e5ecc1ee202 Add --{help,help-extra,version,full-version,show-version} launcher options to print to stdout !

hg: jigsaw/jake: Adjusted workaround for javafx import with new module-info format

Changeset: 891ed56bc4da Author:erikj Date: 2016-11-29 17:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/891ed56bc4da Adjusted workaround for javafx import with new module-info format ! make/common/Modules.gmk

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Hi, I’ve reviewed Langtools code. There are various comment “//TODO”, “//FIXME”, “//XXX”. I think they should be revised. May be issues should be filed to track them. Unused import at 37 import java.io.IOException; in langtools/test/tools/javac/modules/ModuleInfoTest.java ASCII graphics issue

hg: jigsaw/jake/jdk: Fixed typo in javadoc

Changeset: 32c356a9f79c Author:alanb Date: 2016-11-29 17:41 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/32c356a9f79c Fixed typo in javadoc ! src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java