JDK is designed to be mainly used to communicating with the JRE, but it can be replaced by others JDK-based languages which can communicate with JRE and JVM, for example, Kotlin.^ Furthermore, Java bytecode can be compiled statically directly into native code only with a JVM but without the necessity of the Java runtime environment running dynamically.
It implements the Java Language Specification (JLS) and the Java Virtual Machine Specification (JVMS) and provides the Standard Edition (SE) of the Java Application Programming Interface (API). It is derivative of the community driven OpenJDK which Oracle stewards.[6]It provides software for working with Java applications. Examples of included software are the Java virtual machine, a compiler, performance monitoring tools, a debugger, and other utilities that Oracle considers useful for Java programmers.
Oracle releases the current version of the software under the Oracle No-Fee Terms and Conditions (NFTC) license. Oracle releases binaries for the x86-64 architecture for Windows, macOS, and Linux based operating systems, and for the aarch64 architecture for macOS and Linux. Previous versions supported the Oracle Solaris operating system and SPARC architecture.
Oracle's primary implementation of the JVMS is known as HotSpot.
JDK contents
The JDK has as its primary components a collection of programming tools, including:
appletviewer– this tool can be used to run and debug Java applets without a web browser
extcheck – a utility that detects JAR file conflicts
idlj – the IDL-to-Java compiler. This utility generates Java bindings from a given Java IDL file.
jabswitch – the Java Access Bridge. Exposes assistive technologies on Microsoft Windows systems.
java – the loader for Java applications. This tool is an interpreter and can interpret the class files generated by the javac compiler. Now a single launcher is used for both development and deployment. The old deployment launcher, jre, no longer[update] comes with Sun JDK, and instead it has been replaced by this new java loader.
jinfo – This utility gets configuration information from a running Java process or crash dump. (experimental)
jmap Oracle jmap – Memory Map– This utility outputs the memory map for Java and can print shared object memory maps or heap memory details of a given process or core dump. (experimental)
jmc – Java Mission Control
jpackage – a tool for generating self-contained application bundles. (experimental)
jps – Java Virtual Machine Process Status Tool lists the instrumented HotSpot Java Virtual Machines (JVMs) on the target system. (experimental)
policytool – the policy creation and management tool, which can determine policy for a Java runtime, specifying which permissions are available for code from various sources.
wsimport – generates portable JAX-WS artifacts for invoking a web service.
xjc – Part of the Java API for XML Binding (JAXB) API. It accepts an XML schema and generates Java classes.
Experimental tools may not be available in future versions of the JDK.
The JDK also comes with a complete Java Runtime Environment (JRE), usually called a private runtime, due to the fact that it is separated from the "regular" JRE and has extra contents. It consists of a Java virtual machine and all of the class libraries present in the production environment, as well as additional libraries only useful to developers, such as the internationalization libraries and the IDL libraries.
Copies of the JDK also include a wide selection of example programs demonstrating the use of almost all portions of the Java API.
Other JDKs
In addition to the most widely used JDK discussed in this article, there are other JDKs commonly available for a variety of platforms, some of which started from the Sun JDK source and some that did not. All adhere to the basic Java specifications, but often differ in explicitly unspecified areas, such as garbage collection, compilation strategies, and optimization techniques. They include:
1.^ Although the JDK is a development kit, all its modules could be replaced by another one of a language that is compatible with the JVM and JRE, compiling its code to bytecode. There is a misunderstanding about the JDK including the JRE and JVM; the JDK usually uses both. Of course, the JDK only works with the JRE and JVM, but the JRE and JVM don’t, so the JDK is dependent on them because it communicates using bytecode. The inverse isn’t valid because the JVM and JRE don’t depend exclusively on the JDK, which is written in Java. They are independent in existence dependent of the perspective and aren’t used by the user who only executes the Java application but does not develop it. [needsindependentconfirmation]
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
