We Keep Coding

Why Java cannot read same resource file when module-info is added?

There is a simple Java project with standard Maven folder structure.
src
main
java
mypackage
Main.java
resource
abc
cde.txt
Main.java (boilerplate omitted)
var path = "abc/cde.txt";
InputStream input = Thread.currentThread().getContextClassLoader().getResourceAsStream(path);
if (input == null) {
throw new IllegalStateException("Resource not found");
} else {
// read from input
}
This code works fine and read file from the absolute path
"%project_root%/target/classes/abc/cde.txt" (compiled code).
After adding file src/main/java/module-info.java the situation changes: the program cannot find the file and throws in branch (input == null).
How to read files from "resource" folder the old way and have both: java-module and resources in the resource folder? I would like to avoid adding a prefix "src/main/resources" everywhere.

You probably want this:
InputStream input = Main.class.getResourceAsStream("/abc/cde.txt");
When you add a module-info.java, your classes are considered a module by Java.
A module has encapsulation restrictions beyond what a plain old classpath has. To access resources in a module, other code must go through that module, which will check whether the calling code’s module has permission to read those resources.
ClassLoader.getResourceAsStream will only read resources from explicitly opened modules:
Additionally … this method will only find resources in packages of named modules when the package is opened unconditionally.
But Class.getResource and Class.getResourceAsStream only rely on the module to which the class belongs, and don’t have that additional restriction.
One should always use Class.getResource or Class.getResourceAsStream. The ClassLoader equivalents should be avoided.
There is an important difference between the Class methods and the ClassLoader methods: The Class methods treat the argument as relative to the class’s package, unless the argument starts with a slash (/).
Aside from the encapsulation restrictions, given a class named com.example.MyApplication, these two lines are equivalent:
MyApplication.class.getResource("data.txt")
MyApplication.class.getClassLoader().getResource("com/example/data.txt")
And these are equivalent:
MyApplication.class.getResource("/data.txt")
MyApplication.class.getClassLoader().getResource("data.txt")
Again, they are only equivalent in terms of the resource path; the modular encapsulation restrictions are not the same. Always use the Class.getResource* methods, and avoid the ClassLoader.getResource* methods.

How to load a java class outside the classpath?

I have a program where I want the user to be able to choose a .java class file from the file system, and then have that class loaded into the program.
I'm using a JFileChooser to allow the user to select a file. Then, I tried converting that file to a URL, and using a URLClassLoader to load the class (as suggested by these answers).
The problem is that, when I want to use the loadClass() method, I don't know the "full class name" of the class (e.g. java.lang.String). So, I don't know how to make this method work. Is there a way to get this class name? Or is there another way to do this?
Here is a sample of my code:
// Open the file chooser
JFileChooser fileChooser = new JFileChooser();
fileChooser.showOpenDialog(null);
File obtainedFile = fileChooser.getSelectedFile();
// Create the class loader from the file
URL classPath = obtainedFile.toURI().toURL();
URLClassLoader loader = new URLClassLoader(new URL[] {classPath});
// Get the class from the loader
Class<?> theClassIWant = loader.loadClass("the file name"); // What do I put here??

Load a single class file is generally completely useless. Said class file isn't alone; it has more class files that are relevant. Even if you think 'nah, there is just one source file, do not worry about this', note that a single java file can easily generate multiple class files.
Thus, two options:
Don't load class files. Load jar files.
Use the usual mechanisms (META-INF/services or META-INF/MANIFEST.MF) to put some sort of class name in there so you know what to load. Then create a new classloader with the provided jar, load the manifest, figure out the main class, load that, and run it.
Attempt to determine the 'root' for the loaded class file and include that on the classpath.
This is quite difficult - the problem is, to 'load' a class file you need to tell the loader what the fully qualified name is of that class before it is loaded. But how do you know the fully qualified name? You can surmise the class name from the file (not quite always true, but usually), but the package is a more difficult issue.
You can open the class file yourself as a binary stream and write a basic class file format parser to get the fully qualified class name. Easy for an experienced java programmer. Quite tricky for someone new to java (which I gather you are, if you think this is a good idea).
You can also use existing tools to do this, such as bytebuddy or asm.
Finally, you can try a spaghetti-at-the-wall method: Keep travelling up the directory until it works. You know it isn't working if exceptions occur.
For example, to load C:\MyDir\Whatever\com\foo\MyApp.class, You first try creating a new classloader (see the API of URLClassLoader which is part of core java) using as root dir C:\MyDir\Whatever\com\foo, and then you ask it to load class MyApp.
If that works, great (but usually trying to load package-less classes is simply a non-starter, you're not supposed to do that, the CL API probably doesn't support it, intentionally, there is no fixing that).
If it doesn't, instead try C:\MyDir\Whatever\com, and load class foo.MyApp. If that doesn't work, try C:\MyDir\Whatever and load class com.foo.MyApp, and so on.
The considerable advantage is, if there is another class sitting right next to MyApp.class, and MyApp needs it, this will work fine.
You'll need to write a while loop (traversing the path structure using Paths.get and p.getParent()), catch the right exception, manipulate the path into the class name (using .replace and +), and, of course, create a class loader (URLClassLoader), load classes with it (invoke loadClass), and if you intend on running it, something like thatClass.getConstructor().newInstance() and then thatClass.getMethod("someMethod", String.class, /* all the other args here */).invoke(theInstanceYouJustMade, "param1", /*all other params */) to actually 'run' it, more to be found in the java.lang.reflect package.

