We are stuck with Java2SE v1.4 till the end of 2010. That's really nasty, but we can't help it. What options do we have to use some of the new features already now? I can think of several ways like
changing the bytecode, e.g. using Retrotranslator or Retroweaver.
backport of libraries, e.g. Concurrent Backport, but this does not help for generics.
emulation of Java 5 features, e.g. checked Collections, Varargs with helper methods, etc.
changing source code by precompilation, stripping all 1.5 stuff before final compilation, e.g. using Declawer can do this.
I am most interested in very positive experience with it in production environments using Weblogic and "real" stuff.
Thanks for your answers. Here is the summary of all relevant answers and my own research.
Changing the bytecode: The Retros
This is done by the "retro"-tools: Retrotranslator, Retroweaver and JBossRetro. Retrotranslator seems to be the most mature
and active of them tool. These tools scan all classes and change the bytecode to remove Java 5 and 6 features. Many Java5 features are supported, some
by using 3rd party backport libraries. This option is most popular and there is some positive feedback from users. Experiments showed that it's working as
expected. See a short overview on developerworks.
Pro: You can develop entirely in Java 5, build modules and all kind of JARs. In the end you just transform all classes to Java 1.4 and package your EAR.
This is easily done with Retrotranslator's Maven integration (org.codehaus.mojo:retrotranslator-maven-plugin).
Con: Conservative environments do not allow changed bytecode to be deployed. The result of the retro-step is not visible to any coder and can't be approved.
The second problem is fear: There might be some cryptic production problem and the retro-code is another step that might be blamed for that. App-server vendors
might refuse help due to changed bytecode. So nobody wants to take responsibility to use it in production. As this is rather a policital than a technical
problem, so I see no solution. It has happened to us, so I was looking for further options :-(
Compiling Java5 to Java 1.4: jsr14
There is an unsupported option, javac -source 1.5 and -target jsr14 which compiles the Java5 source to valid Java 1.4 bytecode. Most features like
varargs or extended for loop are translated by the compiler anyway. Generics and annotations are stripped. Enums are not supported and I don't know
about autoboxing, as the valueOf methods were mostly introduced in Java5.
Con: Only byte code is translated, library usage is not changed. So you have to be careful not to use Java5 specific APIs (but could use Backports).
Further you have to build all modules at the same time, because for development time you propably want Java5 code with generic and annotation information.
So you have to build the entire project from scratch for Java 1.4 production.
Changing Source back to Java 1.4: Declawer
As answered in a related question, there is Declawer, a compiler extension, that works for generics and varargs, but not for enhanced for loop or
autoboxing. The generated source "is a little funky, but not too bad".
Pro: The generated source is available and can be reviewed. In worst case fixes can be made in this source. There is no "magic", because the source
is valid Java. Some people even use JAD (Java decompiler) to get the Java 1.4 source again. The output of Jad readable is readable if you compile with debug
information and don't use inner classes.
Con: Similar to -target jsr14, you need an extra step in the deployment. Same problems with libraries, too.
Changing Source back to Java 1.4: by hand
Several answers suggested doing it by hand. For an automatic, repeating build process this is of course not useful, but for one-time changes it's
reasonable. Just automate what is possible. Maybe look at Antlr for creating a home-grown conversion tool.
Backported Libraries:
The problem is, that Java5 also ships new libraries, that are not available in older JREs, see related question. Fortunately there are several
backported libraries that give you some functionality of Java5, but can't simulate language features, like generics.
Annotations, discussed at TSS
Concurrent
com.sun.net.httpserver (Java 6 to 5)
Gif writing (Java 6 to 5)
Start your own backport project ;-)
You might copy classes you need from the JDK or other libraries, but most likely they are related to other classes.
Emulating Java5 features in Java 1.4 code:
I was thinking about some things you might do to make your life easier and still staying with Java 1.4. The most important features are typesafe collections,
here are some ideas:
Instead of using generics you can create your own typesafe containers with some template.
Add a typesafe Iterator (which is no Iterator any more).
Add asList methods that allows 1,2,...,n arguments and an array of them (to simulate varargs).
Methods for varargs (converting 1,...,n arguments to arrays) and valueOf can be put in some helper class.
sourcecode precompilation, stripping
all 1.5 stuff before final compilation
and deployment. Are there any tools
which can do this?
Yes. They're called Retrotranslator or Retroweaver. Apart from Generics (which only exist for the compiler's sake anyway), you cannot simply "strip 1.5 stuff". Enums (and maybe also some other features) have to be replaced with functionally equivalent code. Which is exactly what those tools do.
You can code with JDK 1.5 features and target JDK 1.4 at compile time. See available Javac options. However, most libraries are now using JDK 1.5 code, so you'll be stuck with old libs.
It worth noting that while Java 1.4 has been EOL for some time. Java 5.0 will be EOL Oct 8th, 2009. If anyone is promising you Java 5.0 by 2010, I would ask why?!
To simulate annotations in java 1.4 you can use http://xdoclet.sourceforge.net/xdoclet/index.html
Related
We have an old project using gwt 2.6 and therefore we need to compile with -source 1.7 option.
The JRE and JDK used are 1.8, but compile with 1.7 source code option.
We want to use the new compute function from ConcurrentHashMap which is only available from java 8. When using eclipse and maven everything compiled well. On the other hand IntelliJ is complaining. My question is, will it work or will we have issues with it?
Will this project run?
Searching in google for ConcurrentHashmap compute, java 8 and source code level 1.7 did not give any info.
If at all, this would require a lot of careful "manual" work.
When you look at this question for example, you can find that there are various different ideas how people want to enable "stream based" functional programming with Java 7. Maybe, after doing a lot of research, you might be able to find similar things regarding such "enhanced collection" features.
But then, all of that might be quite fragile. The fact that some examples might work fine wouldn't mean that you would be able to run a large production code base on a Java 7 VM.
Thus more of a non-answer here: be careful how to invest your time and energy. Instead of trying to backport libraries to Java 7, rather look into moving your whole project onto Java8 at least. Especially keeping in mind that the release cadence for Java has changed significantly, and going with outdated Java versions for many years is simply even less desirable compared to a few years ago.
Well, the simple answer is that it will not work. The target runtime will not have the updated API (i.e., the compute*** methods won't be on the version of Map that Java 7 has).
So if you deploy that code, the runtime will understand the class version, but will raise NoSuchMethodError and similar errors.
In addition to this, there are many reasons for upgrading your runtime.
What is the best way to migrate Java code of an older jdk (1.5) to a more recent Java version (1.8) to provide from its new features and improvements.
We have a large Java jdk 5 code base and want to migrate to jdk 8.
There are a lot of compiler warnings and hints (e.g. diamond operator, multicatch, unnecessary (un)boxing, etc) which will improve the performance, code readability, etc.
We are using Netbeans IDE. Are there any plugins which we can use or are there migration scripts?
The likelihood of your code being incompatible with Java 8 is slim, since Java has taken great strides to ensure backwards compatibility with all previous versions.
The issues that you'll likely run into lie much deeper, likely in implementations of collections or methods who have changed over the years.
If you don't have a test suite that covers the critical paths of your code, start there. You'll need that test suite to ensure that the migration hasn't horribly broken anything.
Next, peruse the compatibility guides for Java 1.7 and Java 1.8 and be sure that nothing that you're using in particular is impacted by those changes.
Lastly, the code cleanup piece can be tackled, but it shouldn't be addressed right now. The only thing you need to concern yourself with is to get the platform running on the new version of Java. As you work in the code base, discipline yourself and the team to use the newer Java idioms, such as the diamond notation, and try-with-resources where applicable.
Unfortunately, there are no magical ways to achieve what you are asking, but here are a few pointers that can make it easier for you to migrate the code to JDK 1.7 (note that JDK 1.8 has been out for some time now, and 1.7 is already out of support officially by Oracle):
Use checkstyle or a similar plugin in Eclipse to find the problems
Build your project with JDK compiler level 1.7 in Eclipse; warnings given by Eclipse are much more user friendly than the warnings printed on console by command line compiler
In theory, JDK 1.7 is backwards compatible with 1.5. The only exceptions are assert and enum keywords. If you used these words as user defined type/method names, you'll get a compilation error. So for most part, you can get right down to warnings. If push comes to shove, you can choose to ignore many of these warnings (of course, only if you must)
Found what I was looking for: Netbeans offers Inspect and Transform.
This can be used to transform your complete code base (or parts of it) with a configuration of changes.
This is how it works:
select your project
click Refactor menu
click Inspect and Transform menu item
select configuration and configure it using the Manage button
choose your desired transformations (e.g. Can Use Diamond, Join catch sections using multicatch, unnecessary boxing, etc.)
click Inspect
Review proposed refactoring suggestions and click Do Refactoring
Your complete code base is refactored and uses your selected new features and new idioms.
IntelliJ IDEA has a similar feature. See Analyze > Inspect Code ...
In Eclipse this is called clean up in code style (configuration) or source (menu).
I have two Java artifacts being built. One needs to be built in 1.6, because PowerMock isn't compatible w/ 1.7 and we are using it in a lot of unit tests. Refactoring PowerMock out right now isn't an option as it will take too much time.
However, I want to use this artifact in a Java application built in 1.7 and run the whole thing in 1.7. I think that it should be Ok since it is just building some class files, which I doubt changed much if any probably as far back as 1.2 or earlier. Anyway, I obviously have a fuzzy understanding of this and I am interested to get a Java experts deep dive explanation as to when this would matter, when it wouldn't, and why.
Thanks!
Java is usually backwards compatible between versions so anything compiled on an old version should run fine on a newer JVM. In fact a lot of common libraries are compiled in as old a version as possible (usually Java 5 now a days) unless they need a newer feature to allow more people who are still stuck on old JVMs.
Having said that, there are a few gotchas you need to worry about. One problem I had on some Java 6 to 7 conversion was TreeMap with an initial value of null http://hariharanselvarajan-java.blogspot.com/2013/02/treemap-in-java-6-and-java-7.html
EDIT
Here is a link to Oracle discussing what isn't compatible between 6 and 7 although I would imagine this only affects things that are recompiled: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
The compiled code should be backwards compatible, so if you run it all on java7 it shouldn't matter than some was compiled using java6.
When you try the other way you get an invalid major/minor version number error.
I would assume that you can mix & match java 6 and 7 code too, just as you can (with caution) mix and match pre & post generics java.
My old projects use Java 6 (1.6), and I don't know when I update (Java 7), they can run fine ?
There is an official list of known incompatibilities between java 6 and java 7 from Oracle (including descriptions of both binary and source-level incompatibilities in public APIs).
Also you can look at the independent analysis of API changes in the Java API Tracker project: http://abi-laboratory.pro/java/tracker/timeline/jre/
The report is generated by the japi-compliance-checker tool.
They should do, yes. Java has a reasonably strong history of backward compatibility. However, if these are in any way important projects you should still perform a thorough test pass before deploying anywhere production-like.
There shouldn't be any compatibility differences as the JVM is basically the same. However it is early days so there may be subtle differences which cause a problem which people are not yet aware of.
e.g. Eclipse looks at the Supplier in the java.exe on Windows and sets the command line arguments differently for different suppliers. It has a problem with Java 6 update 22 because Oracle wanted to change it from "Sun" to "Oracle". I believe this has been changed so it is "Oracle" in Java 7 (but still "Sun" for Java 6)
My point being, that if you write generic Java code, you shouldn't have a problem. However, if you are doing something a bit unusual, you are likely to need to re-test your application.
As was already stated backward compatibility is a very important aspect in new Java releases, so in general there should be no problems in switching to a newer Java version. In this case, however, Java 7 seems to have a few bugs in the new hotspot compiler optimizations. The Apache Software Foundation has issued a warning that their products Lucene and Solr are affected by these bugs.
http://lucene.apache.org/#28+July+2011+-+WARNING%3A+Index+corruption+and+crashes+in+Apache+Lucene+Core+%2F+Apache+Solr+with+Java+7
The affected loop optimizations can be switched off by starting java with -XX:-UseLoopPredicate.
AFAIS here, there's no Java 6 features which get deprecated in Java 7 so yes, your project should run fine.
Is there any solution through which I can convert java'a higher application, created in netbeans IDE 6.5.1, into lower version of java version 5.
If you have the source code, which I assume you do, this might be easy or difficult depending on the code.
Java 6 made few language changes over Java 5. The only one that springs to mind is you can put #Override on implementations of an interface.
The bigger issue is whether you use any of the API differences, of which there are several. I think JDBC has some major differences, which you may or may not use.
These issues may be big or small. It's really hard to say without knowing anything about your app. Generally speaking though they should be small.
Otherwise you should mostly just be able to recompile it with a Java 5 compiler.
If you don't have the source code it's still doable but you just need to disassemble it first and fixing any issues may be tedious.
You can simply try to recompile it for Java 5. As no language-changes are made between version 5 and 6 you can only run into problems, if you use APIs added or enhanced with the version-upgrade.
If you have the source, you could use backported libraries and code rewrite. There is a tool called Retroweaver which can convert 1.5 code to 1.4, but I doubt It works for 6 to 5.
there is an option somewhere to tell Netbeans to generate GUI with non-Java 6 classes. It is documented somewhere, sorry I don't remember. I've already switched to Netbeans 6.7 (RC3).
Check also usages of Desktop API, #Override in implementing interface methods, etc.
It is a good practice to build with a JDK5 in a CI server (like hudson).