We are using NCSO.jar to interact with Lotus Domino. This internally has dependencies on org.omg.CORBA.* .
We are in the process of migrating to JDK 11 and this version of java do not have these required dependencies due to: https://openjdk.java.net/jeps/320
I tried searching a lot, but haven't got any leads on whether there is an updated NCSO.jar that is compliant with JDK 11.
I am aware of adding 3rd party glassfish jars but it will involve a lot of testing in respect to security vulnerabilities and keep track of them as well (earlier that was not the case as Java would do that for us) and this will be an overhead for us.
Looking for some other possible workarounds/ suggestions.
Related
I have a Java application which shows Apache Tomcat Embed as 9.0.35 version. I need to update this to 10.0.4. I'm very new to Java and have very minimal knowledge on it. This upgrade is needed to resolve some vulnerabilities with in the application.
How can I do this from IntelliJ IDE?
Tomcat 9 & 10 are equivalent products
Apache Tomcat 9 and 10 are equivalent products. The only difference is support for changes for the package names in the Jakarta Servlet and related technologies from javax.* to jakarta.*.
This package name change is for legal reasons involved in the transfer of responsibility for Jakarta EE (formerly Java EE) technologies from Oracle Corp to the Eclipse Foundation.
For more info, read Understanding Jakarta EE 9.
To quote the documentation:
Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later. A migration tool is under development to aid this process.
Move to the latest 9 rather than 10
Tomcat 9 and 10 track the same development changes. If your goal is simply to gain some security fixes, as far as I know you'll get the same fixes in both 9 and 10. Do not take my word for this, just study the Tomcat Release Notes.
So for the fastest easiest migration path, just upgrade to the latest 9 instead of 10. The current latest version of 9 is 9.0.44.
Stick with Tomcat 10
Alternatively, if you want to proceed with using Tomcat 10, change the import statements across your code base to use jakarta.* in place of javax.*.
IDEs such as IntelliJ have added features to assist in this migration chore.
And you’ll need to update any third-party libraries using javax.* to new versions using jakarta.*.
Why is it that I can't keep the latest version of Java, that I have to downgrade to Java 8 for almost all Apache Projects?
Is Java not backward compatible?
A program compiled to ByteCode on a older JDK should be run perfectly well on the JVM of a newer JDK.
Why is it that I have to go through the pains of building from source?
I thought this was one of the things that Java was supposed to overcome!
This problem is not exclusive to Apache projects. With the newer Java Versions it's not so much about 'understanding the older code' but more about 'am I allowed to use these features the old way' (modularization).
In some cases the older code also uses features that are just not part of the latest JDK any more (e.g. removal of JEE Modules). I'd recommend to read Oracles Migation Guide for more on this topic.
For (bigger) projects the Migration to >Java8 is something that needs to be planned and organized and takes a lot of time.
Today i received a request to make a plan to update an web application deployed in a tomcat 7 to Java 1.8 and the reason was the web site security.
So i would like to know if is really important to update our web application to java 1.8 and the real problems if we keep our server using java 1.6 deployed in a tomcat 7 ?
best regards
The biggest risk is probably not for your application. The risk from your customer's perspective is that the Java 6 runtime is vulnerable to many things. If your application only supports Java 6, they need to have that on their workstations, which they don't want to, because it makes their workstations vulnerable.
Your app may also be vulnerable if running on Java 6, see the list of updates here for example. It depends whether you are using any API that had a security vulnerability since then. But my guess is your customer is primarily worried about their workstations.
Most java 1.6 code should compile and be fine with version 1.8 of java.
Things what are already marked as deprecated in java 1.6 (or earlier) may have been removed from a later release (1.7 or 1.8). Any of these will be obvious if you just compile your existing code with a java 1.8 compiler.
As mentioned in another answer, security risks of java 1.6 are a good reason to upgrade. Also versions 1.7 and earlier are already officially end-of-lifed by Oracle so only version 1.8 gets public security updates. It is possible to get a subscription to for java 1.7 security updates from Oracle. I'm not sure if there is one available for any other versions of java.
Another concern may be "is there a java 1.8 version of my JEE container."
1.8 has been out for a while so I suspect that the answer is "yes".
Here is the Oracle Compatibility Guide
Last JDK 1.6 and JDK 1.8 update in 2016-07-19. All platform supported now but only Java 8 have public security updates. It's a good reason for update your jre/jdk. Java 8 support most feature of Java 6, you don't have problem with compilation. But some of methods be deprecated.
The conclusion is that we need to use technologies that are supported by
the developer to the full.
I just need clarifications related to JBoss Application Server. I've developed a project which is compiled in Java 6. And it is deployed in Jboss 5 version. Till now I didn't find any problem with the application. But I want to know will there be any possibility that Jboss will have any backward compatibility problem. Or does Jboss needed upgradation with respect to Java version. Any suggestion would be appreciable.
Thanks,
Marshal.
Even if JBoss 5 is compiled with Java 5 there shouldn't be compatibility problems at a language level.
As for the libraries there might be a problem but those that JBoss requires should have been taken care of. This leaves you with core libraries that JBoss might have replaced in its class loader hiearchy and thus might have an older version. In that case you could put those libraries into your application and effectively override the JBoss versions on a per-application basis. We did that with some XML libs (IIRC JAXB was one of them).
As an alternative - as suggested by #Geziefer - use a JBoss 5 version specifically compiled for Java 6.
We are planning to upgrade our Tomcat from 4.1.31.
Our's is an Axis 1.4 application where we have our web services.
Request you to suggest the latest stable version of Tomcat 5 or Tomcat 6 suitable for our application. And the things to consider while upgrading.
Will the existing 1.4 Java code base works smoothly on Tomcat 5 or 6?
And going further we may write the code in JDK 1.5 as well. So, having Java 1.4 code and Java 1.5 code together, will create any problems?
Kindly suggest.
Please share your upgradation experiences.
Thank You :)
Tomcat 6.0.26 is the latest stable release.
It requires JRE 5.0 or later, so if you are truly stuck on 1.4, you'll need to download the latest 5.5 release, which requires a compatability package to run on 1.4.
My advice: bite the bullet and make the necessary changes for your application to function on 1.6. It is only going to get more and more painful to upgrade (and to continue to code in 1.4) as time goes on.
Go to Java (1.)6; it really makes doing web services like yours easier and it's really widely available now.
If you are going to upgrade I would recommend first doing some tests with java 6 + the existing codebases. If that seems to work, go to Tomcat 6.
Perhaps also upgrade some Axis libraries while you're at it, or leave it as is if it still works.
In my experience you can get to trouble by migrating to Java 5 (and thus 6), especially with XML. My memory has something like a class name clash between Java 5 and an old version of Xerces, but I could be mistaken.