It appears to me that JAR file indexing breaks the mechanics of ClassLoader.getResources(). Consider the following program:
import java.io.*;
import java.net.*;
import java.util.*;
public class TryIt {
public static void main(String[] args) throws Exception {
URL[] urls = {
(new File("a.jar")).getAbsoluteFile().toURI().toURL(),
(new File("b.jar")).getAbsoluteFile().toURI().toURL()
};
URLClassLoader cl = URLClassLoader.newInstance(urls);
String[] res = { "foo", "foo/", "foo/arb", "foo/bar", "foo/cab" };
for (String r: res) {
System.out.println("'" + r + "':");
for (URL u: Collections.list(cl.getResources(r)))
System.out.println(" " + u);
}
}
}
Now prepare the JAR files mentioned in that program:
mkdir a/foo b/foo
touch a/foo/arb a/foo/bar b/foo/bar b/foo/cab
echo "Class-Path: b.jar" > mf
jar cfm a.jar mf -C a foo
jar cf b.jar -C b foo
If you run java TryIt, you will get output like this:
'foo':
jar:file:…/a.jar!/foo
jar:file:…/b.jar!/foo
'foo/':
jar:file:…/a.jar!/foo/
jar:file:…/b.jar!/foo/
'foo/arb':
jar:file:…/a.jar!/foo/arb
'foo/bar':
jar:file:…/a.jar!/foo/bar
jar:file:…/b.jar!/foo/bar
'foo/cab':
jar:file:…/b.jar!/foo/cab
But if you run jar -i a.jar to create an index, then the same command as above prints this:
'foo':
jar:file:…/a.jar!/foo
'foo/':
jar:file:…/a.jar!/foo/
'foo/arb':
jar:file:…/a.jar!/foo/arb
'foo/bar':
jar:file:…/a.jar!/foo/bar
'foo/cab':
jar:file:…/b.jar!/foo/cab
The index itself looks like this:
JarIndex-Version: 1.0
a.jar
foo
b.jar
foo
Doesn't the contract of getResources imply that all available resources matching the given name should be returned?
Finds all the resources with the given name.
Doesn't the JAR File Specification allow indexed packages to span multiple JAR files?
Normally one package name is mapped to one jar file, but if a particular package spans more than one jar file, then the mapped value of this package will be a list of jar files.
Is there some specification somewhere which says that what I'm observing is indeed correct (or at least permissible) behavior?
Is there some workaround to get all named resources despite the index?
This appears to be a bug.
I've reported it to Oracle, and it's now in their bug database as bug 8150615.
I did some digging around in the OpenJDK sources and found the reson for this behavior in there.
The relevant class here is sun.misc.URLClassPath. It contains a (lazily constructed) list of loaders, and queries each loader in turn to assemble its result. However, if a JAR file contains an index, then the JAR files therein will explicitely be excluded from getting added to the list of loaders. Instead, the loader for the JAR containing the index will query said index for the name in question, and traversed the resulting list. But here is the catch: this happens in a method URLClassPath$JarLoader.getResource which returns a single Resource object. It is not possible for this method to return multiple resources. And as all objects in the index are handled by a single loader, a single resource is all we get.
Related
Here's my Situation:
I have a folder Structure:
C:\Users\user\Desktop\JavaTraining\Chapter3\examples.
examples is also a folder. Now, I have a file name Calculator.Java in Chapter3 folder with the package statement package Chapter3;. So, from the Command Line I compiled the file from the JavaTraining directory as javac Chapter3\Calculator.java, It compiled and I see a file Calculator.class generated. But when I run the command java Chapter3.Calculator from the JavaTraining Directory. It throwed me an error: Could not find file or load main class Chapter3.Calculator.
Then, I created a sub folder in Chapter3 named examples and copied the Calculator.java into the examples folder and tried compiling and executing the file thinking Chapter3 as the root folder ( executed commands from the Chapter3 directory). No error, the file got executed.
Please can anyone explain me why this happened or what is the reason behind it, I am going mad...
Calculator.java is just a class Calculator with main function trying to find a sum from a printsum function of two variables.
I went through the suggestions provided in http://stackoverflow.com/questions/18093928/what-does-could-not-find-or-load-main-class-mean
According to the above, it was either the syntax mistake ( the way of trying to executing the file) or setting the PATH and CLASSPATH environment variables.
I even tried the echo %CLASSPATH% to see if my CLASSPATH variable is set to current directory. It did show me the . when I executed the echo command from JavaTraining directory.
The file did not execute when I tried Chapter3 folder as root directory, but when I create a subfolder in Chapter3 and made Chapter3 as the root directory, it executed, what might be the reason or what am I doing wrong,
Here is the command line with the output:
C:\Users\vikas\Desktop\JavaTraining>javac Chapter3\Calculator.java
C:\Users\vikas\Desktop\JavaTraining>java Chapter3.Calculator
Error: Could not find or load main class Chapter3.Calculator
C:\Users\vikas\Desktop\JavaTraining>cd Chapter3
C:\Users\vikas\Desktop\JavaTraining\Chapter3>javac examples\Calculator.java
C:\Users\vikas\Desktop\JavaTraining\Chapter3>java examples.Calculator
The sum is 30
C:\Users\vikas\Desktop\JavaTraining\Chapter3>
The Calculator.java file:
// One Package Statement
package chapter3;
// The file in Chapter 3 folder, file in example folder has
//package examples;
// One or more import statements
import java.io.*;
import java.util.*;
// Class Declaration
public class Calculator {
// State. Variables and Constants
int i=10;
long k = 20;
// Behavior, one or more methods
void printSum(){
long sum;
sum = i+ k;
System.out.println("The sum is " + (i+k));
}
public static void main (String[] args) {
Calculator c = new Calculator();
c.printSum();
}
}
When you build a file, it is good to have a build directory, then java will put the class in the correct package layout.
mkdir build
javac -d build path/to/source/Files.java
java -cp build package.name.Files
I ran into library loading problems after creating a jar from my code via maven. I use intelliJ idea on Ubuntu. I broke the problem down to this situation:
Calling the following code from within idea it prints the path correctly.
package com.myproject;
public class Starter {
public static void main(String[] args) {
File classpathRoot = new File(Starter.class.getResource("/").getPath());
System.out.println(classpathRoot.getPath());
}
}
Output is:
/home/ted/java/myproject/target/classes
When I called mvn install and try to run it from command line using the following command I'm getting a NullPointerException since class.getResource() returns null:
cd /home/ted/java/myproject/target/
java -cp myproject-0.1-SNAPSHOT.jar com.myproject.Starter
same for calling:
cd /home/ted/java/myproject/target/
java -Djava.library.path=. -cp myproject-0.1-SNAPSHOT.jar com.myproject.Starter
It doesn't matter if I use class.getClassLoader().getRessource("") instead. Same problem when accessing single files inside of the target directory instead via class.getClassLoader().getRessource("file.txt").
I want to use this way to load native files in the same directory (not from inside the jar). What's wrong with my approach?
The classpath loading mechanism in the JVM is highly extensible, so it's often hard to guarantee a single method that would work in all cases. e.g. What works in your IDE may not work when running in a container because your IDE and your container probably have highly specialized class loaders with different requirements.
You could take a two tiered approach. If the method above fails, you could get the classpath from the system properties, and scan it for the jar file you're interested in and then extract the directory from that entry.
e.g.
public static void main(String[] args) {
File f = findJarLocation("jaxb-impl.jar");
System.out.println(f);
}
public static File findJarLocation(String entryName) {
String pathSep = System.getProperty("path.separator");
String[] pathEntries = System.getProperty("java.class.path").split(pathSep);
for(String entry : pathEntries) {
File f = new File(entry);
if(f.getName().equals(entryName)) {
return f.getParentFile();
}
}
return null;
}
Let's say there is a jar main.jar which depends on two other jars - dep1.jar and dep2.jar. Both dependencies are in a classpath in MANIFEST.MF of main.jar. Each of dependency jars has a directory foo inside with a file bar.txt within:
dep1.jar
|
\--foo/
|
\--bar.txt
dep2.jar
|
\--foo/
|
\--bar.txt
Here is a main class of main.jar:
public class App
{
public static void main( String[] args ) {
ApplicationContext ctx = new StaticApplicationContext();
Resource barResource = ctx.getResource("classpath:foo/bar.txt");
}
}
Which of two bar.txt files will be loaded? Is there a way to specify in a resource URL a jar the file should be loaded from?
Which one you get is undefined. However, you can use
Resource[] barResource = ctx.getResources("classpath*:foo/bar.txt");
to get them both (all). The URL in the Resource will tell you which jar they are in (though I don't recommend you start programming based on that information).
Flip a quarter, that's the one you'll get. Most likely, it will be the one highest alphabetically, so in your case the one inside dep1.jar. The files both have identical classpaths (foo.Bar), and while this should look to throw a compile time exception, it will not because it will just package both jars up and not try to compile/look at the (this specific file) file as it is a .txt file.
You wouldn't expect a compile time exception as resource loading is a run time process.
You can't specify which jar the resource will come from in code, and this is a common issue, particularly when someone bundles something like log4j.properties into a jar file.
What you can do is specify the order of jars in your classpath, and it will pick up the resource from the first one in the list. This is tricky in itself as when you are using something like ivy or maven for classpath dependencies, you are not in control of the ordering in the classpath (in the eclipse plugins at any rate).
The only reliable solution is to call the resources something different, or put them in separate packages.
The specification says that the first class/resource on the class path is taken (AFAIK).
However I would try:
Dep1Class.class.getResource("/foo/bar.txt");
Dep2Class.class.getResource("/foo/bar.txt");
As Class.getResource works cannot take resources from another jar, as opposed to the system class loader.
With a bit of luck, you will not need to play with ClassLoaders and hava a different class loader load dep2.jar.
As #Sotirios said, you can get all resources with the same name using ctx.getResources(...), code such as :
ApplicationContext ctx = new StaticApplicationContext();
Resource[] resources = ctx.getResources("classpath*:/foo/bar.txt");
for (Resource resource : resources) {
System.out.println("resource file: " + resource.getURL());
InputStream is = new FileInputStream(resource.getFile());
if (is == null) {
System.out.println("resource is null");
System.exit(-1);
}
Scanner scanner = new Scanner(is);
while(scanner.hasNextLine()) {
System.out.println(scanner.nextLine());
}
}
I've got the problem that the following code snip returns null:
System.out.println(Logic.class.getResource("effects\\newball.wav"));
I have a source folder in my project called effects. in this folder there's the referred file. I think there's a syntax error... Because THE FILE IS THERE. I must refer in this way (means with getResource) to my file because I will export it as jar later.
Thank you
Your effect directory should be a direct child of the src dir. Also in which case, you need a / to start the string path. So you would need this
System.out.println(Logic.class.getResource("/effects/newball.wav"));
ProjectRoot
src
effect
newball.wav
What I normally do using an IDE is just create a new package and name it whatever I want the file to be - in your case "effect". It's easier that way.
UPDATE
"I did it exatly so, but it still returns null"
It works fine for me
package stackoverflow;
public class Test {
public static void main(String[] args) {
System.out.println(Test.class.getResource("/effects/stack_reverse.png"));
}
}
Output: file:/C:/Android/workspace/StackOverflow/bin/effects/stack_reverse.png
Resource paths should use forward slashes, regardless of the filesystem on the machine you are using: try "effects/newball.wav"
See http://docs.oracle.com/javase/7/docs/technotes/guides/lang/resources.html (Under "resources, Names, and Contexts -- "The name of a resource is independent of the Java implementation; in particular, the path separator is always a slash (/).")
I have created a package:
path : /home/myid/py_ejb
File : XmppMnager.java
package xmpp;
import org.jivesoftware.smack.Chat;
public class XmppManager {
}
Compiled with
javac -d . -classpath .:smack.jar XmppManager.java
File: XmppTest.java
import xmpp.*;
public class XmppTest {
public static void main(String[] args) throws Exception {
String username = "testuser1";
String password = "testuser1pass";
XmppManager xmppManager = new XmppManager("myserver", 5222);
..}
Compiled with
$ javac -classpath .:smack.jar:./xmpp XmppTest.java
XmppTest.java:10: cannot access XmppManager
bad class file: RegularFileObject[./xmpp/XmppManager.class]
class file contains wrong class: xmpp.XmppManager
Please remove or make sure it appears in the correct subdirectory of the classpath.
XmppManager xmppManager = new XmppManager("myserver", 5222);
^
1 error
I tried a lot of way to fix this compilation issue but it just does not go away
Move the source files into a folder named xmpp so that the package names match that of the folder
Package names are directly related to the classpath directory structure. All the classes in the xmpp package need to be in a folder named xmpp, and this folder must be on the classpath. Similarly, if you had a package called xmpp.util.io you would have to put the files in xmpp/util/io/.
The usual convention is to make a src directory to hold all your source files, and then that can be filled with a directory structure that exactly matches your package structure. A pretty decent tutorial on packages can be found here.
Also, it looks like this is probably just a typo in the question, but if your file is actually named XmppMnager.java rather than XmppManager.java, that won't compile either.