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.
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.
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.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I want to measure API evolution for a given Java project, in particular new/renamed classes, new methods, newly deprecated methods, etc. Is there a tool that detect such changes?
Back in 2007, a Google GSoc project was initiated, however, I cannot find the final work.
I'd use Clirr for that, a binary compatibility checker. From the Clirr web site:
What is it?
Clirr is a tool that checks Java
libraries for binary and source
compatibility with older releases.
Basically you give it two sets of jar
files and Clirr dumps out a list of
changes in the public api. The Clirr
Ant task can be configured to break
the build if it detects incompatible
api changes. In a continuous
integration process Clirr can
automatically prevent accidental
introduction of binary or source
compatibility problems.
...
Features
Report all API changes (currently only partially implemented)
Evaluate each change wrt. binary and source compatibility
support plain text and XML reports
Flexible failure handling (warnings vs. errors, break the build or set
error property)
There's also a new API evolution checking tool called Revapi
Btw there seems to be an api-checker in the gwt source code, don't know if that is the product of the mentioned GSoc project.
GwtJavaApiCompatibilityChecker is also used in build.xml
Try japi-compliance-checker tool. It's open-source. The tool shows API changes and detects both backward source (SC) and backward binary (BC) compatibility issues between two jar archives:
japi-compliance-checker -old LIB-0.jar -new LIB-1.jar
Sample reports for log4j: http://abi-laboratory.pro/java/tracker/timeline/log4j/
You can find classification of found compatibility problems by severity level in the reports for particular library versions:
JDiff is maybe also worth a mentioning.
JDiff is a Javadoc doclet which
generates an HTML report of all the
packages, classes, constructors,
methods, and fields which have been
removed, added or changed in any way,
including their documentation, when
two APIs are compared. This is very
useful for describing exactly what has
changed between two releases of a
product. Only the API (Application
Programming Interface) of each version
is compared. It does not compare what
the source code does when executed.
As I understood it runs on the sourcefolder of the old version and generates an xml file. The same for the sourcefolder with the new version. Than the two xml-outputs are compared and a changelist compiled. In html-javadoc-api-style
You might also want to try japicmp.