I'm currently leaning HTTP/2 Client in Java9~10 through this.
Java 9 does have HttpRequest.BodyProcessor interface while Java 10 does not have HttpRequest.BodyProcessor, but instead it does have HttpRequest.BodyPublisher. Both interfaces are similar.
Why are Java change Interface's name? I think backward compatibility ignored.
The HttpClient has been a part of an incubator module with Java 9 and 10. So what one saw there was more of a prototyped work which though ideally shouldn't change much, yet doesn't guarantee the same.
From the incubator JEP#Incubator Modules:
An incubating feature is an API of non-trivial size that is under
development for eventual inclusion in the Java SE Platform, or the
JDK, but is not yet sufficiently proven.
If you wish to use the standard module you can make use of it in Java 11, where it is named as java.net.http. [notice that its marked as since Java 11 and not 9 or 10]
The jdk.incubator.httpclient module not found in Java11 could help you migrate the usage of HttpClient in Java 11 if you were already using that in Java9/10.
Slightly Off-topic: If you could compare the source code in the two JDK, you would find that there have been updates to the methods in the BodyPublisher as compared to its previous state, both in Java 10 as well as Java 11.
Related
I have a program for work that I'm told will only use Java version 8 update 192 to run correctly. When I downloaded eclipse, it's suggesting that I use JRE 17.0.2 but I recalled my coworker saying I need Java 8 update 192 otherwise it won't work. Does the JRE version matter? Is it irrelevant?
Perhaps I need to download JRE 8.192? I'm not sure. Any help would be appreciated.
I have a program for work that I'm told will only use Java version 8 update 192 to run correctly.
I would doubt the accuracy of that statement. I would say that someone is making a statement without evidence ... if that is what they actually said.
Maybe a more accurate statement is that the program is only known to run on that particular version ...
Anyway, it will probably run on a later version of Java 8, or Java 11. Java 17 is less certain because of the issue of package sealing / blocking of access to internal packages that occurred in Java 16. (Some of the sealing / blocking started in Java 9 ... but there are easy workarounds ...)
Q: Do you need a JRE?
A: No. A JDK will work just as well. (A JDK distro includes a JRE.) But unless there are strong counter-indications, you need the latest version of Java 8, 11 or 17. Java 8 u192 is years out of date.
The only way to be sure that the application will work on a particular version of Java is to try it. In general, there are no shortcuts.
Java 8 is still available, as the first Long-Term Support (LTS) version. The current release is Update 331. I would suggest starting with the latest update of Java 8.
Be aware that Java 8 is not receiving regular updates for the public except for critical security patches. You may want to consider paying for a support contract from any number of vendors such as Azul Systems or Oracle to get support including possible additional updates releases through the rest of this decade.
Generally Java apps will run on later versions of Java without any modifications needed. The Java team at Oracle and the OpenJDK community place a very high priority on preserving that compatibility.
However, there are exceptions to the compatibility policy. In particular: Java 9 introduced the Java Platform Module System which caused some problems in some apps. And in later versions of Java some libraries that were previously bundled are now removed. Some of those removed libraries were transferred to the Jakarta EE project at the Eclipse Foundation. Some were abandoned for lack of interest such as CORBA.
Some few parts of Java that were for years marked as “deprecated for eventual removal” have now been removed.
If you consider moving beyond Java 8, I suggest your first step be sitting down to read through the Release Notes for every release of Java. They are quite well-written. They should alert you to any issues that may affect your app.
FYI, Java 17 is the latest LTS version. Java 18 is current.
As in the other answers, an application built for Java 8 will probably work fine in Java 17, with some caveats, but if you absolutely need the final product to run under Java 8, go get a real Java 8 runtime and set it up in your IDE. Building a Java application for any specific Java version is best done by having an actual copy of that runtime present, preferably a JDK. By having an exact version of its standard library to compile against, you can avoid accidentally referring to packages, classes, and methods added to, or removed from, later versions. You can get an OpenJDK build of Java 8 from https://adoptium.net/?variant=openjdk8 . Be sure to ask your co-worker why they're mentioning an outdated patch version.
Additionally, keep in mind that Eclipse is itself a large Java application. Running it requires Java, and a growing number of downloads include a Java runtime for that simple reason, even the ones that do not include Java development tools. You don't have to compile your code against that version of Java, though--you probably don't even want to since JDK downloads will include JavaDoc for the standard library, among other useful extras.
Here's the thing:
Me and my teammates are now working on a Java project, but I'm almost new to Java development. The thing is that I recently updated my local Java version to 15.0.2, however, they created the project with JDK 1.8 (Java 8 perhaps?).
We are worried that this might cause some conflicts since our Java versions are not corresponding, and I'm also not familiar with the relationship between Java version and JDK version (Just like Java 8 and JDK 1.8).
Could somebody give me some explanations of this? Thanks a lot!
We are worried that this might cause some conflicts since our Java versions are not corresponding ...
Yes, you could run into problems:
There are significant differences in the Java language and Java standard class libraries between Java 8 and Java 15. Code written for Java 15 using Java 15 may not compile on Java 8.
Java 8 and Java 15 tool chains produce compiled code with different classfile version numbers. Code compiled for Java 15 will not run on a Java 8 platform.
It is possible to work around these problems, but it is much simpler if all project members use the same Java version.
If you are new to Java, my recommendation is to install and use Java 8. Note that it is possible to have different versions of Java installed simultaneously, and use different versions for different projects.
... and I'm also not familiar with the relationship between Java version and JDK version (Just like Java 8 and JDK 1.8).
It is pretty straightforward. Java 8 is JDK 1.8, Java 9 is JDK 1.9, and so on. This started with Java 5 / JDK 1.5
The weird numbering is a result of a Sun Management / Marketing decision when naming Java 5:
"The number "5.0" is used to better reflect the level of maturity, stability, scalability and security of the J2SE."
Source: https://docs.oracle.com/javase/1.5.0/docs/relnotes/version-5.0.html
(You could also say that the people who made this decision didn't understand the principles of semantic version numbering.)
I maintain a Java tutorial application written in Java, that demonstrates features of Java 6, 7, and 8. Each tutorial screen is loaded dynamically by Class.forName as needed. The Java 7 classes need to use Java 7 constructs, and the Java 8 classes need to use Lambdas and Date/Time API.
I would like this to be accessible to users of all three of those language levels, just that if they are on Java 6 we would not load up the Java 7 or 8 classes, and if on 7 we would not load the Java 8 classes.
We would dynamically determine the runtime level and disregard higher levels, loading only the relevant classes by Class.forName(). Obviously users with Java 6 or 7 would not be able to execute code with a magic number of 8. So I would like to target an earlier Java release in the build.
In other words, I would like to set source to 1.8 and target to 1.6
However Maven (and Javac) prevent me from specifying a target lower than the source.
Is there any other way?
I have done this in the past with JavaFX code for Android, where I was able to build JavaFX 8 code using Lambdas, but then deploy it to current Android versions. But in that case, there was a special SDK that handled the lambdas and built to Java 7.
Is there any way to do that with standard Java 8?
The only option you have is -source 1.1 -target 1.0 In every other case, they have to be the same
You need to build a jar for each version and another which combines them.
You will have to make 3 different jars, one for each version where the later version include more of your code examples. (on the bright side, you just have to recompile the the java 6 and 7 code multiple times)
for each jar set the -target code to 6, 7 or 8 respectively. You can optionally also use -source parameter and set it to the same value but I don't think you need to unless you are worried you accidentally put in later language features.
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.
I have created the project using the JDK 1.4. Now I want to use JDK 1.6 version in my project.
for this what steps are required.Means I want to know the what changes is require in code to get a JDK 1.6 feature.Basically I am talking about the features that is added in JDK 1.6. If any one list out that changes it is very helpful.
Thanks in advance..............................
Better to see differences between 1.4 and 1.5 and then between 1.5 and 1.6.
You can check new features in each version on official web site, but below is a little chronology ...
JDK 1.0 (january 23, 1996) oak
Initial release
JDK 1.1 (february 19, 1997)
Retooling of the AWT event model
Inner classes added to the language
JavaBeans
JDBC
RMI
J2SE 1.2 (December 8, 1998) playground
This and subsequent releases through J2SE 5.0 were rebranded retrospectively Java 2 & version name "J2SE"
(Java 2 platform, Standard edition) replaced JDK to distinguish the base platform from
J2EE (java 2 platform, enterprise edition) and J2ME (java 2 platform, micro edition).
Strictfp keyword
Reflection
Swing api integration into the core classes
JVM equipped with a jit compiler
Java plug-in
Java IDL
An IDL implementation for corba interoperability
Collections Framework
J2SE 1.3 (may 8, 2000) kestrel
Hotspot jvm included
JavaSound
JNDI included in core libraries
Java platform debugger architecture (jpda)
RMI was modified to support optional compatibility with corba
J2SE 1.4 (february 6, 2002) merlin
assert keyword
Regular expressions
Exception chaining (allows an exception to encapsulate original lower-level exception)
Internet protocol version 6 (IPV6) support
Non-blocking nio (new input/output)
Logging API
Image i/o api for reading and writing images in formats like jpeg and png
Integrated XML parser and XSLT processor (JAXP)
Integrated security and cryptography extensions (JCE, JSSE, JAAS)
Java web start
J2SE 5.0 (september 30, 2004) tiger [originally numbered 1.5]
Generics: provides compile-time
(static) type safety for collections
and eliminates the need for most
typecasts (type conversion).
Metadata: also called annotations; allows language constructs such as classes and methods to be tagged with additional data, which can then be processed by metadata-aware utilities.
Autoboxing/unboxing: automatic conversions between primitive types (such as int) and primitive wrapper classes (such as integer).
Enumerations: the enum keyword creates a typesafe, ordered list of values (such as day.monday, day.tuesday, etc.). Previously this could only be achieved by non-typesafe constant integers or manually constructed classes (typesafe enum pattern).
Swing: new skinnable look and feel, called synth.
Var args: the last parameter of a method can now be declared using a type name followed by three dots (e.g. Void drawtext(string... Lines)). In the calling code any number of parameters of that type can be used and they are then placed in an array to be passed to the method, or alternatively the calling code can pass an array of that type.
Enhanced for each loop: the for loop syntax is extended with special syntax for iterating over each member of either an array or any iterable, such as the standard collection classesfix the previously broken semantics of the java memory model, which defines how threads interact through memory.
Automatic stub generation for rmi objects.
Static imports concurrency utilities in package java.util.concurrent.
Scanner class for parsing data from various input streams and buffers.
Assertions
StringBuilder class (in java.lang package)
Annotations
Java SE 6 (december 11, 2006) mustang
sun replaced the name "J2SE" with java se and dropped the ".0" from the version number.
Beta versions were released in february and june 2006, leading up to a final release that occurred on december 11, 2006.
The current revision is update 20.
Support for older win9x versions dropped.
Scripting lang support: Generic API for integration with scripting languages, & built-in mozilla javascript rhino integration
Dramatic performance improvements for the core platform, and swing.
Improved web service support through JAX-WS JDBC 4.0 support
Java compiler API: an API allowing a java program to select and invoke a java compiler programmatically.
Upgrade of JAXB to version 2.0: including integration of a stax parser.
Support for pluggable annotations
Many GUI improvements, such as integration of swingworker in the API, table sorting and filtering, and true swing double-buffering (eliminating the gray-area effect).
Java se 6 update 10
A major enhancement in terms of end-user usability.
Java Deployment Toolkit, a set of
javascript functions to ease the
deployment of applets and java web
start applications.
Java Kernel, a small installer including only the most commonly used jre classes. Enhanced updater.
Enhanced versioning and pack200 support: server-side support is no longer required.
Java quick starter, to improve cold start-up time.
Improved performance of java2D graphics primitives on windows, using direct3D and hardware acceleration.
A new Swing look and feel called NIMBUS and based on synth.
Next-generation java plug-in: applets now run in a separate process and support many features of web start applications.
Java se 6 update 12
This release includes the highly anticipated 64-bit java plug-in (for 64-bit browsers only), windows server 2008 support,
and performance improvements of java and JAVAFX applications.
...........
You can check in wikipedia till latest update.
To my opinion, the four most prominent enhancements since Java 1.4.2 are
Generics
enums
enhanced for-loop and
Annotations
There are a lot of additional classes and API enhancements, but if you want to 'upgrade' your code, I'd suggest to start your refactoring with using generics and replacing standard for loops by enhanced for loops. Both can be done without major code changes, clean up the code (you can delete a lot of lines of code) and improve readability. And using generics might reveal some hidden bugs ;)
I have created the project using the JDK 1.4. Now I want to use JDK 1.6 version in my project. For this what steps are required.
Actually, there is (almost) nothing that you need to start to make a JDK 1.4 application run using JDK 1.6. In nearly all cases, you simply need to recompile the code with the JDK 1.6 compiler and run it in a JDK 1.6 JVM. The only problems you are likely to encounter are:
If your code uses "enum" as an identifier, you will need to change it to something else. enum is a keyword starting in Java 1.5.
If your code directly depends on Sun proprietary / internal classes, you may need to deal with unannounced API changes.
You might find the certain official API classes or methods have been marked as deprecated.
There are a small number of changes in API implementations / behaviors with each release that may impact your application. These are typically highlighted in the document on upgrading.
Once you have got your application working on Java 1.6, you can then think about whether and when to start using the Java 1.5 language extensions, and the new / enhanced APIs in the class libraries.
Means I want to know the what changes is require in code to get a JDK 1.6 feature.
Almost no changes are required. But obviously, if you want or need to use a new feature you will need to change your code to do that.
Wikipedia has an summary of the most significant changes made across various Java releases.
UPDATE
As of May 2014, Java 6 has been "end-of-lifed", and Java 8 has been released for a month or so (with no significant early release number dramas). You should now be thinking about moving to at least Java 7, and probably Java 8.
The same principles apply. Recompile and run your regression tests, and you will most likely to be good to go. Then start learning all about the Java 8 language extensions.
What's new in JDK 6?
There are so many changes added in 6.0.
However all your 1.4 code will run smoothly.
For further reference about the version please see the following link
http://en.wikipedia.org/wiki/Java_version_history#Java_SE_6_.28December_11.2C_2006.29
Hope it helps.
The important details on 1.5 extensions are covered in these slides which provides also code examples.
There is a big difference in behaviour for volatile keyword in 1.5 - more along the lines of C# away from C++ behaviour. But it only makes the code safer. So no code changes.