I have a jar file that cannot be modified, but I want to use a different .class file in place of one of the members of the jar. How can I tell Java to use the external .class file when the code within the jar attempts to load it?
You could compile another jar file with replacement classes with exactly the same name and put it ahead of the jar file in the class path. For example, this is what the various slf4j bridge jars do to replace calls to log4j or Jakarta Commons Logging in library code with cognate slf4j code; one need not maintain two sets of logging systems and configurations that way.
If you want to override a java... class, you can use some of the command line options to change the boot class path. Look at the -Xbootclasspath options in http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html. Heed the warnings.
There is also the lib/endorsed directory if you need to upgrade a third-party jar that Sun uses. Oracle uses other organizations' XML and CORBA libraries; if they release a new version and you need to adopt it, you can.
You can use AspectJ to instrument the code and possibly replace it. An around advice can call the original code if it wants.
You could see if you really need to replace the original code. Some systems provide customization hooks.
You need to make sure the external .class file is loaded first. If a class is already loaded by the class loader then it will not be reloaded. If you are using an application server, then there are ways to configure the preferences for loading classes for class loader. But if you are using a standalone application then you may need to extend the class loader to load the files in the order you want to.
Related
I have a runnable java jar file that I need somehow to run (pass params, fetch output) from another java class I'm working on. How do I do that? Do I import it as a package somehow, call it on runtime? Can I invoke "main" method from it or do I just run it with "exec"? Thanks for your answers.
Simply add it to your CLASSPATH and call either the main() method or any other public method which it provides (and which is documented). There is no difference between "normal" and "runnable" jar files, besides an entry in the manifest.
One subtle detail you might need to consider is that runnable jar files are usually self-contained - that is, they contain all required classes, including classes from third party libraries. If you are using the same third party libraries in your project, make sure that there are no conflicts, e.g. by removing the separate third party jar files from your project.
See Lesson: Packaging Programs in JAR Files for more information.
Import it in your code if you need something, that you can not achieve from command line exec solution. Note, you can get problems, if you trying to use some methods from jar file itself, and author changes it later.
Consider Bridge pattern, to put some abstraction layer between jar file and your code, If you not sure, that you use public API.
If jar file is library with stable API, you can be more confident, while using it in your project.
Besides, importing jar file and use methods from it is faster, than parsing process output.
u can import it to your project and then call the publicly exposed methods in that jar from within your application.
I've created a project that dynamically writes, compiles and instantiates a new java class at runtime and it works just fine when I run this on the command line or within eclipse. Ultimately my goal is to create a technology very similar to JSP; the user provides a "template" file and I translate it into a java class and instantiate that class. My problem is that I can't seem to instantiate the newly compiled class when in the context of a web application.
The core of my problem is that I don't know where to put my compiled classes so that I can immediately instantiate them.
Here are my goals:
This will be a generic tool for other developers so it can't be specific to my filesystem or my java container.
If the user undeploys their webapp from the container it should also remove these generated classfiles.
Here are my thoughts but I have never done anything like this before:
Do I put these generated classes into one of the existing entries of the classpath, if so which one? Should I let the user provide a path and then my library will add this path onto the classpath? Maybe they provide a path and I just use a custom class loader to read them from that path? The user already provides the path of their "templates" (ex. WEB-INF/templates) so should I put my compiled classes with the original templates? My understanding is that translated JSP files are stored in a proprietary place specific to that java container and therefore I can not follow in the footsteps of JSP files.
Ahh! I'm overwhelmed! Maybe there's an open source java library that does something similar and I can study it to determine where it puts it's generated files??
Basically you will need to define your own classloader and do the loading from there.
See How do you change the CLASSPATH within Java?
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.
What is the simplest way to manage dependencies of Java classes to data files present in the classpath?
More specifically:
How should data dependencies be annotated? Perhaps using Java annotations (e.g., #Data)? Or rather some build entries in a build script or a properties file? Is there build tool that integrates and evaluates such information (Ant, Scons, ...)? Do you have examples?
Consider the following scenario:
A few lines of Ant create a Jar from my sources that includes everything found on the classpath. Then jarjar is used to remove all .class files that are not necessary to execute, say, class Foo. The problem is that all the data files that class Bar depends upon are still there in the Jar. The ideal deployment script, however, would recognize that the data files on which only class Bar depends can be removed while data files on which class Foo depends must be retained.
Any hints?
This is one of the many problems Maven has already solved with it's build, dependency, and resource management. Any maven project follows a standard directory layout which dictates where you should put your Data files: in the 'resources' directories. The conventional Maven directory structure is as follows...
/
/src/
/src/main/java/
/src/main/java/App.java
/src/main/resources/
/src/main/resources/my.prod.data.or.cfg.or.whatever
/src/test/java/
/src/test/java/AppTest.java
/src/test/resources/
/src/test/resources/my.test.data.or.cfg.or.whatever
/pom.xml
The benefit of this is that all files which are contained in the 'main' (prod) resources directories are available to your application at run-time from the Classpath. All of the 'test/resources' files are available to your code during build & unit test time but are NOT included in your final artifact.
I don't think a generic solution exists for the system you describe, however, I just had a stab at reading annotations on classes using ASM, since that is used by jarjar as well. It is not hard to read the annotation data that way (pass in a ClassVisitor to the accept() method on ClassReader, and do something useful on the visitAnnotation callback). This means you can either try and include your intended behavior to jarjar or you could add it as a custom step to your build process.
Can't you refactor your project so that you have submodules that each contain the relevant files for the project itself ; Bar class and Bar related files will be packaged in their bundle while Foo ones will packed into another?
Another possibility would be to use some package naming convention to be able to filter the files you want to see i your bundles.
I am developing a framework that needs a lot of stuff to get working. I have several folders inside of my Eclipse project that are needed
[root]
- config
- src
- lib
- serialized
Also there are important files like the log4j.properties and the META-INF dir inside the src directory.
I wonder if there is a way to distribute one JAR containing all essential files so my gui will just have to import one jar. I guess that I have to exclude the config folder in order to make the framework configurable.
I also wonder, if there is a way to move for example the log4j.properties to the config dir so that I have one config folder containg all needed configurations?
Thanks for help and advise on this matter!
Marco
Yes, but not really. You can take all your dependencies, unpack them and simply merge them into a bigger jar. This is what the maven jar plugin does if you make a jar with dependencies. The only problem is that this might result in conflicting files (suppose two of your dependencies contain a log4j.properties). This is one of the problems when doing the above with some of the spring libraries for instance.
I think someone actually wrote a classloader that allows you to bundle the whole jar inside of your jar and use it as is. I'm not sure how mature that is though and can't at the moment recall the name.
I think you're better off distributing all your dependencies separately. Setting up the classpath is a bit of a pain but surely java programmers are used to it by now. You can add dependencies to the Class-Path header in your manifest file, in simple cases. Bigger libraries have to rely on the classpath being set up for them though.
As to the second part of your question, probably dropping the conf/ directory under META-INF is enough for its contents to be picked up. I'm not sure about this. I'm fairly sure it will always be picked up if you put its contents at the top level of the jar. In any case, this is a distribution problem. You can easily have a conf/ directory inside your source tree and have your build scripts (whatever you might be using) copy the files in it to wherever is most convenient.
As to your users configuring. Try to establish some conventions so they have to configure as little as possible. For things that must be configured, it's best to have a basic default configuration and then allow the user to override and add options through his/her own configuration file.
In terms of the resources, it is possible except that if you do that you are not going to be able to load resources (non class files) from the filesystem (via a file path).
It's likely that you're currently loading these resources from the file system. Once in the jar you need to load them as class path resources via the class.getResourceAsStream or similar.
As for the dependent jars you may have, it's common practice for these to be placed as extra jars on the classpath. I know it's complicates things but developers are used to doing this. The nature of the java landscape is that this is inevitable. What the spring framework for example does is supply a bundled zip file with the core jar and the jar dependencies included.
Is your library going to be used in an EE context or an SE context? If it is an EE context then you really don't have to worry about configuration and class path issues as the container takes care of that. In an SE context it is a lot more tricky as that work has to be done manually.