Develop Reference

Multiple entry points (main classes) inside jar's top level

It worth to mention that I am using maven as my build management tool. I have a jar (let's call it dep.jar) which will be included into the final project (final.jar) as dependency.
dep.jar has a class with main method.
I need to have several entry points (classes with main methods) within my final.jar's top level directory so I can use entry point depending on my need. Including one from dep.jar.
I considered:
Changing META-INF/MANIFEST.MF file within jar. As Oracle stated that is not possible to reference main classes inside jar's dependencies (BOOT-INF/lib directory) -> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html;
Uber jar - not an option, I am dependent on jar directory structure inside Java code base
Using special class loader like this one http://www.jdotsoft.com/JarClassLoader.php. But it implies changing final.jar's main method which I cannot do due to project restrictions.
Using maven-dependency-plugin but it can unpack inner jar (dep.jar) and copy classes to maven working directory target which during packaging phase will be packed to BOOT-INF/classes directory. Again, I cannot reference main classes from there. If I unpack and copy them somewhere different than target - copied classes will not appear in my final.jar
Is there any other plugin or option how to add classes from final.jar dependant jar dep.jar during JAR build to final.jar's top level?
EDIT:
final.jar project looks like this:
final.jar
|_______BOOT-INF
|_______lib
| |_______dep.jar (contains main class I want to invoke)
|_______classes
|__________dir (directory I want to copy on demand with help of CLI)

I found a solution here Spring Boot - How to specify an alternate start-class? (Multiple Entry Points). Ended up using -Dloader.main property when launching jar.
Command line looks like these: java -jar -Dloader.main=<main_class> ./final.jar

Getting resource file from inside jar

I need to get a resource from inside the root of the application when its packed into jar. My project is like this:
ProjectRoot
resource.txt //want to access from here
src
main
java
package1
package2
package3
Main.java
target
app.jar
classes
resource.txt //works when here
package1
package2
package3
Main.class
I use this code:
Path path = Paths.get("resource.txt");
When run before packaging into a jar, it finds the file just fine (inside ProjectRoot). When running the jar, it can't find it, and transforms this path to target/resource.txt.
This code:
BufferedReader br = new BufferedReader(new InputStreamReader(new Main().getClass().getClassLoader().getResourceAsStream(
"resource.txt")));
when run before packaging looks for the resource inside target/classes. After packaging it claims to taking the resource from .../target/app.jar!/resource.txt.
This code:
BufferedReader br = new BufferedReader(new InputStreamReader(new Main().getClass().getClassLoader().getResourceAsStream(
"/resource.txt")));
I can't understand where's looking for the resource, but it doesn't seem to be ProjectRoot.
All I want to do is to place the resource inside ProjectRoot and be able to access it from both outside jar (when running the class files from IDE) and inside (after having packaged the files into a jar file using Maven).
EDIT: I NEED THE CODE TO WORK BOTH FOR PRE- AND POST- packaging. MEANING: If I run a Main.java FROM INSIDE IDE IT WOULD GET THE RESOURCE; IF I PACKAGE EVERYTHING INTO JAR AND RUN JAR IT WOULD GET THE RESOURCE - ALL WITH THE SAME CODE.

Use: Main.class.getResource("/resource.txt").
Note that your attempt using any call to getClassLoader is strictly worse (it's more text, and will fail more often, because that class loader can in exotic cases be null (specifically, when you're part of the bootstrap loader), whereas calling getResource directly on the class always works.
The reason your snippet does not work is because when invoking getResource on the classloader, you must NOT start the resource with a slash. When invoking on a class directly, you can (if you don't, it'll be relative to the package of the class you're calling it on, if you do, it'll be relative to the root).
TL;DR: Of the forms SomeClass.class.getClassLoader().getResource, getClass().getResource and MyClass.class.getResource, only the last one is correct, the rest are strictly inferior and therefore should not be used at all.

Maven uses something called the Standard Directory Layout. If you don't follow this layout then the plugins can't do their job correctly. Technically, you can configure Maven to use different directories but 99.999% of the time this is not necessary.
One of the features of this layout is that production files go in:
<project-dir>/src/main/java
All *.java files
<project-dir>/src/main/resources
All non-*.java files (that are meant to be resources)
When you build your project the Java source files are compiled and the *.class files are put into the target/classes directory; this is done by the maven-compiler-plugin. Meanwhile, the resource files are copied from src/main/resources into target/classes as well; the maven-resources-plugin is responsible for this.
Note: See Introduction to the Build Lifecycle for more information about phases and which plugins are executed by which phase. This Stack Overflow question may also be useful.
When you launch your application from the IDE (possibly via the exec-maven-plugin) the target/classes directory is put on the classpath. This means all the compiled classes from src/main/java and all the copied resources from src/main/resources are available to use via the classpath.
Then, when you package your application in a JAR file, all the files in target/classes are added to the resulting JAR file (handled by the maven-jar-plugin). This includes the resources copied from src/main/resources. When you launch the application using this JAR file the resources are still available to use via the classpath, because they're embedded in the JAR file.
To make resource.txt available on the classpath, just move:
<project-dir>/resource.txt
To:
<project-dir>/src/main/resources/resource.txt.
Then you can use Class#getResource with /resource.txt as the path and everything should work out for you. The URL returned by getResource will be different depending on if you're executing against target/classes or against the JAR file.
When executing against target/classes you'll get something like:
file:///.../<project-dir>/target/classes/resource.txt
When executing against the JAR file you'll get something like:
jar:file:///.../<project-dir>/target/projectname-version.jar!/resource.txt
Note: This all assumes resource.txt is actually supposed to be a resource and not an external file. Resources are typically read-only once deployed in a JAR file; if you need a writable file then it's up to you to use a designated location for the file (e.g. a folder in the user's home directory). One typically accesses external files via either java.io.File or java.nio.file.*. Remember, resources are not the same thing as normal files.
Now, if you were to put resource.txt directly under <project-dir> that would mean nothing to Maven. It would not be copied to target/classes or end up in the JAR file which means the resource is never available on the classpath. So just to reiterate, all resources go under src/main/resources.
Check out the Javadoc of java.lang.Class#getResource(String) for more information about the path, such as when to use a leading / and when not to. The link points to the Javadoc for Java 12 which includes information about resources and modules (JPMS/Jigsaw modules, not Maven modules); if you aren't using modules you can ignore that part of the documentation.

