I've got a relatively large Java application that would benefit from a bit of Python love. To that end I've been working on getting it up and running in Jython. My current roadblock is getting the classpath right.
I've taken two approaches to setting the classpath:
Using a shell script, I've built up a list of jars and executed java -cp ${CP} -jar jyton.jar where $CP is a list of the jars needed for my app. This doesn't seem to work. I'm unable to import any classes from these jars, getting only ImportError: No module named apache instead.
Using a bootstrap python script, i've created a list of paths using glob, and appended them to the current path using [sys.path.append(path) for path in JAR_LIST]. This seems to work correctly; I can now import any of the classes I need to from the included jars.
The above is a bit confusing as most information I've been able to find has steered towards using $CLASSPATH and -cp to added your jars, but I can't get that to work. So the question so far: Is #2 the proper way to add dependancies to your classpath when using Jython?
The main reason I question my methods is because I'm still having problems fully utilizing my application. A number of places in my app reverences resources using relative URLs : classpath:some-critical-file.xml
some-critical-file.xml and a number of my classes reside within the same jar. I'm able to import classes from that jar, but any attempts to load my xml with classpath:some-critical-file.xml results in a java.io.FileNotFoundException
Any insight as to why my classes are available but relative paths to resources using classpath: are not would be much appreciate. I'm at a loss at this point.
I've run into a little classpath weirdness myself lately. Have you tried the old school approach of:
CLASSPATH = ${CLASSPATH}:your.jar
export CLASSPATH
jython your_script.jy
If you're invoking the standalone jar using java -jar then from the Java Documentation ...
-jar
When you use this option, the JAR file is the source of all user classes, and other user class path settings are ignored.
So it it not possible to add anything to the classpath when using -jar. See this answer for a solution - basically add the jython.jar to the classpath (either using -cp or CLASSPATH) and run the org.python.util.jython class directly.
Related
Hi I'm building a program using optaplanner, and everything seems to be imported and working fine, but when I run and debug the code, I get a ClassNotFoundException "org.optaplanner.core.impl.solver.DefaultSolver". I believe I've imported all the jar files correctly, but just to be sure, what jar file is the DefaultSolver class in?
As a follow up, I keep getting prompted to edit the source lookup path. This happens after running SolverConfig.buildSolver() line 156: "DefaultSolver solver = new DefaultSolver();" I'm running OptaPlanner 6.1.0.Final.
Found the problem, I realized that I had both imported the examples jar file into my buildpath and at one point imported a class from the examples jar file when I was messing around with the examples. Rereading the manual I saw it explicitly said not to import the examples jar file, so I unimported that and found the culprit pretty fast. Thanks for your help.
Both the class SolverConfig and the class DefaultSolver are in the jar optaplanner-core-*.jar.
So this doesn't make sense: if the jar is in the classpath, it should find DefaultSolver. If the jar is not in the classpath, it shouldn't even find SolverConfig. What you're seeing can never happen in a normal classpath.
Are you using anything like OSGi, JBoss modules, jigsaw, Karaff or other classloading magic?
I am designing a tool, that takes an sbt project path as a parameter. I would like to be able to build that given project on the fly, and be able to get its classpath.
I previously designed my tool as a sbt plugin to achieve this but it is not flexible enough for my purpose: I don't want to have to parameter anything in the sbt config files of the project I am studying.
I would like to use sbt externally, construct a project (from a sbt directory path) and compile it externally in my scala code without invoking sbt in a console. This is a reproduction in code of what happens when "sbt" is typed in a given directory in the console. Is there a straightforward way to achieve this?
I think you need to look at SBT jar file and source code. Find the "Main" class and call it programmatically. The code is here: https://github.com/sbt/sbt. The main class is: xsbt.boot.Boot. I got it from sbt jar file by unzipping it and looking at META-INF/MANIFEST.MF. So you can see how SBT passes command line arguments to it and take it from there. Here is the Boot class just in case: https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/Boot.scala. Have fun! :)
p.s. in your code just call Boot.main(<your sbt commands>).
I have a vaguely similar requirement. I produce a command-line tool as one of the deliverables from my project. The script launches the Scala runtime itself and naturally needs the effective class-path for the project's dependencies. To get that in an external form, I use the SBT-Start-Script plug-in. While that plug-in does produce an actual launcher, I need to do more than it provides, so I just use it to externalize the project's (current) class-path, which I extract into a shell array initialization in a separate source file that may be source-ed by the main launcher script.
So I'm relatively new to Java EE and I am having a tough time understanding when, where and why Java deployment files are packaged with their dependencies.
Say I build my project into myapp.jar, and it depends on fizz.jar, buzz.jar and JODA (joda-time-2.0.jar).
I've heard that the default classloader doesn't package jars inside of other jars, so I have to assume that if I called a jar task from Ant, then the default classloader would get invoked and myapp.jar would be created without those 3 dependencies in it.
Is this because the mentality is to deploy main-less jars in containers or other systems that will provide its requirements at runtime? If not, then how does myapp.jar ever run correctly?
What about executable jars? To met, these must be different than main-less jars, because they are meant to be standalone units, right? That means they would need all of their dependencies packaged with them, right?
Last but not least, what about jars that depend on jars that depend on jars...etc. (i.e., dependencygraphs that are huge)?
I guess all of these questions can be summed up as follows:
Is the idea behind a non-executable jar that it will be ran in such a way that it will know what classpath(s) to look on for its dependencies at runtime? (And thus doesn't need to be packaged with its dependencies)?
Is the idea behind an executable jar that it is a standalone unit and should be pacakged with its dependencies?
If my assertion to Question #1 above is correct, how does such classpath configuration take place? Are these settings that are stored inside the jar (such as in the manifest)? Else, how would a JRE know where to search for a particular jars dependencies at runtime?
Answers to these questions will actually clarify quite a lot of hangups I have with Java fundamentals, and so any input/help here will be appreciated enormously! Thanks
Jars do not know about other jars (unless assisted by some tools like Maven). The inter dependency of the jars is purely resolved by the Classloaders. I strongly recommend to have some idea about classloaders.
To address your questions,
Is the idea behind a non-executable jar that it will be ran in such a way that it will know what classpath(s) to look on for its dependencies at runtime? (And thus doesn't need to be packaged with its dependencies)?
NO. As mentioned, it's the classloader which looks the classpath and the jars mentioned therein. The jars do not have any information about other jars.
Is the idea behind an executable jar that it is a standalone unit and should be packaged with its dependencies?
NO. A classloader loads the standalone executable jars at the start of execution. If it needs other dependency jars it'll look into the classpath for those jars.
If my assertion to Question #1 above is correct, how does such classpath configuration take place? Are these settings that are stored inside the jar (such as in the manifest)? Else, how would a JRE know where to search for a particular jars dependencies at runtime?
For standalone jar (executable jar), the classloader looks for the classpath variable OR classpath passed while invoking the application.
For other type of application (WAR, EAR), There are predefined places/folders where the dependencies should be placed in order to get picked up. This is standardized by specs.
In a nutshell, it's the classloader which is pulling all the threads. There is standard places where it looks for all the dependent jars. This link nicely describes how the classloaders in standalone application and in a deployed (in some container) works.
JAR files are a way to package togher complex java application. Jar application are easy to move between diffrent machines and operating system.
I think the right way to use Jars is not tu put everything (every dependencies) into a single jar.
For example if your application uses a jar libryra (for example jdbc) to access a database you should not put the jdbc jar into your jar.
You had better to build a jar file with only your .class file.
Of course your code needs the jdbc jar to work properly. Here comes to explain how the virtual machine searches for extarnal classes:
-it first searches in the directories that contain the classes that come standard with J2SE (the path depends on your installation)
-it searches in the directories specified by the classpath (a classpath is either an environment variable or an option of the java command)
for example:
java -jar -c /your/path/ yourApp.jar
will run your application and will search th classes your application refers to in the directory /your/path/ so if you have external jars you can put them in that directory.
For detailed documentation: http://download.oracle.com/javase/tutorial/deployment/jar/index.html
I'm trying to package a small application (still learning Scala!) in a "clean way". The goal is to have an executable JAR file. I've done the following:
packaged a JAR using sbt -> will work with
scala -cp myjarfile.jar MyClass
or
java -classpath path\to\scala-library.jar;myjarfile.jar MyClass
but won't work with
java -jar myjarfile.jar
because then scala/ScalaObject cannot be found. And no use adding a classpath on this last one, since the -jar option will ignore the -classpath option. Note that I have added the scala libs in my system CLASSPATH variable, but it seems to be ignored too when -jar is used.
added the scala library contents (by unzipping them first) to the jar created by sbt. This then works (the jar can be double-clicked and launched), but the manipulation is somewhat lengthy, and the resulting file is several megabytes big. Not ideal.
After hours of googling, I can see no way to create a small jar file that will launch when double-clicked and that doesn't involve a painful manipulation. What am I missing? I'm guessing there should be some way to define where the scala libraries are at system level. How do you deal with small applications that you want to be compiled and ready-to-run for efficiency?
Note that while I'm using sbt, I don't have a jar tool at hand (I'm relying on a JRE, not a JDK).
Thanks!
Pierric.
The following setup works for me:
have scala-library.jar in the same folder as the executable jar (and call java from there)
put this into your manifest:
Class-Path: scala-library.jar
Another option is to merge the contents of scala-library.jar into your application jar. The drawback is that this will increase its size. But you can use Proguard to strip unused classes from your final jar. I think there is an easy way of using sbt to package an executable jar using proguard.
Regarding the shrinking using Proguard, you can have a look at this page. It's about Android development; just ignore this part and have a look at the tables of the shrinking results. Some example applications shrink to less than 100kB.
Edit
Maybe you need to refine your question a bit. What are you trying to achieve? Do you want to install the program only on your system or do you want to distribute it?
If all you want is quickly launching a Java application without much impact of the JVM start-up time you can have a look at nailgun.
I have two java files. They run fine in NetBeans, but I have to compile them in javac, and run them on a unix machine since I'm connecting to a database on my school's server.
I've been searching online but everything is too specific, and I'm not too familiar with NetBeans.
What I'm doing is copying those two java files, and a .form file to a directory on my school's server, and then try to compile the two java files using javac. However, I'm assuming that it doesn't compile because it's missing all the information from the .form file?
I'm getting 100 errors when compiling the one of the java files, and they look something like this:
CARTSJFrame.java:380: package org.jdesktop.layout does not exist
.add(jPanel9, org.jdesktop.layout.GroupLayout.PREFERRED_ SIZE, org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLay
My guess was that it has something to do with the .form file that I can see in my NetBeans project directory.
I've looked at previous questions about this but still haven't been able to figure this out. Any help is appreciated.
You are running into compilation errors because NetBeans includes a jar in your project's classpath automagically when you compile and run the project.
NetBeans uses the dot-form file to help it generate code for the layout. It is not used at compilation time.
There are a couple strategies that you can follow to resolve this problem:
Get the jar that has the classes...
http://www.findjar.com/jar/net.java.dev.swing-layout/jars/swing-layout-1.0.1.jar.html;jsessionid=252692AC0FBE9421C9436A748744ACED... and include that jar in your
classpath at compile and runtime.
Convert the code in your project to
use the javax.swing.GroupLayout.
This is a 'standard part' of Java SE 6. This SO answer covers how to convert between
org.jdesktop.layout.GroupLayout and
javax.swing.GroupLayout in
NetBeans.
I think your problem is that javac doesn't know where to find that library.
A typical Java project uses many libraries. Netbeans uses a folder "lib" to store those libraries and also some configuration files to automatically set the classpath. The classpath is a environment variable that Javac uses to 'know' where are the libraries.
When you use javac to compile the java files you need to provide the CLASSPATH variable first. Write all you dependencies.
An example:
Project/compile_all.sh
export CLASSPATH=$CLASSPATH:"lib/jopt-simple-3.2.jar":"lib/commons-io-2.0.jar"
javac src/*.java
Now you just need to run
sh compile_all.sh
And it compiles all you .java files