I tried a strange experiment.
I created a project in Eclipse. I created Abc.java which has a main method which prints "Hello" to output.
I then built the project using eclipse. A class file named Abc.class was created. I copied that class file to some random location. Then , I navigated to the class file and used the following command to execute it.
java Abc
It printed "Hello" on the console. So far so well. I assume for a simple sysout there are no dependencies a JVM needs to resolve.
Next I created a very complex program in my eclipse for which I had to include 15 different jars(ex slf4j and apache-commons). After building the program in eclipse, I just copied its class files to a different location(not the JARS).
The main method which does all the complex coding was still in Abc.
I hit the command again(this time I followed package structure so I had to call a slightly different command).
java com.great.Abc
I was under the impression that since I hadn't added any jars to classpath in the java command, this code would break down miserably(remember it had a lot of dependencies).
However, its working absolutely fine.
Can someone please explain why?
(Half hour later :|)
Meanwhile I tried another experiment, and this amazes me even more. I mailed all the class files generated through eclipse to a different computer (note that I did not mail the jar files, only the class files generated by eclipse).
And I ran the program over there, hoping that it would break this time.
And guess what, it runs perfectly. Any inputs?
Are the jars required only at compile time?
How would I ensure that the jars I use are needed at runtime while creating a program?
Please explain calmly no matter how stupid the questions seem. :)
In Java, code dependencies are established between classes so when you create a class which just prints a message, your eclipse project setup has no relevance as long as your class is not using any class from the fancy eclipse setup.
Even if your class is referring to other classes it might happen that these classes are not loaded at runtime when the class is not really using them.
Even if you launch a Java program from a jar file which has dependencies to other jar files declared in its manifest, the standard Java launcher will ignore the absence of one or more of these jar files silently and during the program execution it will report failures only if required classes from these missing jar were tried to load.
One case were it is guaranteed that your program will break early is when its superclass is not present at runtime.
The Jar files aside, I actually find it strange enough that it even loaded your Abc class itself, since the JVM would look for com.great.Abc only in a com/great subdirectory of your classpath. I suspect that you, somehow, have some implicit classpath set in your environment or something, which points back to your Eclipse environment, and that the JVM found it there.
To verify this being or not being the case, you can run Java with the -verbose:class option, to make it tell you where it loads classes from:
java -verbose:class com.great.Abc
Eclipse uses the Absolute path to your included jar files.
Even when you move your main class it still works fine
Related
I'm re-using a standalone Swing-based Java class which backs up and restores mysql databases.
I've tested running it from a Windows batch file (.bat) on my dev system, and it works there.
But, if I run the batch file on a different Windows , I get a "main class not found" exception.
However, when I run the command directly on the command line, it works.
The command in the batch file to run it is:
java -cp lda-services.jar;bip-services-1.6.0.0-SNAPSHOT.jar;decryptor-1.6.0.0-SNAPSHOT.jar;slf4j-api-1.7.31.jar;commons-io-2.6.jar com.ilcore.util.SosaMaintenanceJFrame
The SosaMaintenanceJFrame class is contained in the lda-services jar.
Here's the error message:
Error: Could not find or load main class com.ilcore.util.SosaMaintenanceJFrame
Caused by: java.lang.ClassNotFoundException: com.ilcore.util.SosaMaintenanceJFrame
The class is definitely in the jar file, as I've extracted it the file and seen it.
Any thoughts on why this would be happening? I need to run inside a batch file so the user can just click on it to run it.
Most likely explanation
Your paths are relative, which means that the batch file isn't going to work unless you run it from the right place. In general, having a batch file that has an invisible rider stapled to it with: "I break in mysterious ways if not run from the appropriate dir" is a crappy batch file - make it better.
Better solution
Or, even better, get rid of it. You don't need batch files to distribute java programs.
Proper ways to distribute java programs:
The modern take is very very different from what you have here: JREs are dead, you must ship an installer that does the whole thing, notably including a java runtime (no longer called a JRE, and one you ship and keep up to date if relevant). That's perhaps a bridge too far for what you're doing here. Relevant tools include jlink.
A slightly less modern take involves jars with manifests:
Your jar file should contain a manifest. This manifest must contain 2 relevant entries:
Class-Path: lda-services.jar bip-services-1.6.0.0-SNAPSHOT.jar decryptor-1.6.0.0-SNAPSHOT.jar slf4j-api-1.7.31.jar commons-io-2.6.jar
and
Main-Class: com.ilcore.util.SosaMaintenanceJFrame
You can use jar's -m switch, or just include the manifest (it's just a file in the jar): it's at META_INF/MANIFEST.MF and it's a text file, each line is an entry, and an entry consists of a key: value pair.
When a jar contains this, just double clicking the jar and running java -jar thejar.jar will then take care of it all: Java will load the stated jars as part of the classpath, and these, crucially, are resolved as paths relative to the directory the jar is in, so it DOES work when you try to launch them from elsewhere, i.e. if you do:
C:
CD \
java -jar "c:\Program Files\MyApp\myapp.jar"
it works fine, whereas that batch script would fail due to being in the wrong place.
Build systems let you define the manifest too, check your build systems docs for how to do this, it'll be easy, and there are tons of tutorials if you search the web for e.g. 'manifest executable jar maven' or whatnot.
You can consider making a shaded jar. But I wouldn't.
A shaded jar takes all your dependencies and packs them into your main jar, so that there is only one jar. There is now no need for a Class-Path entry (the jar you run is obviously already on the classpath and there's nothing else to include) and your app is shipped as 'just' a single jar file.
But this is mostly a red herring: There are no consumer JREs anymore so you've made the user experience from a D- to a D. If you actually care about giving your users a nice experience, there's no getting around an installation process of some sort and once you have that, having the separate jars is no longer a problem. Separate jars are less hairy when signed jars are involved, are much easier to keep up to date, and have a significantly faster turnaround (when you build your stuff and want to ship what you built, shading takes ages, so it's nice to cut that step out). The faster your CI system tells you about failing tests, the better.
Meet in the middle
You don't have to upgrade to modules and the like. What you can do instead is use something like launch4j. The aim is to end up with a zip file along with the installation instructions: Make a dir somewhere. unzip this zip in it. Doubleclick 'myapp.exe'. Done.
The zip would contain an entire JRE, all your jar file deps, and your main app, and an exe file which launch4j made for you, that launches your app using the JRE packed into the jar. This means you know exactly which JRE is being used, and it'll work even on systems that didn't have one installed yet (which, these days, should be all of them - the notion of 'end user downloads a JRE from oracle and the user + oracle work together to keep that thing up to date and security-issue-free', is dead).
The fact that it's an EXE is nice: Now if the user e.g. alt+tabs through their apps, they get your app, with your name, and your icon, instead of 'javaw.exe' with an ugly coffee mug logo.
But when I try running it from the jar file generated by Maven, however, I get a "class not found" exception.
Even if you didn't get that error, you'd get another one unless you'd used Maven Shade, as that's the only way you're going to run that with a single jar. My guess as to why that particular error occurs is that the app class you're attempting to run is in fact in one of the *SNAPSHOT* jars
I'm grading an assignment in Java. Students are asked to implement a Five-In-A-Row (like Tic-Tac-Toe, or two-player Pente) interface which is used by a GUI .java file. These files (interface and GUI) are given to the students in a file called lab2.jar (where they're in cs251/lab2/ under the names GomokuModel and GomokuGUI, respectively), which the students must add to their classpaths. When the project is finished, students are requested to turn in a .java file called Gomoku.java.
One student turned in a .jar, but the command
java -jar Gomoku.jar
responds with
no main manifest attribute, in Gomoku.jar
I figure the student may have forgotten / not known to make a manifest file. I unzip the student's jar and find only .class files. I try to make my own jar from these files:
According to specs, the main must be in Gomoku.java, whose class is Gomoku.class. So I make a manifest.txt file that looks like
Main-Class: Gomoku
Class-Path: lab2.jar
And try to make a .jar out of it using the command
jar cfm myJar.jar manifest.txt *.class lab2.jar
But when I run this using the command
java -jar myJar.jar
I get the following error:
0Exception in thread "main" java.lang.IllegalAccessError: tried to access method cs251.lab2.GomokuGUI.<init>(Lcs251/lab2/GomokuModel;)V from class Gomoku
at Gomoku.main(Gomoku.java:47)
This particular error is giving me trouble. I've never seen anything like it, and my research on the web doesn't turn up anything. Because the error says it's coming from GomokuGUI, which is one of the lab2.jar files, I think the error's on my end. My questions are:
Can I make an executable .jar when I know and have
What goes in the classpath
Where the main should be
A set of relevant class files
If the answer to (1) is yes: Am I going about it in the right way? I have a feeling I'm missing a recompile step somewhere.
In this particular case, I may ask the student to resubmit. And I will download the .jar's I see submitted before due date to make sure they are runnable. But for knowledge's sake (I myself have made .jar files that have had only .class in them and no manifest), is there a way to salvage a working file like the one described above?
From the JRE javadoc:
public class IllegalAccessError
extends IncompatibleClassChangeError
Thrown if an application attempts to access or modify a field, or to
call a method that it does not have access to.
You're getting
0Exception in thread "main" java.lang.IllegalAccessError: tried to access method
cs251.lab2.GomokuGUI.<init>(Lcs251/lab2/GomokuModel;)V from class Gomoku
at Gomoku.main(Gomoku.java:47)
The method it's complaining about is named <init>. That's what Java calls constructors, internally. It's saying that Gomoku.main() tried to issue new GomokuGUI(model) where model is expected to be an instance of GomokuModel, but that this constructor was not accessible. The fact that Gomoku.main() is in a different package from GomokuGUI means the constructor would have to be public for that to work.
You can check that via reflection -- I believe Eclipse can do that for you, actually -- but that's almost certainly what's going on.
So either the student turned in broken code, or you broke it during your attempts to force-fit it into convenience-executable jarfile format. Which was wasted effort in any case, since you can't grade the assignment based on object code and you're going to have to go back and ask for source code anyway.
If you really want to try running the jarfile the student submitted: Go back to the original unmodified jarfile and try just running 'java Gomoku -classpath myJar.jar' where myJar.jar is what the student turned in. If that doesn't work, try 'java Lcs251.lab2.Gomoku -classpath myJar.jar', which is probably the package they intended to put it into given the error message you're getting. If neither of those runs, ask the student what command line they've been using to run it and try that. If THAT doesn't work, then it's time to investigate why.
The whole executable-jar question is a red herring and a waste of time until you know the code actually runs and what the entry point actually is.
Yesterday i thought one question ,below is the detail:
I have 3 JAR files, a.jar, b.jar ,c.jar . both these jars files have a class named com.test.Test ,and sayHello() was defined in this class.
I create a web application, i reference a.jar,b.jar,c.jar . And in main method, i involve sayHello(); .at this time, which com.test.Test will be load?
the result is a.jar.
any body tell me the reason ?? thanks in advance!!!
That is what java language specification says. It loads what ever the class first occurs in classpath and ignores other.
Instead of focusing on which one will be loaded, realize that the stuff within the JAR files probably need their com.test.Test class instead of someone else's com.test.Test to work properly. That means for a functional system you'll have to make a way that a.jar finds a.jar's com.test.Test instead of the one in b.jar. The same goes for b.jar finding it's classes in preference to a.jar's.
The only way to do this is to use a framework which adds name spacing beyond the java package mechanism. This is typically done with multiple classloaders, often one for each JAR file. You can write such a thing yourself (Tomcat did), where you need to specify the rules for cross-loader discovery, or use something akin to a OSGi framework.
Whichever Jar File comes first in your classpath will be used..
You can modify your CLASSPATH environment variable to the path of your Jar file
Suppose you modify it as below: -
set CLASSPATH = %CLASSPATH%;.;a.jar;b.jar
then a.jar will be used..
You can also modify it by: -
set CLASSPATH = %CLASSPATH%;.;b.jar;a.jar
In this case, b.jar will be used..
These commands you need to run from your Command Line..
** NOTE: - If you are using any IDE, then they don't use System Classpath.. You need to set different classpath for the IDE you are using..
If you are using an IDE, such as eclipse, you can modify your classpath on the properties of the project, then go to Build Path, and then you have the Order and Export tab where you can move up and down the jars. The one of the top will be the first taken by your application.
This you can also do manually by editing the file called "classpath" which is on your project and move to the top the jar you want your application to use first.
How can I get mcc to recognize imports from user-provided Java libraries, or to simply ignore unresolvable imports?
I have a Matlab codebase that I'm building with the Matlab Compiler, but the build is breaking because mcc is erroring out when it encounters import statements for Java classes that were in JARs on Matlab's dynamic classpath. I am including all the JAR files on the classpath with the mcc -a option. The code works in the IDE, and I think it will work in the deployed app, if it will only allow me to build. (Works under R2009b, which ignores these imports in non-MCOS classes.)
Here's a simple repro. This file is in the same dir as guava-11.0.1.jar from Google Guava.
%file hello_world_with_import.m
function hello_world_with_import
import com.google.common.base.Stopwatch;
disp('Hello, world!');
end
Running it in Matlab works fine. But building it fails. (The javaaddpath here is not strictly necessary in the example, because bad imports by themselves are not an error in plain Matlab. Just showing how it works in practice, and how I wish mcc picked up on it.)
>> javaaddpath('guava-11.0.1.jar');
>> hello_world_with_import()
Hello, world!
>> mcc -m -a guava-11.0.1.jar hello_world_with_import
Error: File: C:\Temp\import_test\hello_world_with_import.m Line: 3 Column: 8
Arguments to IMPORT must either end with ".*"
or else specify a fully qualified class name: "com.google.common.base.Stopwatch" fails this test.
Unable to determine function name or input/output argument count for function
in MATLAB file "hello_world_with_import".
Please use MLINT to determine if this file contains errors.
Error using mcc
Error executing mcc, return status = 1 (0x1).
This is in Matlab R2011b on Windows.
Some background on my environment. My app has about 40 JARs on the dynamic classpath which are a mix of third party libraries and our own Java code. It's deployed to 50+ users on a mix of single-user and multi-user Windows machines. And there are other groups that may be deploying other MCR apps to the same users and machines. On any machine, different MCR apps may be run concurrently by the same or different users. We do weekly releases, and (mostly due to changes in our own Java code) at least one JAR file changes about every other release. I need a mechanism that will work in this environment.
Any suggestions? Anybody know a good way to get mcc to add stuff to its java classpath in the compilation step, or just ignore bogus imports? My fallback plan is to go through the codebase and remove all the imports for Java classes, which is kind of a pain.
UPDATE 12/2/2012: I heard from MathWorks that this is fixed in Matlab R2012b. (But I'm no longer using Matlab so can't personally verify it.)
UPDATE 12/09/2014: I'm using Matlab again (R2014b), and the Matlab Compiler now includes JARs that are on the dynamic classpath in the compiled program's dynamic classpath. It doesn't seem to automatically include the JAR files in the archive, though; you must manually include them using an mcc command line switch, or adding them as "additional included files" in the Matlab Compiler app.
The code executing in the MATLAB IDE works because the guava jar file has been added to the "dynamic" classpath via the javaaddpath method. However, when you use MCC to invoke the MATLAB Compiler, it does not rely on the dynamic java classpath, but the "static" java classpath which is defined in:
$MATLABROOT/toolbox/local/classpath.txt
If you add an entry for your JAR file here, then MCC will be able to resolve the IMPORT line in your M-File.
So to test this, I downloaded the guava jar file and tried the steps above. Works like a charm.
Also, If you read the "Troubleshooting" section for the MATLAB Compiler, this exact situation is documented:
http://www.mathworks.com/help/toolbox/compiler/brtm1xm-8.html
Quoting from the link: "The import statement is referencing a Java class () that MATLAB Compiler (if the error occurs at compile time) or the MCR (if the error occurs at run time) cannot find.
To work around this, ensure that the JAR file that contains the Java class is stored in a folder that is on the Java class path. (See matlabroot/toolbox/local/classpath.txt for the class path.) If the error occurs at run time, the classpath is stored in matlabroot/toolbox/local/classpath.txt when running on the development machine."
You just have to put import statements in a separate .m file.
so from:
javaaddpath 'c:\some.jar';
import com.something.Element;
...interesting stuff...
There will be a do_imports.m:
import com.something.Element;
And in original .m:
javaaddpath 'c:\some.jar';
do_imports
...interesting stuff...
And then it will compile and work. No need to mess around with system-wide classpaths.
Here is an extract from the link
http://blogs.mathworks.com/desktop/2009/07/06/calling-java-from-matlab/
MATLAB maintains a path for Java classes separate from the search path. That means even if you have a .class or .jar file on the MATLAB path, unless you use javaaddpath you will not be able to use it. To see what is currently on the path use javaclasspath. Running this command you will show you a long list of files that ship with matlab called the Static Class Path and then you'll see the Dynamic Class Path. The dynamic class path is where classes added to the path with javaaddpath will be placed. They can be removed with javarmpath and have to actively reloaded each session of matlab.
I'm having trouble adding a .jar file I downloaded for my Java project. This is really the first time I've used eclipse, so please bear with me and for some reason (I have no clue why), I just find it somewhat confusing.
I know that in order reference different class files you simply need to create a class library and add it to the build path. From there, all which needs to be done (unless I'm misunderstanding this for whatever reason) is use the "import" keyword to import whatever .jar, .java, or .class/.interface file necessary into the project.
I've tried that with my .jar. I have it referenced in the build path (all I did was just copy the jar to the project directory, and then use the build path option to add it externally), but when ever try to call the object "Delegator", which obviously is a part of the .jar file, it won't read.
Am I missing something here? Seriously, anyone who knows the answer to this - you're relieving a mother of a headache. And before anyone asks - yes, I've searched this one to death. I've found similar questions, but nothing which quite hit what I was looking for. Either that, or I really just lack the common sense.
Right click on project->BuildPath->Libraries->Addexternaljar and then press ok and if it doesnot worked then you should go to the Order and Export tab and checked the jar you have just added in your project. It will solved your problem.
There are several possible reasons, for the question hasn't mentioned the specific failure, and where it has occurred. The following is a list of possible reasons I could think of, but this may not be exhaustive:
You can import a class, in a different package only if the class is public. The only exception is when you are using the class in the same package. If the class is an inner class marked as private, then you're well and truly out of luck. The Delegator class in question might not be public, and that's why you may be unable to use it. This issue ought to be caught by the compiler.
The directory structure within the JAR might not match your package import statements in your classes. This might not be necessary, for Eclipse ought to provide possible fixes, but it is better to verify that nevertheless. Again, the compiler should complain if this is the case.
If the issue is at runtime, then, it is most likely that the JAR is not available in the runtime classpath. You'll need to configure the Runtime configuration, to add the JAR to the runtime classpath. Refer to the Eclipse documentation on run configurations, if you need to know how to change the runtime classpath.
Note:
Exporting the build classpath entries would matter to other projects that depend on the pertinent project; unexported entries will have to be re-imported if required in other projects. This would not apply to a run configuration.
Update
Every Java application needs a main(String[] args] method to start execution. This is the entrypoint for the application. From the comment, it appears that the main method is in a different class. If so, the said class ought to be used to start the application. In Eclipse, a "Run configuration" might be used for the class that lacks this entrypoint, resulting in the described error. One can rectify this by creating a new Run configuration for the class with the said entrypoint. This may be done by one of the following:
editing the existing Run configuration to use the desired Class (the one with the main method). See the above link, in the third bullet point. Edit the value of the class to be launched.
creating a new Run configuration for the desired Class. Usually, you'll need to traverse to the desired class, and run your application (using the Alt+Shift+X+J shortcut) from the said class.
i was facing similar issue with spring jar files but then tried with different jar files and it work so I think , classes defined in jar files were private and not available outside of jar hence you were not able to access the file .
thanks ,
Raju Rathi
Right click on the project--->Build Path--->Configure Build Path...--->In left side you have to choose Java Build Path--->Libraries--->Add External JARs--->ok--->ok
Steps to add jar file in eclipse
1. right click on project
2. click on Bulid Path->configure path
3. click on java Build path
4. Click on libraries tab
5. click on add external jar tab
6. choose jar file
7 click on ok
Copy the .jar file in libs folder which you want to add in your project.
Right click on .jar file -> Add Build Path
Done.