jdeprscan throws cannot find class error

I'm trying jdeprscan on my CentOS system. Here are the commands that I'm executing:
export classpath=<PATH/*>:<ANOTHER/PATH/*>:<SOME/OTHER/PATH/*>
jdeprscan --for-removal --verbose --class-path $classpath --release 9 <ANOTHER/PATH>/MyProject.jar
In spite of providing the classpath, I'm getting multiple errors of this sort
Processing class <some/class/in/MyProject.jar>...
error: cannot find class <some/class/in/a/different/jar>
error: cannot resolve Methodref <some/class/in/a/different/jar>.<method>:()Ljava/lang/String;
I've verified that the class mentioned in the error message are pretty much among one of the jars provided in the classpath.
Strangely, it's not the case that I'm getting this error for every other classes referred in the jar that I'm scanning.
Few points for your consideration:
The are 50+ jars in the paths provided in the classpath
The jar that I'm trying to scan is residing in one of the paths mentioned in the classpath
I've tried jdeprscan available in JDK 9 & JDK 10 and getting the same errors
I've tried replacing the * in classpath with *.jar, doesn't help!
Is there anything wrong in the syntax that I'm following or is this a known bug in jdeprscan?

Some preliminary notes on jdeprscsan from Oracle JDK 11 under Windows (I know the question related to JDK 9 on CentOS, but maybe the following applies as well...):
use wildcard "path/to/lib/*.jar" (it will not work without the ".jar" extension)
having a wildcard with more than one path is not supported (i.e. --class-path dir1/;dir2/*.jar throws a parse exception on the wildcard)
JARs in the directory specified by --class-path are added to the classpath and analyzed in alphabetical order, which may cause some error : cannot find class X messages because a JAR a.jar may depend on a JAR b.jar which is not yet loaded.
Based on the above, I found the 3 solutions below. Note that I did the same experiment with jdeprscan from the Oracle JDK 12.0.2 without any improvement.
Solution 1: all classes on the classpath
unzip all JARs in a specific directory (ignore overwritted files such as META-INF/maven/pom.xml), e.g. mylib (note that at this stage, the mylibs directory contains only classes organized by directory packages, and no JARs).
run the following command:
jdeprscan --for-removal --class-path /path/to/mylib /path/to/my-application.jar
Advantage: fast (very manual operations)
Drawback: only analyses the JAR file that has been specified on the command line (my-application.jar)
Solution 2: all JARs + a fat JAR on the classpath
copy all JARs libs into a single mylib directory
extract all files from JARs of mylib (ignore duplicate files) and repack them into a big JAR mylib/00lib.jar (a simple ZIP file renamed to .jar makes the trick)
copy the mylib/00lib.jar to mylib/01lib.jar to ensure that it will be analysed
run the following command:
jdeprscan --for-removal --verbose --class-path path/to/mylib/*.jar path/to/my-application.jar
Advantage: fast (only a few manual operations) + analyses the JARs from mylib
Drawback: some of the jdeprscan messages will be related to the fat JAR 00lib.jar so you will not be able to determine immediately which library uses classes that are deprecated or removed from Java 9 or 11, but you can do it indirectly by looking at the class name, e.g. (a class from the com.atomikos library requires the missing class javax.jms.JMSException):
Processing class com/atomikos/datasource/xa/jms/JmsTransactionalResource...
error: cannot find class javax/jms/JMSException
Solution 3: reorder the JAR files on the classpath
copy all JARs libs into a single mylib directory
run the following command:
jdeprscan --for-removal --class-path path/to/mylib/*.jar path/to/my-application.jar
inspect the log to see error: cannot find class messages that are not supposed to be raised because the JAR exists in the lib directory. For each such library, copy the library with a name that is before the library name which reference it alphabetically speaking. For example, I have a JAR in the lib dir alpha.jar which depends on commons-lang-3.0.jar (which is not yet loaded in the classpath), so I copy commons-lang-3.0.jar to a0commons-lang-3.0.jar so that it will be loaded before alpha.jar. It is important to copy the JAR and not to rename it otherwise it may not be analyzed by jdeprscan (does not occur on every JAR). Once done, go back to step 2 until no error messages produced by library dependencies occurs.
Advantage: gives a clear view of which JAR uses deprecated/removed classes.
Drawback: takes a lot time (manual copy of each individual JARs which cause a classloading issue).
Conclusion
I use jdeprscan with Solution 2. This should be considered as a workaround (is it an incomplete tool documentation or a bug, I don't know...).

If you happen to have a folder in PATH which has classes and JARs, it won't work. You'd have to specify the JARs individually (or get rid of the classes).

Reflection + libraries java

Edit: this is the Project Setup:
IDE: Eclipse:
Project1 : "Server"
src:
com/mainpackage/main.java
libs:
commons-x-0.jar
PluginInterface.jar
all jar in libs-folder are on the buildpath.
Project2 : "PluginInterface"
src:
com/interfaces/plugininterface
Project3 : "Plugin"
src:
com/package/class1.java - (this implements plugininterface)
libs:
library1.jar
PluginInterface.jar
all jar in libs-folder are on the buildpath
so when i export the Plugin (Project3) i get a jar like this (excluded PluginInterface.jar from export)
com/
com/package/
com/package/class1.class
com/package/class1.java
libs/
libs/library1.jar
library1.jar looks as follows - it is not written by me:
com/
com/stuff/
com/stuff/libclass.java
com/stuff/libclass.class
now i Want to utilize class1 in the "Server" over the Interface:
ClassLoader loader=URLClassLoader.newInstance(
new URL[]{new URL("file:path/to/plugin.jar")},
ClassLoader.getSystemClassLoader()
);
Class<?> pluginclass = Class.forName("com.package.class1", true, loader);
plugininterface ref = (plugininterface)pluginclass.newInstance();
i can now call methods from class1 using the interface both projects know, because both of them include "PluginInterface.jar" in their buildpath.
THE PROBLEM:
"Server" does not recognize "libclass", because is neither in its path nor did i load the class from the plugin.jar in which the library1 is nested.
how do i access this class if an import as library is not possible at the server?
Thanks for any help!
Edit: just for the sake if someone ever has this Problem again, i'll add the ANT files' build-target that makes it work:
<target name="build">
<javac destdir="bin" includeantruntime="false" source="1.7" target="1.7">
<src path="src"/>
<classpath refid="Plugin.classpath"/>
</javac>
<unzip src="${libs}/library1.jar" dest="bin/">
<patternset>
<include name="**/*.class"/>
</patternset>
</unzip>
<jar destfile="plugin.jar" basedir="bin"></jar>
</target>
Just copy the contents of the Library-jar into the build directory (in my case ./bin/). it then isn't even necessary to feed the libraryclasses to the Classloader, it finds them when loading the Classes use them.

