If I have a java class and:
- I compile the class and include it in a jar, A
- compile separately the same class and include it in a different jar, B
(I know it's not politically right to do this...etc)
(the compilation is done against the same jdk, on the same machine)
If I put these two jars in the same war - can I get class loading problems?
Two ways to get into trouble:
Have two externally different classes by the same name, such that other classes that are compiled against one will not be valid referencing the second.
Have two identical copies of the class (or even the same copy) and manage (through one of several means) to load it twice with two different class loaders.
But having the same (from an external attributes standpoint) class twice in your classpath is not a problem -- the first one in the JAR search order will always be loaded.
No. You'll simply get the first copy it finds. If they're in the same package, you'll effectively never see that other class.
And it's not "politically" wrong to do this. It's fundamentally a bug.
Related
I have two jar files with similar Util class names, but different method signatures.
In jar1, I have a main method which must use the method in Util class in jar1. The JVM is linking to Util class in jar2.
How to resolve this class conflict?
If both jar files are loaded into the same classloader then there is no way to determine which class will get loaded. The only way to handle this is to isolate them so only one of them is loaded into the classloader you are using.
You can set up a classloader and only load the jar you want to get the class from, but it is probably much easier to just make sure classes are unique on your path.
Normally one avoids that situation by using appropriate package names, such that they are different.
In extreme situations, where you dont have the choice to change the jar files,
there is the option "bootclasspath" where you can specify classes that gets loaded first.
I'm having troubles compiling a mixture of clojure and java files into a single package. The files have dependencies between each other and if they were all just java files the java compiler could handle all of this. Just to make this concrete I want to create a package called pkg with 4 files, A.java, b.clj, c.clj, and D.java. A.java contains main and creates an object declared in b.clj, b.clj calls functions in c.clj and uses objects of class D. How do I write the project file?
If I use
:prep-tasks ["javac" "compile"]
in the project file then I get a complaint while compiling A.java that something in pkg.b or pkg.c is undefined. If I use
:prep-tasks ["compile" "javac"]
I get a complaint that class pkg.D does not exist. If I try
:prep-tasks [["javac" "pkg/D.java"] "compile" "javac"]
it can't find pkg/D.java, even though I set java-source-paths correctly.
One way to handle this would be to create 3 packages, one that contains A.java, one that contains b.clj and c.clj, and one that contains D.java. Then build a jar for D.java, a jar for b and c, that uses D.jar, and a jar for A that uses bc.jar and D.jar. Ugly, though.
You cannot have circular dependencies between the java and clojure sources in a single lein project. As you correctly point out, you could split the project in more than one package to avoid the circular dependency, but you don't need 3 packages but just 2, as lein supports Clojure -> Java dependencies. So you could have a project with b, c and D and another one with just A.
Another option would be just to write A in Clojure so you avoid the burden of multiple projects.
Recently have been touched Java classloaders and suddenly recognized that do not fully understand what happens step-by-step when someone calls
java -jar App.jar
Well I guess
a new instance of JVM is created
it uses ClassLoader to load main class and other classes
byte-code is started to execute from main() method
But still I suppose there are many things I need to know more about it.
Who and how decides which classes should be loaded at startup and which once needed?
I have found two related questions but there it is not explained how to apply that to Java realities.
What happens when a computer program runs?
What happens when you run a program?
•Who and how decides which classes should be loaded at startup and which once needed?
we need to understand the fundamentals of java class loading. Initially bootstrap classloader (it is implemented natively as part of the VM itself) is responsible for loading core system classes. Then there are other class loaders as well like Extension, system, user-defined(optional) class loaders which decide when and how classes should be loaded.
Fundamentals of class loading
The decision is made by the classloader. There are different implementations, some of which pre-load all classes they can and some only loading classes as they are needed.
A class only needs to be loaded when it is accessed from the program code for the first time; this access may be the instantiation of an object from that class or access to one of its static members. Usually, the default classloader will lazily load classes when they are needed.
Some classes cannot be relied on to be pre-loaded in any case however: Classes accessed via Class.forName(...) may not be determined until this code is actually exectued.
Among other options, for simple experiments, you can use static initializer code to have a look at the actual time and order in which classes are actually loaded; this code will be executed when the class is loaded for the first time; example:
class SomeClass {
static {
System.out.println("Class SomeClass was initialized.");
}
public SomeClass() {
...
}
...
}
Your example shows an executable jar, which is simply a normal java archive (jar) with an extra key/value pair in it's manifest file (located in folder "META_INF"). The key is "Main-Class" and the value the fully qualified classname of that class whose "main" method will be executed, if you "run" the jar just like in your example.
A jar is a zip file and you can have a look inside with every zip archive tool.
Whenever you compile a Java program the following steps takes place
First the Class Loader loads the class into the JVM.
After giving the command javac filename.java the compiler checks for compile time errors and if everything is fine then it will generate the .Class files(byte code).
This will be the first phase.
Later the interpreter checks for the runtime errors and if everything is fine without exceptions then the interpreter converts the byte code to executable code.
First phase in java is done by the JIT compiler(Just In Time).
Java class files inside jars can be easily replaced and modified. For instance, the following command can be used to replace a compiled class file within a jar:
jar uf JarFile.jar com\something\Class.class
If the class file was replaced with a file such that no dependencies were broken, then the code is still able to execute. The same happens with class files that are not inside jars.
Is there any way to validate a set of class files (whether inside a jar or not) to see if all their dependencies are present and not broken?
I do not want to prevent class files from being modified but rather to be able to verify that changes are valid (with respect to dependencies). The compiler does this check (dependency-check) at compile time, but once the classes are compiled, how can one verify the class files themselves?
You might have sealing and signing JARs in mind.
Update:
Apparently I've missed the mark with my first guess.
What do you plan to do if they're not? If they're a 3rd party, I'd say that you've got little choice besides reporting to the bug database that the download is bad.
If you mean "I want to make sure that all their 3rd party JAR dependencies are correct", you've got a much bigger problem. Most downloads that I know of (e.g. Spring) make dependencies available using Maven. That's the best you can do.
If you mean you want to check your own dependencies, I'd say that testing would reveal any errors you've made.
Just loading the class will ensure that.
no, you cannot.
at least: not really.
the problem is that java loads classes at runtime only when needed. so eventually it might be alright to remove a class from the jar file and as long as no code referencing that class is executed things run very smoothly.
consider this example:
class A{ public static void main( String args[] ){ out.println( "hello" ); } }
class B{}
compile this, put it in a jar, remove the B.class from it, no problem there :)
now you might think you can go through each .class file, check what classes it references and see if the files are all there. not only is this painful, it is also incomplete. you will never quite catch files loaded with reflection because their class names might be constructed just at runtime.
my advice: don't go there. if someone removes a class file it's their own fault.
the best thing you can do is (but only if this really really worries you) try to catch ClassNotFoundExceptions at runtime (look into thread.setUncaughtExceptionHandler)
I am new to Java and might be asking a basic question which might sound silly to some.
After I compile my Main Java class most of the subclasses are displayed as $ in the folder. I copy the complied classes and put it on another location to execute. Everytime I make make a change to the main class or one of the sub classes do I need to copy all the associated subclasses? or just copying the changed ones will do?
Thanks.
Nick
Copying the changes will do.
Normally, you would let your IDE (e.g., Netbeans) / build system (e.g., Ant / Maven) do this for you. Alternatively you could create an executable jar-file, leaving you with only one file to copy.
Classnames containing $ are for nested/anonymous classes.
And see this Stackoverflow question.
But that's not the whole point. Quoting OP I copy the complied classes and put it on another location to execute. -- looks like you should automate this task and employ one of traditional Java build tools such as Ant or Maven.
Nick,
Are you referring to nested classes? If so, they will contain "$" in the compiled class file names. Assuming your code changes were only to the parent class, the nested class bytecode should not have changed during the recompilation. It should work to only copy the main .class file. However, it's obviously more of a guarantee to copy the everything.
Is this about subclassing (class Y extends X {}), or nested classes (class Y { class X {} })?
The $ that you mention seems to indicate the latter, in which case you should probably copy everything, but if you are only subclassing then just copying the compiled versions of the files you have changed is probably just fine.