I'm using NetBeans 7.2 as IDE, Java 7 and I have a lot of issues with different versions of a library.
Let's call the library in question as Lib (JAR file).
I have to realize a project A in Java, that uses package B and package C. Now B has dependency on Lib_v1.jar and C has dependency on Lib_v2.jar. Lib_v1 and Lib_v2 are 2 version of the same library and they aren't compatible, nevertheless they have a lot of class in common, so it is possible that a class can be loaded from a different version of the
library.
How can I manage this issue?
Unfortunately there is no real way to solve this problem. Even if you put both JAR files into the classpath one will get picked up by preference to the other.
If the library versions are not backwards compatible and the people who made the change didn't change package or something then you are pretty much out of luck.
isn't lib_v2 backwards compatible ? So you could use only lib_v2.jar ?
I saw a googlecode project(jar jar) which seems to solve your problem, have a look: https://code.google.com/p/jarjar/
Related
I need to add some jars from JRE7 library to my Android project. But for example rt.jar is in conflict with android.jar from Adroid 2.2 SDK, so I get this error:
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
I know there have been several threads about it and things like JarJar, OneJar or FatJar might be good for me. But I don't know how to make any of them work and documentation doesn't really make it clear (for me). I guess they use Ant commands, but I have always used Eclipse built-in builder and now I have no idea how to use neither Ant nor any of mentioned above.
So my question is: how can I repack this rt.jar so I could compile it in my Android project?
Thank you!
EDIT:
Ok, so what I want to achieve is to create a .jar, which can be used during developing Android application (simplifies some functionalities, doesn't really matter). But I would also like to be able to add the very same .jar to standard Java project in order to use some functions there as well. It would look like this:
Whoever writes an application adds this .jar to his Java project -> it enables him to generate certain files (internet is needed to do it) -> these generated files are then added to Android project -> later on, when somebody uses this Android app, these files provide certain functionalities without using internet (off-line).
It would be ill-advised to do this in any project at all, even if it were possible. You would be opening yourself to a wealth of class incompatibility and loading problems. But in any case it doesn't even matter because the core Java libraries are loaded way before your archives are even touched, making any such attempt at overriding them moot.
Not to even talk about the fact that Android is using its own JVM implementation which is not fully compatible with JDK 6 (forget JDK 7). Also note that it may be a copyright violation to package the core Java libraries with your code and could change your licensing options (IANAL).
You need to find another way to resolve whatever issue you are having (which you failed to mention in your question).
There are many JARs that work nicely on both Android and on classic Java. None involve having Android developers pirate rt.jar. Stick to java.* and javax.* classes that exist in both the Android SDK and in whatever level of Java you are supporting, and your JAR will work fine in both environments.
You should ideally refrain from using such .jar files, but if you must, you can add them to build path. But this, at times results in a conflict, like the one that you are facing right now. What you need to do to resolve this kind of a conflict, is:
add the jar in the build path.
Check "referenced libraries". The jar file should appear under the same.
once it features under referenced libraries, check the "android dependencies" virtual directory. If you get to see that you have an instance of the same jar file there as well, you should delete the "android dependencies" folder altogether. (Trust me, this does not affect your project in any way).
having done that, you should be able to compile your code without any further conflicts.
Happy coding.. :)
In my project, I'm using both glassfish-embedded 3.1.1 and the guava lib... The problem is that glassfish comes with the old implementation of guava (ie google-collections)...
This results in NoSuchMethodError at runtime, for example when using Lists.reverse(), or Sets.newIdentityHashSet() which were introduced later in guava.
I don't find any solution to solve this... (the only one is to manually trash the com/google classes directory in the glassfish jar...)
You can overcome this be specifying the below. Read the Delegation section of the Class Loaders chapter.
<class-loader delegate="false" />
Check this SO post for class loading in Java EE apps in general: Java EE class loading standard
Glassfish should never have included com.google classes in their own jar. That was an error.
UPDATE[#sly7_7]: It seems like glassfish does not include guava in their own jar anymore, but it depends on the guava artifact instead. This should resolve the problem.
Thanks to #JagWire for pointing this.
I was able to make the error go away by using the following Glassfish v4 build:
http://grepcode.com/snapshot/maven.java.net/content/groups/promoted/org.glassfish.main.extras/glassfish-embedded-all/4.0.1-b01
Might be worth taking a look.
I found a java code and want to use it in my project. It contains these imports that my JDK does not have :
import com.sun.awt.AWTUtilities;
import com.sun.jna.Native;
import com.sun.jna.platform.WindowUtils;
I referred to sun site and found this download page :
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Is it necessary to download all JDK and JRE and replace it from SUN website? My JDK is version 6 and is up to date.
Thank you all
JNA is an additional library and not part of the standard api, you have to download it (here) and include it in your classpath.
The AWTUtilities class is only distributed with the sun jvm as an implementation detail of the api and as such subject to change, this can break any program depending on it (if possible don't use it).
WindowUtils can be found in the platform.jar, you it can find it on the same page as jna.
Your JDK should have com.sun.awt.AWTUtilities. It is in rt.jar.
Maybe the problem (for that file) is that your IDE excludes the parent the build path ... on the grounds that it is a bad idea to use those classes directly.
The com.sun.jna classes are not in rt.jar. They apparently may be found in a jna.jar, though I haven't yet found a good place to download it from. (If you use Maven, try this.)
You should not use any com.sun packages except as a last resort. These are considered to be implementation details, and they are not part of the JDK API. They can change arbitrarily between versions, so they can cause problems when you try to upgrade JDK versions.
The com.sun classes are almost always wrapped by "official" classes - you should use those instead. You can use these in a last resort situation, but they are already part of the JDK download, so there should be no extra downloading necessary.
EDIT: Looks like you're right, you do need to download some extra jars. The JNA jar is available on maven central (http://mvnrepository.com/artifact/com.sun.jna/jna/3.0.9). Especially if this is a code snippet you found, I would highly advise against using com.sun packages directly.
This is a common problem. I'm using 2 libraries A.jar and B.jar and these depend on different versions of the same jar.
Let's say that at runtime I need THIS.x.x.x.jar
MY.jar
-> A.jar -> THIS.1.0.0.jar
-> B.jar -> C.jar -> THIS.5.0.0.jar
I can compile the specific jar (A.jar/B.jar) against its dependency but at runtime I've to load only 1 version. Which one?
Loading only 1 dependency (the latest version) means that my code will probably throw runtime exceptions if the libraries are not Backward Compatible (are there Backward Compatible libraries out there?).
Anyway I know that something like OSGi can fix this issue.
I'm wondering what's the old way to fix this kind of problems...
Thanks a lot
"Old way" you mentioned (and the one OSGI certainly uses under the hood) is to install your own ClassLoader for both branches of your dependencies. That's how, for instance, application servers are able to run both older and newer versions of the same application inside the same JVM.
Read about classloader hierarchy.
In your setup, the tricky part is the joint point, where classes from both branches meet. Neither branches can use classes loaded into another one. The way to make it work is to make sure only classes loaded by boot classloader (JRE classes) or classloader of MY.jar are passed down to both branches.
OSGi can fix this problem. An OSGi bundle is nothing more than a jar with additional metadata detailing versions. A bundle has a version number, and will detail version numbers (or ranges) of dependent jars.
Take a look at this introductory Javaworld article for more information.
To solve this without OSGi means having to ensure manually that you compile and run with compatible jars. As you've discovered that's not necessarily a trivial task. Since jars don't necessarily identify their versions, the only sure way to do this to record/compare checksums or signatures.
Many libraries are backward compatible. But not all..
The old way is to try to depend from only one version.
It is probably safer to compile both with the same version (latest).
At least you get compile-time errors, instead of runtime errors.
If needed, you can modify a little bit your library that works with the old dependency...
This would require access to the source...
Please note that compile-time compatibility will not guarantee correct runtime behavior either. It is one step, then you can:
read the WhatsNew file for the new version of the jar
look on the Internet for users reporting compatibility problems
write JUnits
compare the codes in both jars
As mentioned by KLE, the default approach is to depend on the newer version. There is no guarantee, but most of the time this works. Probably the best way (while being a bloated one) is using OSGI to get over it.
To refer a basic "oldway" implementation checkout https://github.com/atulsm/ElasticsearchClassLoader
This provides an approach to handle non-backward compatible versions of elasticsearch client usage.
I have a 3rd party JAR file that is compiled using Java 1.4. Is there a tool that can make the jar file compatible with Java 1.6? (Something like 'retrotranslator' but what does the reverse of it).
I tried decompiling the class files and re compile them in 1.6 but it fails.
Here is the issue:
My project uses 'rsadapter.jar' for was 5.1 and I had my project setup in Eclipse 2.0 + JDK 1.4 and it used to work fine. Now, I have migrated to Java 1.6 and Eclipse Ganymede (as per the requirements) and the same project (exactly same setup) started complaining about the missing class files in the 'rsadapter.jar'. I put the JAR in classpath explicitly too but it still could not load the classes. Then I changed the Java Compiler version to 1.4 and it started working.
Regards,
- Ashish
Classes compiled by JDK 1.4 should be usable in a Java 6 runtime as-is. If you have actually encountered a problem, please describe it.
Update: I can only reproduce this with types in the "default" package (that is, not in a package). Are the classes you are trying to use in the default package? Also, this happens to me regardless of the JDK version used to compile.
Update: Okay, after a little research, I realized that you can never reference a type in the unnamed package from a named package. Makes sense, but definitely not what you are running into.
I can compile code under JDK 1.4.2_19 and utilize it just fine in a Java 6 Eclipse project. I think that this problem is something specific to your environment. In this situation, I would backup Eclipse and recreate everything (JDK installation, workspace, projects) from scratch, to see if I could clear it up.
I had another issue with some legacy code written in Java 1.4.x: the authors loved enumerations and loved to name the corresponding variables 'enum'. They even used it for package names. And this prevents from compiling the code under Java 1.5 (or higher) quite successfully.
Changing that automatically is quite an issue.
May be you have defined Eclipse to throw compiler errors on use of deprecated methods or classes?