The standard class loader does not support nested jar files. You could programmatically extract the jar, or write your own classloader which will decompress the nested files on demand. However, you'd be swimming against the current: such packaging is just not recommended. Instead it is recommended to explode the nested jar into its parent. This is, for example, what Maven dependency plugin does, and the default way to publish a Clojure application with Leiningen.
To achieve your goal from Eclipse the best approach seems be this:
have Eclipse's Export JAR wizard save the ant build scripts it internally generates to build your JAR;
adapt the resulting script to meet your specific needs;
in the future don't run the wizard anymore, but the ant script.

As mentioned by Marko, your standard class loader will not scan through nested jars and nested jars within them. However, if you're willing to play around with TrueZip, you can easily do this without having to extract archives or anything. What's better is that you can have nested archives within nested archives as deep as as you like. So your path could look like:
/path/to/foo.jar/bar/foo/my.zip/containing/some.tar/com/foo/My.class
If you feel comfortable writing your own classloader using TrueZip, this would be a neat way to do it. If not, then you'd have to write a utility class that parses the path and extracts the archives first, before feeding it into the standard URLClassloader.

what is correct internal structure of JAR file

This is a really silly question that I can't fine a difinitive answer to.
Background.
I'm using Eclipse (with one of the ANT plugins, on an XP terminal).
I have just started playing with ANT, in the [jar] directive I am setting the location of my finished JAR file and I get the following when I 'unzip' the file
META-INF/MANIFEST.MF
MyMainFile.class
which is consistent with that found on the oracle web site for the internal structure.
(here http://docs.oracle.com/javase/tutorial/deployment/jar/view.html )
But when I try to run my file I get a 'main class not found' error ?
I have seen some other posts where people have 'unzipped' the JAR file and ended up with a structure of the following...
META-INF/MANIFEST.MF
dtvcontrol/DTVControlApp.class
(from here http://www.coderanch.com/t/528312/java/java/standalone-application)
So should I get a structure where my class files are in a directory that reflects the name of the package... eg
META-INF/MANIFEST.MF
MyPackage/MyMainFile.class
and if so, why am I getting the incorrect structure using ANT, or why are there 2 different 'correct' internal structures? (how to specifify main-class and classpath for each / control what I get)
Also in case you are interested, in the MANIFEST file states (build using ANT)
[attribute name="Main-Class" value="MyPackage.MyMainFile"/]
Also the directory structure of the package under development is as follows...
/JavaDev/MyTestPackage/src (contains the source files)
//JavaDev/MyTestPackage/bin (contains the class files from eclipse, or from the ANT JAVAC task, have I named it incorrectly? should I have called it build ? )
Further to this, when I create the jar I am not naming it 'MyTestPackage.jar' but simply 'test.jar' could this be causing a problem? I assume not as if I have well understood that is what the [main-class] definition stuff is all about.
Further to all this...
'MyTestPackage' is actualy a small visual error messaging library that I use elsewhere, and I have a second file that has a main class to use for testing. As such it points to various libraries (do I need to copy all the SWT libraries to a specified directory?)
I have read somewhere that if I load libraries into my main class (which I obviously do to open the window) then trying to run the program will fail on a 'main class not found' if I use them, same is also true for adding in any 'static final' members (which I use for the loggin of errors).
'Static Final' problem...
I tried to adjust the classpath in ANT, and I get a load of other errors for the connection to Log4J and my 'wrapper' that I use (to do with it being a bad import), but the libraries exist where they should as set in the classpath).
I feel like I am almost there.... but not quite...
I'm doing this for the small 'library projects' that I am creating with the intention of using MAVAN for the main outer package that will connect them all together... for now however I just want to get this going so as it works.
I can supply the full source, or any other info as required.
Thanks in advance...
David

It's simple when you know where to look. Say your META-INF/MANIFEST.MF contains the line:
Main-Class: mypackage.MyMainFile
then the structure of the jar needs to be
META-INF/MANIFEST.MF
mypackage/MyMainFile.class
where MyMainFile has to be in the proper package:
package mypackage;
public class MyMainFile {
public static void main(String[] args) {
...
Your error message is caused by MyMainFile being in the wrong place.
Edit: it's been a while since the last time i did that with ant, but i think you need something like this: a source file structure that reflects the package struture, say
src/main/java/mypackage/MyMainFile.java
and a directory to put the compiled class file into, say
target
(I'm using maven conventions here, ant doesn't care and you can use the (rightclick)->properties->Java Build path->Sources tab in eclipse to set the source dir to src/main/java and the target to target/classes). Then in ant, have a compile target that compiles from source to target:
<target name="compile">
<mkdir dir="target/classes"/>
<javac srcdir="src/main/java" destdir="target/classes"/>
</target>
so that after ant compile you should see the class file in the target
target/classes/mypackage/MyMainFile.class
Then have a ant jar task that packages this:
<target name="jar" depends="compile">
<jar destfile="target/MyJarFile.jar" basedir="target/classes">
<manifest>
<attribute name="Main-Class" value="mypackage.MyMainFile"/>
</manifest>
</jar>
</target>
After saying ant compile jar you should have a file MyJarFile.jar inside target and
java -jar MyJarFile.jar
should run the main method.