How to instantiate a class without knowing its package?

I have an Eclipse project (MainProject) and it references another Eclipse project (ReferencedProject). MainProject also references a JAR file (ReferencedJar). This ReferencedJar's file name is known. I also know there is a class (ReferencedClass) in ReferencedJar, but I don't know in what package ReferencedClass is because the package path is not known beforehand.
I need to instantiate ReferencedClass in ReferencedProject using reflection. How can I do this? And will the solution be okay when the project is packaged to a its standalone jar outside Eclipse?
The reason for this question is; The ReferencedJar is file generated by a modeller application. It generates java classes for your model and puts them into ReferencedJar. The user can choose which package the classes it generates will be put into. But the class names are always the same. MainProject is project that will include this generated jar, but ReferencedProject (a framework) also needs to instantiate a class in this generated jar. Hope this makes the question more clear.
Thanks in advance
Edit: Actually I have an idea but don't know how to implement it. Because I know the name of ReferencedJar file, I could access it on runtime and check all the classes it contains. Then I can find the matching class by name comparison. But how can I access the ReferencedJar on runtime?

As long as the class you need is in the class path, you can get a reference to it by invoking Class.forName(String className)
String className = "WhatEver";
String packageName = "some.package";
Class<?> c = Class.forName(packageName + "." + className);
If you don't know the package name, however, and there's no way to get it from a configuration file, I would recommend using a library like reflections to scan the class path and find the relevant class.

You can not instantiate a class you if do not know its package

How to use ROME for RSS

I am using the code from Rome's tutorials page http://wiki.java.net/twiki/bin/view/Javawsxml/Rome05TutorialFeedReader .
When I try to compile, it says class FeedReader is public, should be declared in a file named FeedReader.java.
I am new to Java, but I think that the FeedReader class should be part of the package used in the example, or in one of the import paths. I can't find file com.sun.syndication.samples (which is the package from the example) in the Rome library I downloaded. Any thoughts?

The code from your tutorial is
package com.sun.syndication.samples;
public class FeedReader {
...
}
It must be in a file named FeedReader.java and put in a directory com/sun/syndication/samples. If you change the name of the class, you must change also the name of the java file. If you change the package declaration, you must also change the location of the file.

Error when I try to change the class name

class HelloObject {
void speak() {
System.out.println("Hello (from object)!");
}
}
class HelloTester {
public static void main(String[] args) {
HelloObject object = new HelloObject();
object.speak();
}
}
When I change the "HelloTester" class name to something like "HelloTester2", the program suddenly works. The class file is called ClassesBegin.java.
Why does the java program not work when I try to change the name of the class?
EDIT: Sorry I should have clarified more. I changed the class name to HelloTestera and this is the error I get:
Exception in thread "main" java.lang.NoClassDefFoundError: HelloTester
But it works even when the file name has nothing to do with a class name. It works with HelloTester when the file name is ClassesBegin.java

You need to change the file name, not just the class name.
In Java, the .java and .class names have to be identical to the class name.
Hence, each class has to go to a separate file with its name so that a separate .class file is created.
Putting two different classes in the same file is a C++ practice that works with its compilation model, not with Java.
Edit: User ended up clarifying what caused his error, so obviously my answer here is not relevant. All the above applies to public classes. You can pull that off for package-level classes though I have to say that I consider that a horrible practice. If you're going to have something used by multiple classes in your package, give it its own file. If it's used just by one class, make it an inner class...

"EDIT: Sorry I should have clarified more. I changed the class name to HelloTestera and this is the error I get: Exception in thread "main" java.lang.NoClassDefFoundError: HelloTester But it works even when the file name has nothing to do with a class name. It works with HelloTester when the file name is ClassesBegin.java"
The file name and the class name must match if the class is public.
If you chagned the class name to "HelloTestera" but ran "java HelloTester" (which is what java.lang.NoClassDefFoundError: HelloTester would indicate) then the issue is that you passed the wrong class name to "java".
But save yourself a lot of time and name the class and the file the same thing and keep it at one top level class per file. A simple way to "force" that is to make all of your classes public for now (you can only have one public class per file). This will really save you from making some mistakes.

You are allowed to have as many non-public classes in your ClassesBegin file as you like in terms of compilation. But only the public (ClassesBegin in this case; until you change the name of the file) is able to be used externally.
In particular, the main() method must be public, and in a public class to be able to be found by java. Rename your file to HelloTester to make it work.
Or - rename the HelloTester class in your IDE, which probably is relaming the file automatically, since it has a main method, and the IDE knows that it needs to be the public class...

The easiest way to do this is:
1) only one top level class per file
2) the name of the class and the name of the file must match (name and CasE)
This makes it easier to find you classes (the name of the class is the name of the file) and you don't wind up with some odd issues where the compielr cannot find all of the classes to copmpile.
Java also has a restriction where the name of a public class 100% must be the same as the name of the file. The restriction is only on public classes (or interfaces or enums). You can have as many non-public types as you want in a file... but don't do that - stick with one top level class/interface/enum per file.

You write:
I changed the class name to HelloTestera and this is the error I get: Exception in thread "main" java.lang.NoClassDefFoundError: HelloTester
It seems you are not actually running the renamed class but the old one. Did you call Java with the new changed class name? Did you recompile the file before running the class?
After renaming the class, you should first run:
javac ClassesBegin.java
And then:
java HelloTestera
Which for me yields:
Hello (from object)!
Usually, when using an IDE, these issues are handled for you (compile before running).