Recently I was assigned to a task wherein I have to upgrade the existing standalone java application from Java 1.6 to Java 1.8.
I'm yet to go through the code and I have no idea about this project.
They were using
ANT 1.6.1,
AXIS 1.5.1,
ABINITIO 2.15,
ORACLE 11.1.0.7,
AUTOSYS R11,
Java 1.6.
I got to know that first I need to identify whether the above mentioned Tools/Frameworks are compatible with Java 1.8.
Please suggest what are the other challenges I might encounter while compiling and building the application?
Although Java is supposed to be backward compatible between versions, it's also known that backward compatibility in any language isn't aways as straight forward as the name suggests. Some (most) projects release it's libs versions compiled specifically targeting one or another development kit, to take advantage of new features and enhancements added to the language.
That being said, I believe the smarter way to go would be: first, update the project's JDK and rebuild it targeting the new bytecode's version. There's a chance you'll have to upgrade both Ant and (if that's your IDE of choice) Eclipse (see here why).
Second, you'll have to check for compilation errors, which will most likely lead you to update libraries conditionally to get them fixed. With those solved, you MUST run your app and see if it's running as intended; remember that compilation problems are just the top of the iceberg when the subject are dependencies.
Carefully check the app's logs looking for exceptions of any kind but mainly the ones related to class loading exceptions such as ClassCastException, ClassNotFoundException, NoClassDefFoundException, UnsatisfiedLinkError and others. If any apear, you'll have to pinpoint one by one and search for the specific solution of the specific troublemaker library.
With all that covered, you should have your app running healthily again.
One last hint, if this project of yours is still being developed, it would be a very good practice to keep the tools you use updated to their very last release. Keep also the development tools updated, like build (such as Ant, Maven, Gradle and others), JDK's and IDE's. It way easier to upgrade the pieces as they are release than to handle a mass scale upgrade :)
Related
Does the version of Eclipse affect the version of code? Suppose, developers are using different version of Eclipse for same version of code with same version of JDK. Will it cause any issue?
No, the version of Eclipse does not matter.
Eclipse has extensive configuration for exactly which version of Java you are targeting. For example see the 'Java > Compiler' settings in the Preferences, and the 'Compiler Settings' in the Properties for a Java project.
You can also tell Eclipse which JRE/JDKs you have installed (see the 'Java > Installed JREs' page in the Preferences). You can run your code using any of these JREs, this is completely separate from the version of Java you are using the run Eclipse itself.
You do need to run a version of Eclipse which understands the version of Java you want to use. So for Java 13 you need to use at lease Eclipse 2019-12.
Of course newer versions of Eclipse contain more tools for helping with Java development and more bug fixes so using an up to date version is recommeneded.
Eclipse is simply an IDE (Integrated development environment). It combines debugging, compiling and other convenient tools for development. on the other hand, the Java code itself is separate, and you don't necessarily need eclipse to write the code. In fact, a simple text editor is enough. All you need is a file with a java extension (Example: hello.java).
It depends on what users share. I'm assuming you're using some sort of SCM, in which case the same project (fully shared) on different versions of the IDE can possibly lead to annoying situations.
There would be no issues in general, as far as producing the code is concerned, except in situations where some versions of IDEs don't support the required Java version (or other features). But I see this more as the user being affected rather than the project/code.
Here's what you should keep in mind:
Keep IDE project configuration files (such as .project, .settings, .classpath) ignored by your SCM system
All Java configuration should be based on a build tool. Use Maven/Gradle, etc, and any modern IDE will be able to create a project from its config file. The IDE would derive local configuration files which should not be sent back to shared repositories
This way, all developers are free to use whatever IDE (and whatever version) without causing interference, and CI tools will work off build tools' configuration as well.
I have java EE artifacts like .jar , .war, .ear files compiled and running in java 1.6 version. i wanted to run them (.ear file [.jar + .war]) in latest java versions like java 1.8.
Which Option would be the best considering moving to new java version.
1) Recompile Code in 1.8 and deploy to Application server
- to be at a little safer.
2) Just deploy to java 1.8
- No Code Compilation required (means .ear file generated using java 1.6). .ear file can be safely deployed to latest java 1.8 version
- probably we wont end-up having runtime issues ?
As this this is a production code base and no developer. Hence No Code changes in either cases, the only change is java version. I prefer going with Option-1, as compilation in higher version of exiting java classes to avoid any runtime issues.
Any thoughts ! or other useful options in this regard.
Thanks
As #Stultuske mentioned you only telling no code changes possible in either cases then your first case not valid one only.
But anyway as per java(Oracle) compatibility specification Java 8 is backward compatible with previous versions for sure no doubt about this except some very rare cases where binary incompatibilities happened.
For more information about this you can refer below stack overflow link --
Can newer JRE versions run Java programs compiled with older JDK versions?
Recently I did a similar thing but we updated the code/dependencies if needed.
I will suggest recompiling the code base first because this will tell you quickly if it or any dependencies don't support the newer Java version. If compilation is successful, then deploy to test environment and do sanity, regression, etc.
I hope you aren't talking about deploying to Production environment directly :)
I have an application which I would like to deploy, compiled for java 1.8.0_151. However, the user has only 1.8.0_25. User cannot launch the app because LocalDateStringConverter is missing.
As written here (https://docs.oracle.com/javase/8/javafx/api/javafx/util/converter/LocalDateStringConverter.html) this class has been added only in 8u40
How can I compile (is it possible?) a jar with dependencies for the specific java version of the user?
Or maybe I misunderstood something, new to java here
EDIT I tried specify the pricise version with update number in my pom.xml but it didn't help
There are a two ways to approach this:
You have to set your environment to use the JDK that is expected by the user. In this case 1.8.0_25 - you need to develop all logic using this JDK and the classes available in it. If LocalDateStringConverter is your only dependency missing, you can easily find out the source code and duplicate the logic inside your project as utility class and use that instead.
You can ask/help/advise your user to upgrade their environment to more recent JDK version (security reasons and such). As you are aware most software has minimum requirements to run and it's expected from the end user to meet those requirements in order to run the software.
As already mentioned you can use the Maven Enforcer Plugin to enforce specific java version, but this will not make the functionality from 1.8.0_151 available in 1.8.0_25.
Compiling your code with 1.8.0_25 and hoping that the newer versions are backward compatible is probably the easiest solution. Assuming you have automated tests this will catch problems like a missing class.
The other option would be to build an executable bundle containing both your application and the entire JRE 1.8.0_40 or newer. This is going to result in your software bundle growing by dozens of MBs so I would not recommend it. However one way to do it would be to use Launch4j as advised here.
You can try implementing your own LocalDateStringConverter but how many other classes are you missing? What if there are other subtleties in behaviour between versions? Based on java.com 1.8.0_25 was released on October 14, 2014 while 1.8.0_151 on October 17, 2017. That's 3 years of Java development that your user is missing.
I use Eclipse Indigo for java development but I want to experiment with scala. Since I have to download a nightly build to run on Eclipse : http://scala-ide.org/download/nightly.html is this safe ?
Is there a chance the plugin can corrupt my eclipse installation since the plugin is not a full blown release as yet ?
I run the latest Scala milestone with no problems right now, which is probably safer than the nightly, and has better highlighting features. If you do run into trouble you can always revert to a previous installation state in Eclipse, so I would consider it safe
The plugins architecture is designed so that Eclipse is protected from instability, unless they maliciously delete files on your installation, I doubt they would break Eclipse permanently. To be extra careful you can make a backup of your eclipse directory.
Nighly builds gives developers a chance to use latest features (not certified to be working on all environments) of the plugin which are not yet made available to end users. In general they work fine but there may be few undiscovered issues. You can always rollback your installation if something goes wrong or if you find any bugs.
If your aim is to learn or develop using scala, better to use stable build. A stable scala-ide plugin is available for Eclipse Indigo. Please visit 'http://scala-ide.org/download/current.html' for more details.
I am trying to recompile an existing Java project exported from Eclipse. It is necessary to recompile this because I am running simulations remotely on other machines where a different (older) version of Java is installed. I have tried recompiling my .java file which specifies the simulation in question. However, it appears that it is necessary to recompile all other classes etc as well. Has anyone got an idea how to do this WITHOUT using Eclipse (I am not the Admin on the other machines and thus Eclipse is unavailable to me) and not manually because the project is quite huge?
Thanks a lot for any suggestions!
I recommend you to always have an command line way to build an application. The usual way to do this in Java is using ANT (or Maven).
As #Santiago Lezica says, Eclipse can generate an Ant file.
I believe that Eclipse allows you to build for an older target platform than the one you are currently running. That way you can do all of your builds locally.
The second approach has the advantage that you can fix any problems arising from compiling for the older platforms (e.g. use of new language features, use of new classes / methods) from the comfort of your own ... workstation.
There is another option that you should consider: Tell Eclipse to generate code for the old Java version (see the compiler options). That way, you can create code that runs on Java 1.3, even if Eclipse uses Java 5.
Not sure what your requirements are, but you could set the compiler level for your projects at the (older) level of your Linux installs. This would cause Eclipse to recompile it at that version, instead of a newer version.
At my company we use IBM's Rational Application Developer (instead of pure Eclipse), but I am assuming the option is in the same spot. If you right-click on your project, you can go to the Java Compiler options and then set the compatibility to the level of that on Linux (1.3, 1.4, etc.).
Since compile Java byte-code is supposed to be portable (for the most part), this should get you past most of your problems.
Otherwise, the other option is to use something like Ant or Maven scripts (which can be kicked off by Eclipse) and then just use a property to set the compiler right before you run it. This way you don't have to switch properties on your projects all the time, if you truly do need "newer" compiled code and can't live with "older" code on both systems.