hg: jigsaw/jake/langtools: Filter open packages when calling Builder::contains
Changeset: 3f46df92ca42 Author:mchung Date: 2016-11-30 17:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3f46df92ca42 Filter open packages when calling Builder::contains ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java
hg: jigsaw/jake/jdk: 2 new changesets
Changeset: 0a41a3f8b890 Author:mchung Date: 2016-11-30 18:00 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a41a3f8b890 Minor cleanup: remove unused local variable ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java Changeset: f42eb43b30d3 Author:mchung Date: 2016-11-30 18:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f42eb43b30d3 Fix jmod/jlink/jar w.r.t. the opens directive ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
hg: jigsaw/jake/jdk: Fix typo and formatting nit
Changeset: 08f950844aab Author:mchung Date: 2016-11-30 16:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/08f950844aab Fix typo and formatting nit ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/Layer.java
hg: jigsaw/jake/langtools: rename test class from Aux to Extra to avoid problems on Windows
Changeset: c64079dbb1ba Author:jjg Date: 2016-11-30 14:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c64079dbb1ba rename test class from Aux to Extra to avoid problems on Windows ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java ! test/tools/javac/modules/AnnotationsOnModules.java
Re: RFR 8160359: Improve jlink logging for cases when a plugin throws exception
> On Nov 30, 2016, at 3:05 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8160359
>
> jdk webrev: http://cr.openjdk.java.net/~sundar/8160359/webrev.01/
I expect JlinkTask::run method be updated such that it will always print the
stack trace when PluginException is caught rather than just printing the
message only.
ImagePluginStack.java
273 } catch (PluginException pe) {
274 if (JlinkTask.DEBUG) {
275 System.err.println("Plugin " + p.getName() + " threw
exception during transform");
276 pe.printStackTrace();
277 }
278 throw pe;
It might be useful for PluginException to take a plugin name in the constructor
so that the exception message is always prepended with the plugin name to help
troubleshooting. If JlinkTask::run is changed as suggested above, is line
273-278 still needed?
454 if (JlinkTask.DEBUG) {
455 System.err.println("IOException while reading
resource: " + res.path());
456 ex.printStackTrace();
457 }
458 throw new PluginException(ex);
Same as above comment and also PluginException should include res.path() in the
message.
As Alan mentioned, make/InterimImage.gmk should also be updated.
Mandy
hg: jigsaw/jake/jdk: Update ResourceBundle to find bundles visible to the class loader
Changeset: 46739df435c8 Author:mchung Date: 2016-11-30 13:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/46739df435c8 Update ResourceBundle to find bundles visible to the class loader ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilResourceBundleAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/classes/module-info.java + src/java.base/share/classes/sun/security/util/AuthResourcesProvider.java + src/java.base/share/classes/sun/security/util/AuthResourcesProviderImpl.java - src/java.base/share/classes/sun/util/locale/provider/ResourceBundleProviderSupport.java ! src/java.base/share/classes/sun/util/resources/Bundles.java ! src/java.logging/share/classes/java/util/logging/Level.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/jdk.security.auth/share/classes/module-info.java ! test/java/util/ResourceBundle/modules/modlocal/modlocal.sh ! test/java/util/ResourceBundle/modules/visibility/visibility.sh ! test/java/util/logging/LocalizedLevelName.java ! test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java ! test/sun/tools/jconsole/ResourceCheckTest.java
hg: jigsaw/jake/jdk: More typos and random cleanup
Changeset: cc35c0bc4a3c Author:alanb Date: 2016-11-30 21:02 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cc35c0bc4a3c More typos and random cleanup ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! test/java/security/testlibrary/Proc.java
hg: jigsaw/jake/hotspot: 8170542: Quarantine serviceability/jdwp/AllModulesCommandTest.java test
Changeset: a96915b95040 Author:gtriantafill Date: 2016-11-30 15:17 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a96915b95040 8170542: Quarantine serviceability/jdwp/AllModulesCommandTest.java test Summary: Add @ignore Reviewed-by: hseigel ! test/serviceability/jdwp/AllModulesCommandTest.java
Re: testing for a class having been loaded
By the way, I had no trouble finding examples on the web of using findLoadedClass() via reflection. I listed the first 11 below. Obviously, this hack is known, of interest, and used. I think it deserves to be an issue. > As I said, this change will not be popular but please bear with it until the > extent of the issues uncovered is more widely understood. We need all the > help we can get to identify issues and get them reported (and hopefully > fixed) by the libraries and tools with the technical debt (and we expect a > lot of it will be technical debt). For those working on OpenJDK and the JDK 9 > project then it's very possible that some of these issues will redirect to > the JDK as requests for new APIs or hooks (and I assume will need to be > looked at on a case-by-case basis). > > Any help reporting issues to popular tools and libraries would be appreciated. https://github.com/HotswapProjects/HotswapAgent/blob/master/hotswap-agent-core/src/main/java/org/hotswap/agent/util/classloader/ClassLoaderHelper.java http://stackoverflow.com/questions/482633/in-java-is-it-possible-to-know-whether-a-class-has-already-been-loaded http://stackoverflow.com/questions/12093271/how-do-i-determine-class-loading-order-when-i-inject-them-into-the-systemclasslo https://dzone.com/articles/classloaderlocal-how-avoid http://snacktrace.com/artifacts/net.bytebuddy/byte-buddy-dep/1.3.20/net.bytebuddy.dynamic.loading.ClassInjector https://fossies.org/linux/yacy/source/net/yacy/document/parser/pdfParser.java http://lists.jboss.org/pipermail/jboss-cvs-commits/2010-May/120099.html https://devops.ands.org.au/browse/VT-BUILD-55/artifact/JOB1/Javadoc/src-html/au/org/ands/vocabs/toolkit/utils/ApplicationContextListener.html http://visualvm.sourcearchive.com/documentation/1.2.1-0ubuntu1/ClassLoaderManager_8java-source.html http://code.taobao.org/svn/QLExpress/trunk/src/main/java/com/ql/util/express/ExpressClassLoader.java http://svn.rifers.org/rife/tags/release-1.4/src/framework/com/uwyn/rife/engine/EngineClassLoader.java
Re: testing for a class having been loaded
On 11/30/2016 07:07 PM, Alan Snyder wrote:
Why separately packaged? The goal would be loose coupling allowing
smaller images. Same goal as Jigsaw…
Your solution uses Class.forName(), which will load classes. Perhaps
it works, but doesn’t it rely on implementation specific behavior for
nested static classes?
Alan
You can create a top-level class if you are worried. You don't even need
two "Loaded" classes. One "Rendezvous" class is enough. Like this:
package pkga;
public final class Rendezvous {
private static Class aClass, bClass;
static synchronized void aLoaded(Class aCl) {
aClass = aCl;
if (bClass != null) {
connect();
}
}
public static synchronized void bLoaded(Class bCl) {
bClass = bCl;
if (aClass != null) {
connect();
}
}
private static void connect() {
System.out.println("Connecting " + aClass + " with " + bClass);
}
}
package pkga;
public class A {
static {
Rendezvous.aLoaded(A.class);
}
public static void use() {
System.out.println("A used.");
}
}
package pkgb;
public class B {
static {
try {
Class rendezvousClass = Class.forName("pkga.Rendezvous");
B.class.getModule().addReads(rendezvousClass.getModule());
rendezvousClass.getMethod("bLoaded",
Class.class).invoke(null, B.class);
} catch (ReflectiveOperationException ignore) {
// A$Rendezvous not visible
}
}
public static void use() {
System.out.println("B used.");
}
}
Regards, Peter
On Nov 30, 2016, at 9:52 AM, Peter Levart > wrote:
Hi Alan,
On 11/29/2016 10:14 PM, Alan Snyder wrote:
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 bad thing to be able
to do this?
Here is my use case:
I have two classes, A and B, that have been designed to be aware of
each other, but are packaged in separate JAR files or modules that
can be loaded independently. My goal is for these classes to make a
runtime connection with each other, but only if both have been
loaded by the application.
If each class can at load (initialization) time test whether the
other has been loaded, then they can use reflection to make that
connection.
All of the other solutions I have thought of require yet a third
class/interface C that is separately packaged and loaded by both A
and B. This is feasible, but seems unnecessary.
Why separately packaged? You could do something like the following:
package pkga;
public class ClassA {
public static final class Loaded {
private static boolean loaded;
public static boolean isLoaded() { return loaded; }
}
static {
try {
Class bLoadedClass = Class.forName("pkgb.ClassB$Loaded");
ClassA.class.getModule().addReads(bLoadedClass.getModule());
java.lang.reflect.Method bLoadedMethod =
bLoadedClass.getMethod("isLoaded");
synchronized (ClassA.Loaded.class) {
ClassA.Loaded.loaded = true;
boolean bLoaded = (Boolean) bLoadedMethod.invoke(null);
if (bLoaded) {
connect();
}
}
} catch (ReflectiveOperationException ignore) {
// ClassB.Loaded not visible
}
}
private static void connect() {
System.out.println("Connecting from A -> B");
}
public static void use() {
System.out.println("A used.");
}
}
package pkgb;
public class ClassB {
public static final class Loaded {
private static boolean loaded;
public static boolean isLoaded() { return loaded; }
}
static {
try {
Class aLoadedClass = Class.forName("pkga.ClassA$Loaded");
ClassB.class.getModule().addReads(aLoadedClass.getModule());
java.lang.reflect.Method aLoadedMethod =
aLoadedClass.getMethod("isLoaded");
synchronized (aLoadedClass) {
ClassB.Loaded.loaded = true;
boolean aLoaded = (Boolean) aLoadedMethod.invoke(null);
if (aLoaded) {
connect();
}
}
} catch (ReflectiveOperationException ignore) {
// ClassA.Loaded not visible
}
}
private static void connect() {
System.out.println("Connecting from B -> A");
}
public static void use() {
System.out.println("B used.");
}
}
Regards, Peter
Re: testing for a class having been loaded
Why separately packaged? The goal would be loose coupling allowing smaller
images. Same goal as Jigsaw…
Your solution uses Class.forName(), which will load classes. Perhaps it works,
but doesn’t it rely on implementation specific behavior for nested static
classes?
Alan
> On Nov 30, 2016, at 9:52 AM, Peter Levart wrote:
>
> Hi Alan,
>
> On 11/29/2016 10:14 PM, Alan Snyder wrote:
>> 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 bad thing to be able to do
>> this?
>>
>> Here is my use case:
>>
>> I have two classes, A and B, that have been designed to be aware of each
>> other, but are packaged in separate JAR files or modules that can be loaded
>> independently. My goal is for these classes to make a runtime connection
>> with each other, but only if both have been loaded by the application.
>>
>> If each class can at load (initialization) time test whether the other has
>> been loaded, then they can use reflection to make that connection.
>>
>> All of the other solutions I have thought of require yet a third
>> class/interface C that is separately packaged and loaded by both A and B.
>> This is feasible, but seems unnecessary.
>
> Why separately packaged? You could do something like the following:
>
>
> package pkga;
>
> public class ClassA {
>
>public static final class Loaded {
>private static boolean loaded;
>public static boolean isLoaded() { return loaded; }
>}
>
>static {
>try {
>Class bLoadedClass = Class.forName("pkgb.ClassB$Loaded");
> ClassA.class.getModule().addReads(bLoadedClass.getModule());
>java.lang.reflect.Method bLoadedMethod =
> bLoadedClass.getMethod("isLoaded");
>synchronized (ClassA.Loaded.class) {
>ClassA.Loaded.loaded = true;
>boolean bLoaded = (Boolean) bLoadedMethod.invoke(null);
>if (bLoaded) {
>connect();
>}
>}
>} catch (ReflectiveOperationException ignore) {
>// ClassB.Loaded not visible
>}
>}
>
>private static void connect() {
>System.out.println("Connecting from A -> B");
>}
>
>public static void use() {
>System.out.println("A used.");
>}
> }
>
>
> package pkgb;
>
> public class ClassB {
>
>public static final class Loaded {
>private static boolean loaded;
>public static boolean isLoaded() { return loaded; }
>}
>
>static {
>try {
>Class aLoadedClass = Class.forName("pkga.ClassA$Loaded");
> ClassB.class.getModule().addReads(aLoadedClass.getModule());
>java.lang.reflect.Method aLoadedMethod =
> aLoadedClass.getMethod("isLoaded");
>synchronized (aLoadedClass) {
>ClassB.Loaded.loaded = true;
>boolean aLoaded = (Boolean) aLoadedMethod.invoke(null);
>if (aLoaded) {
>connect();
>}
>}
>} catch (ReflectiveOperationException ignore) {
>// ClassA.Loaded not visible
>}
>}
>
>private static void connect() {
>System.out.println("Connecting from B -> A");
>}
>
>public static void use() {
>System.out.println("B used.");
>}
> }
>
>
>
>
> Regards, Peter
Re: testing for a class having been loaded
All questions are worthy of some study, but I’m not getting why you question the sanity of asking for the status of classes but have no problem with asking for the status of packages. Do you have some vague sense of possible problems? Alan > On Nov 30, 2016, at 8:45 AM, Alan Bateman wrote: > > On 30/11/2016 15:51, Alan Snyder wrote: > >> : >> As Michael said, the hack is using reflection with setAccessible() to call >> the protected method ClassLoader::findLoadedClass(). >> >> Is there some conceptual or security reason to not provide this >> functionality in a public API? > It's protected because it's for use in class loader implementations. It is > final so it could potentially be changed to public but would require a lot of > consideration before going that road. To be honest, the scenario is a bit > odd, there must be a saner solution that doesn't involve checking if classes > are loaded. > > -Alan
Re: testing for a class having been loaded
Hi Alan,
On 11/29/2016 10:14 PM, Alan Snyder wrote:
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 bad thing to be able to do this?
Here is my use case:
I have two classes, A and B, that have been designed to be aware of each other,
but are packaged in separate JAR files or modules that can be loaded
independently. My goal is for these classes to make a runtime connection with
each other, but only if both have been loaded by the application.
If each class can at load (initialization) time test whether the other has been
loaded, then they can use reflection to make that connection.
All of the other solutions I have thought of require yet a third
class/interface C that is separately packaged and loaded by both A and B. This
is feasible, but seems unnecessary.
Why separately packaged? You could do something like the following:
package pkga;
public class ClassA {
public static final class Loaded {
private static boolean loaded;
public static boolean isLoaded() { return loaded; }
}
static {
try {
Class bLoadedClass = Class.forName("pkgb.ClassB$Loaded");
ClassA.class.getModule().addReads(bLoadedClass.getModule());
java.lang.reflect.Method bLoadedMethod =
bLoadedClass.getMethod("isLoaded");
synchronized (ClassA.Loaded.class) {
ClassA.Loaded.loaded = true;
boolean bLoaded = (Boolean) bLoadedMethod.invoke(null);
if (bLoaded) {
connect();
}
}
} catch (ReflectiveOperationException ignore) {
// ClassB.Loaded not visible
}
}
private static void connect() {
System.out.println("Connecting from A -> B");
}
public static void use() {
System.out.println("A used.");
}
}
package pkgb;
public class ClassB {
public static final class Loaded {
private static boolean loaded;
public static boolean isLoaded() { return loaded; }
}
static {
try {
Class aLoadedClass = Class.forName("pkga.ClassA$Loaded");
ClassB.class.getModule().addReads(aLoadedClass.getModule());
java.lang.reflect.Method aLoadedMethod =
aLoadedClass.getMethod("isLoaded");
synchronized (aLoadedClass) {
ClassB.Loaded.loaded = true;
boolean aLoaded = (Boolean) aLoadedMethod.invoke(null);
if (aLoaded) {
connect();
}
}
} catch (ReflectiveOperationException ignore) {
// ClassA.Loaded not visible
}
}
private static void connect() {
System.out.println("Connecting from B -> A");
}
public static void use() {
System.out.println("B used.");
}
}
Regards, Peter
Re: Services and Bindings - expected usage scenarios
On 30.11.2016 17:31, mark.reinh...@oracle.com wrote: [...] The SE Platform has ServiceLoader rather than a built-in DI mechanism because the former is more primitive and imposes less overhead, while the latter can be built on top of the former. (I don't really know, nor care, whether java.util.ServiceLoader is officially an instance of the Service Locator pattern.) while some form of DI can be built on top of ServiceLoader, it usually is not. And that is because it is really annoying to do so. Imagine for example in Spring what you have to do to get DI configured only in Java running on top of the ServiceLoader architecture. Just imagine how many additional ClassLoaders you will need and now also Layers. And then imagine how you are going to test all this... And you really, really cannot expect that this all will be done without the user noticing additional quirks. I see not a single thing being better for DI with non-static descriptors in jigsaw. Only many more complications bye Jochen
Re: testing for a class having been loaded
On 30/11/2016 15:51, Alan Snyder wrote: : As Michael said, the hack is using reflection with setAccessible() to call the protected method ClassLoader::findLoadedClass(). Is there some conceptual or security reason to not provide this functionality in a public API? It's protected because it's for use in class loader implementations. It is final so it could potentially be changed to public but would require a lot of consideration before going that road. To be honest, the scenario is a bit odd, there must be a saner solution that doesn't involve checking if classes are loaded. -Alan
Re: Services and Bindings - expected usage scenarios
2016/11/29 9:30:29 -0800, vitaliy.pisa...@hpe.com: > Thank you mark, this goes far to answer my question. > > I do want to ask you 3 follow-up questions: > > ... > > By promoting the SL pattern, aren’t you effectively taking a stand in > this debate? An SL proponent might say: "Look! The Java architects > actually made it part of the language! so it must be superior to DI" > But of course the validity (or-invalidity) of this sentence comes from > your intent, not from the fact. I can equally well imagine a DI proponent saying, "Look! The Java EE architects made CDI part of the EE platform, so it must be superior to SL and those Java SE architects must be idiots!". I take no position on whether DI is inherently superior to SL, or vice-versa. Each approach has its strengths and weaknesses. I do agree with Fowler [1]: The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application. The SE Platform has ServiceLoader rather than a built-in DI mechanism because the former is more primitive and imposes less overhead, while the latter can be built on top of the former. (I don't really know, nor care, whether java.util.ServiceLoader is officially an instance of the Service Locator pattern.) > Also- what would you say to an application that does use a DI > framework? would you say that using an SL in this constellation is > inferior or would you justify cases where DI and SL can be applied in > conjunction? I'm no Pattern Philosopher, but in the abstract I'd say that using both DI and SL in the same component (i.e., module) is probably a code smell, while using both in a large, multi-component application is probably unavoidable and nothing to worry about. > Finally, it seems to me that the gaols of Jigsaw as stated in the JSR > are fully met even without the service provider clause in the module > declaration. Seeing that each feature in the language is astoundingly > expensive, you must have had very strong incentive to push for this > direction. I wonder what was it that drove you to include this? In a modular system, a specific implementation of a service can be composed of multiple modules. Provisioning a service can thus induce the resolution of additional modules, which can in turn induce the provisioning of additional services. Module resolution and service provisioning are, in other words, recursively intertwined, hence it's not just appropriate but necessary for the module system to take services into account. - Mark [1] http://martinfowler.com/articles/injection.html
Re: testing for a class having been loaded
> On Nov 30, 2016, at 1:46 AM, Alan Bateman wrote: > > On 29/11/2016 21:14, Alan Snyder wrote: > >> 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 bad thing to be able to do >> this? > I can't quite tell what the hack is, is it reading the private `classes` > field? > As Michael said, the hack is using reflection with setAccessible() to call the protected method ClassLoader::findLoadedClass(). Is there some conceptual or security reason to not provide this functionality in a public API? >> >> Here is my use case: >> >> I have two classes, A and B, that have been designed to be aware of each >> other, but are packaged in separate JAR files or modules that can be loaded >> independently. My goal is for these classes to make a runtime connection >> with each other, but only if both have been loaded by the application. >> >> If each class can at load (initialization) time test whether the other has >> been loaded, then they can use reflection to make that connection. >> >> All of the other solutions I have thought of require yet a third >> class/interface C that is separately packaged and loaded by both A and B. >> This is feasible, but seems unnecessary. >> > The scenario sounds like it needs a broker but without specifics then it's > hard to make suggestions. > > One question: Are A and B in different packages? If A is p.A and B is q.B > when would it be enough to know if any p.* or q.* types have been loaded? If > so then ClassLoader::getDefinedPackage might be useful. ClassLoader::getDefinedPackage might be useful in a new design, especially one using modules, as split packages are not allowed. However, I’m not sure of the implications of this method not searching ancestor class loaders. Might there be circumstances where the result is not consistent with findLoadedClass()? Alan
Re: testing for a class having been loaded
On 30 November 2016 at 11:46, Alan Bateman wrote: > I can't quite tell what the hack is, is it reading the private `classes` > field? I assume reflectively calling ClassLoader::findLoadedClass ? /Michael
Re: RFR 8160359: Improve jlink logging for cases when a plugin throws exception
On 30/11/2016 11:05, Sundararajan Athijegannathan wrote: Please review fix for https://bugs.openjdk.java.net/browse/JDK-8160359 jdk webrev: http://cr.openjdk.java.net/~sundar/8160359/webrev.01/ top webrev: http://cr.openjdk.java.net/~sundar/8160359/top/webrev.01/ For the top-level repo then I assume you also need to update InterimImage.gmk so that we have debugging when creating the interim image. Often when building the JDK then this will be the place it will fail. -Alan
Re: RFR 8160359: Improve jlink logging for cases when a plugin throws exception
Looks good to me! /Claes On 2016-11-30 12:05, Sundararajan Athijegannathan wrote: Please review fix for https://bugs.openjdk.java.net/browse/JDK-8160359 jdk webrev: http://cr.openjdk.java.net/~sundar/8160359/webrev.01/ top webrev: http://cr.openjdk.java.net/~sundar/8160359/top/webrev.01/ This is mainly a debugging aid for jlink invocation - in particular from jdk makefiles. We'd like to get maximum info. like stack trace on exception from builtin plugin invocation from jdk makefiles. Main changes from earlier round: * Plugin.configure should throw only IllegalArgumentException (never PluginException) - as suggested by Mandy earlier. * jlink.debug turned on for JDK makefile's invocation of jlink (top webrev) - as suggested by Claes earlier. Earlier round of review: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010034.html Thanks, -Sundar
Re: RFR 8160359: Improve jlink logging for cases when a plugin throws exception
+1 > On Nov 30, 2016, at 7:05 AM, Sundararajan Athijegannathan > wrote: > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8160359 > > jdk webrev: http://cr.openjdk.java.net/~sundar/8160359/webrev.01/ > > top webrev: http://cr.openjdk.java.net/~sundar/8160359/top/webrev.01/ > > This is mainly a debugging aid for jlink invocation - in particular from > jdk makefiles. We'd like to get maximum info. like stack trace on > exception from builtin plugin invocation from jdk makefiles. > > Main changes from earlier round: > > * Plugin.configure should throw only IllegalArgumentException (never > PluginException) - as suggested by Mandy earlier. > > * jlink.debug turned on for JDK makefile's invocation of jlink (top > webrev) - as suggested by Claes earlier. > > Earlier round of review: > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010034.html > > Thanks, > > -Sundar >
Re: #CyclicDependences with ServiceLoader
On 30.11.2016 10:16, Alan Bateman wrote:
On 30/11/2016 08:53, Jochen Theodorou wrote:
Hi,
for my understanding I would like to ask the following:
Given:
* Module A: uses service S1 and provides service S2
* Module B: uses service S2 and provides service S1
In my understanding this forms a cyclic dependency, but since this is
not directly on the API level I am wondering if this is really one
"per definition as to be seen by jigsaw"?
You need to expand the example a bit to say where S1 and S2 are, it's
otherwise impossible to say if there is a cycle in the dependency graph.
For example, there is no cycles here:
module S {
exports p;
}
module A {
requires S;
uses p.S1;
provides p.S2 with ...
}
module B {
requires S;
uses p.S2;
provides p.S1 with ...
}
if that is no cycle, then you answered my question already. There is no
dependency between A and B in the sense that A uses a class from B and B
uses a class from A - not directly at least. But there is one through
the ServiceLoader, but it is still not cyclic for jigsaw, which looks
for that only at the "direct" API usage
And it is easy to see that if we drop S and put the service interface
for S1 in A and the one for S2 in B that we then get a cycle just
because of "requires"
thanks,
Jochen
Re: Code review for jigsaw/jake -> jdk9/dev sync up
test/java/security/testlibrary/Proc.java:
if (hasModules) {
Stream.of(jdk.internal.misc.VM.getRuntimeArguments())
-.filter(arg -> arg.startsWith("--add-exports="))
+.filter(arg -> arg.startsWith("--add-exports=") ||
+ arg.startsWith("--add-opens"))
.forEach(cmd::add);
}
Maybe "--add-opens=" to be more precise?
Thanks
Max
Re: Code review for jigsaw/jake -> jdk9/dev sync up
Thanks to everyone that have been reviewing these changes. I've pushed an updated set of webrevs here: http://cr.openjdk.java.net/~alanb/8169069/1/ The update includes changes to address most of the reviewer comments so far. There are a few more cleanups that still need to be pushed today but I think we are otherwise in reasonable shape at this point. As I said in the original mail, we will keep the jake forest open as there are still issues to work on after this integration. -Alan
RFR 8160359: Improve jlink logging for cases when a plugin throws exception
Please review fix for https://bugs.openjdk.java.net/browse/JDK-8160359 jdk webrev: http://cr.openjdk.java.net/~sundar/8160359/webrev.01/ top webrev: http://cr.openjdk.java.net/~sundar/8160359/top/webrev.01/ This is mainly a debugging aid for jlink invocation - in particular from jdk makefiles. We'd like to get maximum info. like stack trace on exception from builtin plugin invocation from jdk makefiles. Main changes from earlier round: * Plugin.configure should throw only IllegalArgumentException (never PluginException) - as suggested by Mandy earlier. * jlink.debug turned on for JDK makefile's invocation of jlink (top webrev) - as suggested by Claes earlier. Earlier round of review: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010034.html Thanks, -Sundar
Re: Code review for jigsaw/jake -> jdk9/dev sync up
On 28/11/2016 14:47, Chris Hegarty wrote: : 2) jartool Main.java Maybe concealedPackages should have a comment about its use ( it is used in the Validator, and not by Main at all ). Just on this one, I think this was introduced when Steve added the MR JAR validation, I agree it's ugly but we haven't changed it here. I'll add a comment as you suggest but it does some overall cleanup as part of finishing up the MR JAR work. -Alan
Re: Migrating to uses from an existing module system
On 29/11/2016 22:45, Thomas Watson wrote:
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
discussion the existing code could look like this:
ServiceLoader sl =
ServiceLoader.load(PrintServiceLookup.class);
System.out.println(sl.findFirst().orElseGet(() -> {return
null;}));
Without mapping OSGi to JPMS modules this code works fine.
but only if you resolve the modules that provide implementations of
PrintServiceLookup. The platform modules may provide one or more
implementations of PrintServiceLookup but there may be others that the
above consumer may wish to select.
I guess I can't quite tell if you are doing service binding
(resolveRequiresAndUses) or not. Even so, I assume the generated module
doesn't declare any `uses`, hence there won't be any any service
consumers (beyond what the platform modules might provide).
This is
because the code ends up being loaded by an unnamed module for which JPMS
assumes is allowed to use any service through the ServiceLoader. But once
I map the OSGi bundle class loader to a JPMS module the code above fails
to work with an exception:
java.util.ServiceConfigurationError: javax.print.PrintServiceLookup:
module test.service.loader does not declare `uses`
Is there any way around this? I know there is an addUses method, and I
also know that I can generate ModuleDescriptors for my Layer that specify
a proper uses requirement. But that would require a code scan to discover
all possible calls to the ServiceLoader in order to declare the uses.
Existing code can been coerced into an automatic module and can use any
service provider in modules that are resolved by other means. However,
in the above then it looks like existing code has been coerced into a
"normal" module and is missing its `uses` declaration. This means it has
to use addUses at run time (the check that you run into is specifically
there to ensure that consumer modules declare the service types that
they use, it shouldn't be necessary to have to list the service provider
modules explicitly via --add-modules or equivalent).
-Alan
Re: testing for a class having been loaded
On 29/11/2016 21:14, Alan Snyder wrote: 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 bad thing to be able to do this? I can't quite tell what the hack is, is it reading the private `classes` field? Here is my use case: I have two classes, A and B, that have been designed to be aware of each other, but are packaged in separate JAR files or modules that can be loaded independently. My goal is for these classes to make a runtime connection with each other, but only if both have been loaded by the application. If each class can at load (initialization) time test whether the other has been loaded, then they can use reflection to make that connection. All of the other solutions I have thought of require yet a third class/interface C that is separately packaged and loaded by both A and B. This is feasible, but seems unnecessary. The scenario sounds like it needs a broker but without specifics then it's hard to make suggestions. One question: Are A and B in different packages? If A is p.A and B is q.B when would it be enough to know if any p.* or q.* types have been loaded? If so then ClassLoader::getDefinedPackage might be useful. -Alan
Re: #CyclicDependences with ServiceLoader
On 30/11/2016 08:53, Jochen Theodorou wrote:
Hi,
for my understanding I would like to ask the following:
Given:
* Module A: uses service S1 and provides service S2
* Module B: uses service S2 and provides service S1
In my understanding this forms a cyclic dependency, but since this is
not directly on the API level I am wondering if this is really one
"per definition as to be seen by jigsaw"?
You need to expand the example a bit to say where S1 and S2 are, it's
otherwise impossible to say if there is a cycle in the dependency graph.
For example, there is no cycles here:
module S {
exports p;
}
module A {
requires S;
uses p.S1;
provides p.S2 with ...
}
module B {
requires S;
uses p.S2;
provides p.S1 with ...
}
Ditto if you drop module S and move the service types to A (A will
`exports p` and B will `requires A`).
-Alan
#CyclicDependences with ServiceLoader
Hi, for my understanding I would like to ask the following: Given: * Module A: uses service S1 and provides service S2 * Module B: uses service S2 and provides service S1 In my understanding this forms a cyclic dependency, but since this is not directly on the API level I am wondering if this is really one "per definition as to be seen by jigsaw"? bye Jochen
