Editing Java (programming language) (section)

== Execution system ==
=== Java JVM and bytecode ===
{{Main|Java (software platform)|Java virtual machine}}
<!-- we apparently have two main sections for what seems to be the same thing. Merge needed? -->

One design goal of Java is [[software portability|portability]], which means that programs written for the Java platform must run similarly on any combination of hardware and operating system with adequate run time support. This is achieved by compiling the Java language code to an intermediate representation called [[Java bytecode]], instead of directly to architecture-specific [[machine code]]. Java bytecode instructions are analogous to machine code, but they are intended to be executed by a [[virtual machine]] (VM) written specifically for the host hardware. [[End user|End-users]] commonly use a [[Java virtual machine|Java Runtime Environment]] (JRE) installed on their device for standalone Java applications or a web browser for [[Java applet]]s.

Standard libraries provide a generic way to access host-specific features such as graphics, [[thread (computing)|threading]], and [[Computer network|networking]].

The use of universal bytecode makes porting simple. However, the overhead of [[Interpreter (computing)|interpreting]] bytecode into machine instructions made interpreted programs almost always run more slowly than native [[executable]]s. [[Just-in-time compilation|Just-in-time]] (JIT) compilers that compile byte-codes to machine code during runtime were introduced from an early stage. Java's Hotspot compiler is actually two compilers in one; and with [[GraalVM]] (included in e.g. Java 11, but removed as of Java 16) allowing [[tiered compilation]].<ref>{{Cite web |date=2021-08-06 |title=Deep Dive Into the New Java JIT Compiler – Graal {{!}} Baeldung |url=https://www.baeldung.com/graal-java-jit-compiler |access-date=2021-10-13 |website=www.baeldung.com |language=en-US |archive-date=October 28, 2021 |archive-url=https://web.archive.org/web/20211028165746/https://www.baeldung.com/graal-java-jit-compiler |url-status=live }}</ref> Java itself is platform-independent and is adapted to the particular platform it is to run on by a [[Java virtual machine]] (JVM), which translates the [[Java bytecode]] into the platform's machine language.<ref>{{cite web|url=http://www.programmerinterview.com/index.php/java-questions/jvm-platform-dependent/|title=Is the JVM (Java Virtual Machine) platform dependent or platform independent? What is the advantage of using the JVM, and having Java be a translated language?|publisher=Programmer Interview|access-date=2015-01-19|archive-url=https://web.archive.org/web/20150119144223/http://www.programmerinterview.com/index.php/java-questions/jvm-platform-dependent/ |archive-date=January 19, 2015|url-status=live}}</ref>

==== Performance ====
{{Main|Java performance}}

Programs written in Java have a reputation for being slower and requiring more memory than those written in [[C++]].<ref name=Jelovic>{{cite web |title=Why Java will always be slower than C++ |last=Jelovic |first=Dejan |url=http://www.jelovic.com/articles/why_java_is_slow.htm |access-date=2008-02-15 |url-status=dead |archive-url=https://web.archive.org/web/20080211111923/http://www.jelovic.com/articles/why_java_is_slow.htm |archive-date=February 11, 2008}}</ref><ref>{{cite web |last=Hundt |first=Robert |title=Loop Recognition in C++/Java/Go/Scala |url=https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf |access-date=2012-07-12 |url-status=live |archive-url=https://web.archive.org/web/20111116151424/https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf |archive-date=November 16, 2011}}</ref> However, Java programs' execution speed improved significantly with the introduction of [[just-in-time compilation]] in 1997/1998 for [[Java version history|Java&nbsp;1.1]],<ref>{{cite web |url=http://www.symantec.com/about/news/release/article.jsp?prid=19970407_03 |title=Symantec's Just-In-Time Java Compiler To Be Integrated into Sun JDK 1.1 |access-date=August 1, 2009 |archive-url=https://web.archive.org/web/20100628171748/http://www.symantec.com/about/news/release/article.jsp?prid=19970407_03 |archive-date=June 28, 2010 |url-status=dead}}</ref> the addition of language features supporting better code analysis (such as inner classes, the StringBuilder class, optional assertions, etc.), and optimizations in the Java virtual machine, such as [[HotSpot (virtual machine)|HotSpot]] becoming Sun's default JVM in 2000. With Java&nbsp;1.5, the performance was improved with the addition of the {{code|java.util.concurrent}} package, including [[lock-free]] implementations of the [[Java ConcurrentMap|ConcurrentMaps]] and other multi-core collections, and it was improved further with Java&nbsp;1.6.

=== Non-JVM ===
Some platforms offer direct hardware support for Java; there are micro controllers that can run Java bytecode in hardware instead of a software Java virtual machine,<ref>{{Cite journal|last1=Salcic|first1=Zoran|last2=Park|first2=Heejong|last3=Teich|first3=Jürgen|last4=Malik|first4=Avinash|last5=Nadeem|first5=Muhammad|date=2017-07-22|title=Noc-HMP: A Heterogeneous Multicore Processor for Embedded Systems Designed in SystemJ|journal=ACM Transactions on Design Automation of Electronic Systems |volume=22|issue=4|pages=73|doi=10.1145/3073416|s2cid=11150290|issn=1084-4309}}</ref> and some [[ARM architecture family|ARM]]-based processors could have hardware support for executing Java bytecode through their [[Jazelle]] option, though support has mostly been dropped in current implementations of ARM.

=== Automatic memory management ===
Java uses an [[Garbage collection (computer science)|automatic garbage collector]] to manage memory in the [[object lifetime|object lifecycle]]. The programmer determines when objects are created, and the Java runtime is responsible for recovering the memory once objects are no longer in use. Once no references to an object remain, the [[unreachable memory]] becomes eligible to be freed automatically by the garbage collector. Something similar to a [[memory leak]] may still occur if a programmer's code holds a reference to an object that is no longer needed, typically when objects that are no longer needed are stored in containers that are still in use.{{sfn|Bloch|2018|loc=§Item 7: Eliminate obsolete object references|p=26-28}} If methods for a non-existent object are called, a [[null pointer]] exception is thrown.<ref>{{cite web |url=http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html |title=NullPointerException |publisher=Oracle |access-date=2014-05-06 |archive-url=https://web.archive.org/web/20140506214735/http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html |archive-date=May 6, 2014 |url-status=live}}</ref><ref>{{cite web |url=http://www.artima.com/designtechniques/exceptions.html |title=Exceptions in Java |publisher=Artima.com |access-date=2010-08-10 |archive-url=https://web.archive.org/web/20090121152332/http://www.artima.com/designtechniques/exceptions.html |archive-date=January 21, 2009 |url-status=live}}</ref>

One of the ideas behind Java's automatic memory management model is that programmers can be spared the burden of having to perform manual memory management. In some languages, memory for the creation of objects is implicitly allocated on the [[Stack (abstract data type)|stack]] or explicitly allocated and deallocated from the [[Memory management#DYNAMIC|heap]]. In the latter case, the responsibility of managing memory resides with the programmer. If the program does not deallocate an object, a [[memory leak]] occurs.{{sfn|Bloch|2018|loc=§Item 7: Eliminate obsolete object references|p=26-28}} If the program attempts to access or deallocate memory that has already been deallocated, the result is undefined and difficult to predict, and the program is likely to become unstable or crash. This can be partially remedied by the use of [[smart pointer]]s, but these add overhead and complexity. Garbage collection does not prevent [[logical address|logical memory]] leaks, i.e. those where the memory is still referenced but never used.{{sfn|Bloch|2018|loc=§Item 7: Eliminate obsolete object references|p=26-28}}

Garbage collection may happen at any time. Ideally, it will occur when a program is idle. It is guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new object; this can cause a program to stall momentarily. Explicit memory management is not possible in Java.

Java does not support C/C++ style [[pointer (computer programming)|pointer arithmetic]], where object addresses can be arithmetically manipulated (e.g. by adding or subtracting an offset). This allows the garbage collector to relocate referenced objects and ensures type safety and security.

As in C++ and some other object-oriented languages, variables of Java's [[primitive data type]]s are either stored directly in fields (for objects) or on the [[Stack-based memory allocation|stack]] (for methods) rather than on the heap, as is commonly true for non-primitive data types (but see [[escape analysis]]). This was a conscious decision by Java's designers for performance reasons.

Java contains multiple types of garbage collectors. Since Java 9, HotSpot uses the [[Garbage-first collector|Garbage First Garbage Collector]] (G1GC) as the default.<ref>{{cite web |url=https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html |title=Java HotSpot™ Virtual Machine Performance Enhancements |publisher=Oracle.com |access-date=2017-04-26 |archive-url=https://web.archive.org/web/20170529071720/http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html |archive-date=May 29, 2017 |url-status=live}}</ref> However, there are also several other garbage collectors that can be used to manage the heap, such as the Z Garbage Collector (ZGC) introduced in Java 11, and Shenandoah GC, introduced in Java 12 but unavailable in Oracle-produced OpenJDK builds. Shenandoah is instead available in third-party builds of OpenJDK, such as [[Adoptium#Eclipse Temurin|Eclipse Temurin]]. For most applications in Java, G1GC is sufficient. In prior versions of Java, such as Java 8, the [https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html Parallel Garbage Collector] was used as the default garbage collector.

Having solved the memory management problem does not relieve the programmer of the burden of handling properly other kinds of resources, like network or database connections, file handles, etc., especially in the presence of exceptions.