Hướng dẫn cài đặt java sdk cho forumvi năm 2024
There has been a lot of confusion lately about Java and its available SDKs (Software Development Kits). You might’ve heard the Java SDK called the JDK. They’re one and the same. Java SE (Standard Edition) is a specification that’s governed by the JCP (Java Community Process). This process decides what goes into (or gets removed from the JDK). Anyone can implement the Java specification. If they pass the TCK (Test Compatibility Kit), they’re considered a viable JDK. Show Confusion around the Java SDK started because of two events:
Here’s a quick summary of Oracle’s changes:
To make matters more contentious, Oracle will end public updates for Java 8 this month! This isn’t out of the ordinary, it regularly does this for major Java versions after five years of public availability. Related: public updates for Java 11 will end this March when Java 12 is released. This largely has to do with support contracts. I don’t know about you, but I’ve never paid for a Java support contract in my career. Granted, I’ve spent most of my developing days as an independent consultant. I’m willing to bet that most of you haven’t paid for Java support either. My guess is the people who pay for Java support are in charge of companies that built their business on Java and can’t migrate to the latest version. They need support and security fixes for older versions because they can’t upgrade. Java SDK OptionsCurrently, the only source code for the JDK is in the OpenJDK project. You can check out the source code for OpenJDK and build it yourself if you like. However, it’s not considered "Java SE compatible" unless it passes the TCK. Also, you cannot call it "Java SE" without getting a license from Oracle. There are many Java SDK options besides Oracle’s. Let’s take a look at the main ones and when you might want to use them. I’ve listed them below in alphabetical order. AdoptOpenJDKAdoptOpenJDK is a community and code that builds free OpenJDK binaries. They’re published to adoptopenjdk.net. Binaries are published for five years after the version’s initial release. Builds are available for OpenJ9 (IBM’s JVM) and HotSpot. What is OpenJ9? According to the AdoptOpenJDK website, OpenJ9 is a JVM that is designed for low memory usage and fast start-up time. A JVM runs compiled Java bytecode, while the Java language provides a syntax for how to produce that bytecode. AdoptOpenJDK builds are not tested with the TCK due to a disagreement with Oracle. They do test with a suite of functional, integration, and performance tests. They also test popular framework libraries, languages, and applications. Amazon CorrettoAmazon is the new vendor on the block that’s offering builds of OpenJDK at aws.amazon.com/corretto. Amazon Corretto 8 (based on Java 8) is in preview; there is no Java 11 build available. Corretto 11 is scheduled to be released in Q2 2019. GA for Corretto 8 is Q1. Corretto is unique in that it has no-cost long-term support from Amazon. Its builds have passed the TCK. Java 8 support is currently slated to run through June 2023. All AWS instances that run Java use Corretto by default. Azul ZuluAzul builds and publishes Zulu at azul.com/downloads/zulu. It’s an OpenJDK build that’s passed the TCK and is fully compliant with the Java SE standard. Zulu Enterprise is Azul’s commercial offering with paid support. It provides long-term support for eight years after the version’s initial release. Microsoft’s Azure platform uses Zulu for its Java support. Oracle’s OpenJDKOracle builds and publishes OpenJDK builds at jdk.java.net. Binaries are only published for the first six months after a major release. The branded, commercial version (that can’t be used in production without paying Oracle) is available at oracle.com/technetwork/java/javase/downloads. jdk.java.net is where Oracle’s OpenJDK builds are published for download, openjdk.java.net is the OpenJDK project itself. Red HatRed Hat distributes OpenJDK builds via Red Hat Enterprise Linux, a commercial product. It also has an IcedTea project that builds OpenJDK and adds some features. However, it doesn’t seem to be very active (there’s no Java 11 support) and you hardly hear about it anymore. Which JDK Should You Use?The JDK I use is largely determined by the tool I use to install Java. I used to download and install Java manually. When I did that, I used Oracle’s JDK. These days, I use SDKMAN!, a command line tool that installs and manages versions for me. SDKMAN determines the distributions I use today. SDKMAN is all about convenience. The project aims to make it as easy as possible for you to install Java. If you run To see the versions available from SDKMAN, you can run
$ java -version
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (build 1.8.0_192-amazon-corretto-preview-b12)
OpenJDK 64-Bit Server VM (build 25.192-b12, mixed mode)
$ jenv versions
system
1.8
I also have OpenJDK 11 installed. What Java SDK do you recommend for development? For production?Brian Demers: This is tricky one, many of us are still going to be supporting a minimum version of Java 8 for a while. Generally, I’d say for development, use what you are using in production, but for things like library development, it’s definitely time to move to an OpenJDK distro. For production, I suggest starting with what is readily available on your platform (Amazon, Red Hat) and switch later to a different distro later if you need to. Micah Silverman: For me today, it’s squarely Java 8 in development and production. That’s because the people I support are primarily using Java 8. That said, I set a goal for myself to update my relevant blog posts and examples as well as the production code I’ve written for my team to Java 11 this year. We’ll see how that goes. I was pissed that while the incorporation of Jigsaw with Java 9 and above is awesome, it essentially broke existing code immediately. I would’ve liked to have seen a "compatibility mode" or some such to ease the transition. But, the route of "pulling the band-aid" is not terrible either. I just haven’t gotten there yet. I asked Les Hazlewood about OpenJDK versus Oracle. Here’s what he had to say: "The only time the OpenJDK builds have been a big pain for me is that they were woefully behind the Oracle JDK’s implementation for TLS cipher suites and TLS version (1.1, 1.2) implementations. However, the open-source projects I work on have a pretty large exposure to diverse crypto algorithms and reverse-proxy types of workloads which leverage these things pretty deeply, so that very likely may not represent the types of issues others might encounter with standard web apps or microservices when trying OpenJDK. Especially if OpenJDK 11 and later are supposedly more aligned with the Oracle JDK releases. That said, I am fairly nervous about the ability to receive timely bug fixes and point revision patches over OpenJDK’s lifetime. With the new Java versioning strategy, the only way to obtain those patches long term without paying would be to upgrade as soon as possible to the latest stable releases (11, then 12, then 13) as soon as they’re released. That can potentially significantly increase build/ci/test compatibility burden. However, given that these releases are time-based – and not as much feature-based – the amount of conflicts you might see from version upgrades after getting to the 11 baseline I would expect would be much, much fewer than what most people experienced going from version 7 to 8. So this could be attainable but definitely increases testing and rollout workload for software engineering and operations teams. Not fun but doable. I also have had some exposure with the Azul guys in the past. It was a while ago, but I was quite impressed with their garbage collectors that came out long before JDK 8’s dynamic collector. I think Azul customers haven’t had to deal with PermGen Space Exceptions for almost a decade now, if not longer. Their engineering team at the time I engaged with them was extraordinarily smart, and assuming they’re still staffed with such folks, I personally would feel confident using their JDK implementations in production after suitable testing. Given that people can’t use JDK 11 or later in production without paying, my particular take on a pragmatic approach for an engineering team would be:
Java Is Still FreeMatt Raible is a well-known figure in the Java community and has been building web applications for most of his adult life. For over 20 years, he has helped developers learn and adopt open source frameworks and use them effectively. He's a web developer, Java Champion, and Developer Advocate at Okta. Matt has been a speaker at many conferences worldwide, including Devnexus, Devoxx Belgium, Devoxx France, Jfokus, and JavaOne. He is the author of The Angular Mini-Book, The JHipster Mini-Book, Spring Live, and contributed to Pro JSP. He is a frequent contributor to open source and a member of the JHipster development team. You can find him online @mraible and raibledesigns.com. |