2

Before Java9, I could get the URLClassLoader instance and fetch the URL[] containing all the items on the classpath: jars and folders.

How can I do that in Java9? It would be super cool if I can do that using just regular API and not forcing users to add additional VM flags or who-knows-what.

For now, I am able to get the classpath for current module:

Module module = MyClass.class.getModule();
module.getClassLoader().getResource(
    classNameToResourceName(MyClass.class));

This can give me something like e.g. file:/Users/...... I can the same for any explicit class of 3rd party module, getting something like e.g.jar:file:///Users....

I know there if ModuleFinder that finds modules that are already on some path - which is the thing I want to find here.

I don't know how to get the paths for other modules/jars without needing to explicitly use a class from the module/jar (as shown above).

System.getProperty("java.class.path") is not working as it does not give the classpath, on Java9 example I tried it returns only the jar of the IntelliJ IDEA.

The reason is quite obvious: classpath scanning. This feature is not a new for the frameworks out there. For example, a user can build a class, annotate it and he is done - the framework would locate it and register it for him/her.

EDIT: the proposed duplicate question really is the same (about the scanning), however, the answer is helpful, but it is not complete.

igr
  • 10,199
  • 13
  • 65
  • 111
  • True, but it does not give a precise answer. – igr Dec 05 '17 at 07:38
  • I remember Alan answering this on some other thread as well. Do take a look at this as well though http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-September/013182.html – Naman Dec 05 '17 at 09:36
  • @nullpointer thanx didnt found that one. meanwhile i got some findings, testing, and will add an answer – igr Dec 05 '17 at 10:39
  • "This is a powerful feature that really removes the overhead of manual registration of classes." - have you looked at using services and ServiceLoader? – Alan Bateman Dec 05 '17 at 10:44
  • @AlanBateman ServiceLoader requires interfaces to be extracted. My framework does not need that. Just write a class, annotate it and - magic - its registered and available. Sure, you can use interfaces, but you dont have to. This is really simple and yet powerful developer experience IMHO. – igr Dec 05 '17 at 10:51
  • @AlanBateman the feature of scanning for a class is nothing new in the frameworks world. Please let's not change the focus from the question. – igr Dec 05 '17 at 10:53
  • Pointing out services is not changing the focus, it's just pointing out the existing mechanism in the platform. As regards your question then the implementation of the application class loader has never been documented (can't assume it's a URLClassLoader). The class path is exposed in the value of the java.class.path system property. – Alan Bateman Dec 05 '17 at 11:14
  • @AlanBateman you are right about the focus, sorry, I should clarify myself better. Will check the system path; i wonder why i never used that :) – igr Dec 05 '17 at 11:17
  • `System.getProperty("java.class.path")` returns just jar that runs the app, not the whole classpath, for example: "/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar". This is not what we need. – igr Dec 05 '17 at 11:19
  • java.class.path is the starting point. If the value is just a JAR file then I assume you are using an executable JAR. Are you using the Class-Path attribute and looking to expand that? The JDK does not have an API for doing that. – Alan Bateman Dec 05 '17 at 11:32
  • @AlanBateman of course I do. But again, what I get in return is not what I need, unfortunately - i simply do not get the list of classpath items loaded in the app (in java9) – igr Dec 05 '17 at 12:02
  • The answer to my question (that this one is a duplicate of) has been updated with some wonderful info. Check it out. – kaqqao Jun 14 '18 at 14:14

0 Answers0