Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I know that similar questions have already been answered, but I have a specific question for which it would be great if someone can throw some light.
I am trying to migrate a couple of applications (desktop apps using Swing) to Java version 8. Currently the version used for compiling as well as running) is 6.
There are a large number of third party APIs (which are no longer supported) used by these two apps which are compiled using JDK 5.
I plan to compile the applications using JDK 8 but to avoid any more complications (and rework) want to keep the 3rd party APIs as it is (compiled on version 5) even though I do have the whole source code of the APIs.
Do you think it is a good idea and what are the points I need to be careful about.
Edit :
To precise my qustion here - considering the behaviorial and source incompatiblities between Java 5 and Java 8, is it possible and probable in practical terms that an API compiled with version 5 works perfectly fine with JRE 8, but wen I try to recompile it with JDK 8, it fails with compilation errors?
Thanks in advance
Generally old code runs without problems on newer JVM.
There are very few exceptions that need to be considered.
They are listed in the java 8 compatibility guide.
Each incompatibility is listed with a number.
As an example removeAll in the class Collection has a different behaviour if you pass a null parameter in java 8:
RFE 7131459
Area: Core Libs / java.util.collections Synopsis In previous
releases, some implementations of Collection.removeAll(Collection) and
retainAll(Collection) would silently ignore a null parameter if the
collection itself was empty. As of this release, collections will
consistently throw a NullPointerException if null is provided as a
parameter.
Nature of Incompatibility behavioral
If your code has a complete set of unit test, you can run them using JRE of java 8 and check that none of them fails. If the coverage of unit test is complete you are quite sure that there will be no problem upgrading to java 8.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I'm using intellij for Java development, and when I run the application, it shows an error message saying "Warning: The jjs tool is planned to be removed from a future JDK release jjs>", then it gets stuck at the line and none of my System.out.println print anything at all. I'm not sure what to do with it.
In the short term, you don't need to do anything. This is just a warning. Your code will keep running until you upgrade to a Java release that removes the Nashorn Javascript interpreter.
The deprecation is in accordance with JEP 335. A Java release for Nashorn removal is not proposed in the JEP, and it hasn't been removed yet as of Java 13.
UPDATE - Nashorn was actually removed in Java 15+ (source Wikipedia).
In the long term, you will probably need to find a different Javascript interpreter for your application to use. You could suppress the warnings for now (for example: Disable warning in IntelliJ for one line), but if you do that there is a risk that you will forget that you did it, and then get a nasty shock when you upgrade to the (future) release.
If Intellij itself is using jjs, then the Intellij developers will need to address this.
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I bumped into JEP 12 searching for JDK 12 and was intrigued.
Summary: A preview language or VM feature is a new feature of the Java
SE Platform that is fully specified, fully implemented, and yet
impermanent. It is available in a JDK feature release to provoke
developer feedback based on real world use; this may lead to it
becoming permanent in a future Java SE Platform.
Following the responses to this question, I wish to ask only the following:
Can you provide a usage example of this JEP- incorporation of new language and/or VM features in code?
Does this mean that usage of new features will now be as simple as downloading a support jar and 'plugging' it into our projects?
No. This is about enabling "preview" features in the Java language and the JVM, so that a feature can gain wider exposure and feedback (with suitable opt-ins) before being finalized. (If you could just enable an experimental / preview feature by dropping in a JAR file, this mechanism wouldn't be necessary ...)
In fact, with the "preview" mechanism as described in the JEP:
any code supporting a preview feature would already part of the JRE / JDK, and
the features would be enabled by providing extra command line options to the javac and java commands.
Can anyone share any usage experiences of this JEP? Actual code?
Compiler and VM support for preview features will be supported starting in Java 11, and we will likely see the first preview features in Java 12. Looking at the early access build release notes, they don't explicitly mention any "preview" features. Yet.
It is too soon for "experiences". (And I'm not sure what they would tell you. The JEP-12 mechanism is the mechanism for enabling the features ... not the features themselves.)
I also looked into the JIRA issue related to this JEP, it seems that this feature is currently completed but unresolved.
The issue is an "umbrella" issue (if that is the correct term). Drill down to the list of related issues, and you will see that two of them are still unresolved. However three related issues are resolved, so it looks like JEP-12 support will make it into Java 11.
UPDATE: 2019/08/22 - There is now just one relatively small issue about improving javac compiler messages.
This question already has answers here:
It is a bad practice to use Sun's proprietary Java classes?
(7 answers)
Closed 8 years ago.
I'm actually developing a Java applet to access an HSM in order to sign data.
So I'm using a lot of Sun packages (PKCS11 wrapper and sunPKCS11 provider).
I saw that link : http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html that tells us it is discouraged to use sun packages.
But I want to make sure why. I'm actually compiling my code in Java 1.6 x86 JDK.
Is it possible that end-users won't be able to use my application when updating their version of Java ?
Or will the problem appear only if I change my JDK to compile my code ?
Or is it both situations ?
Thanks in advance for your clarifications.
It's stated pretty clearly in the documentation your linked :
A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
So end-users might not be able to use your app if they're not using the same JDK as you.
And yes, in the future you might have problems too with a newer version of your JDK.
The main problem is that those packages/classes might not exist in other JDKs or versions of the same JDK. You might get problems compiling your code on another JDK but it's mainly the users which you should think about: if their runtime lacks the classes that are needed they eventually try to run some code that isn't available and depending on how you structured your application the result might range from functionality simply being unavailable to a crash of the application.
Note that this might also be the case if you're hosting the application, i.e. when it is a web application. We ran into the same problem with some of the imaging classes which prevented us from upgrading the Java version on our servers without having to change the application as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I wrote a program in Java 6.0, but it turns out that some of our client only have 5.0.
The issues is that lot of features that 6.0 has was not in 5.0 yet. For example:
JTable Sorting, Filtering feature
SwingWorker class
My Question is :
is it legal to just copy the java 6.0 source code to my own project so that my client with 5.0 jre can run it.
from technical point of view, is it hard to copy the classes source code like TableRowSorter, regexFilter to my own project and let it work?
Thanks
Probably no, the OpenJDK classes are under GPL meaning you will have to put your sources under GPL too. The Oracle Java classes are also under a "you cannot just do what you want to with our sources", so this is most likely a VERY bad idea.
You can use Retroweaver to make your source work with an earlier version of Java, but I would say that you should make your code work with Java 5, optionally using Java 6 facilities if available, and then say to your customers which things they will get from upgrading.
2021 edit: As of Java 17 the proper solution would be to include a tested JVM as part of your deployment. There is tooling for bringing just what you need.
One question you should ask is: why haven't your clients upgraded to Java 6.0? Since it's free and easy to do they must have a reason, and you should probably find out what it is before sending them code from it.
That depends on the source code you are copying from. From JavaSE? OpenJDK?
Wherever you want to copy from, check their license for the code.
The copying may be simple, copying just the classes and it’s dependencies. There may be a lot of specific dependencies though, which can make it consume a lot of time. And you’ll really have a problem when you have to copy a changed class that already existed in version 5, where you would need one version for some code, and the newer for the other. But if you’re only using Java6 code in that project it should be alright. Moving the classes into another package may also be an option, with potentially a lot of work as well though.