Okay, welcome back. In this lecture we'll introduce you to the Java platform. The key objectives of this lecture will be for you to understand what Java is, understand which tools to use, and to understand the different versions of Java.

When we talk about Java, what exactly do we mean? Well, Java is more than just a software language. It's a platform that provides many features. The Java platform not only runs on computers, but it is equally at home with cars, cards, rings, PDAs, and many other physical devices. The Java platform was developed early on with the explicit intention of being a portable technology, being agnostic of any underlying operating system, and therefore being able to run in as many different places as possible. This is and has been always one of the main motives to consider investing in Java.

Java is provided in several different versions each of which targets a particular use case. As seen here, there are three main versions: Java Standard version, Java Enterprise version, and the Java Micro edition. We'll focus on the specifics of each edition in the next three slides, but for now a quick summary follows.

The Java Standard edition or Java SE is typically used on desktop computers and high-end small devices. It contains some APIs that are essential to building enterprise applications, such as JDBC and RMI. The Java Enterprise edition or Java EE targets building large scale multi-tier enterprise applications and is built on top of the Java SE. It contains enterprise-specific APIs not found in Java SE, for example, CDI and Jax-RX. The Java Micro edition or Java ME is designed to be used in embedded systems and is essentially a subset of Java SE being subdivided into a number of profiles.

A quick note regarding the Java Enterprise edition, the Java Enterprise edition used to be maintained by Oracle under the Java community process. In 2017, Oracle announced that it would submit the platform to the Eclipse Foundation. Initially, the Eclipse top-level project was called Eclipse Enterprise for Java. However, since Oracle owns the trademark for the name Java, the Eclipse Foundation was forced to change the name. In February 2018 it was announced that the new name of Java Enterprise edition would become Jakarta Enterprise edition.

The Java platform Standard edition is very much at the core of Java technology. Java SE provides support for many areas of programming functionality, including but not limited to the essentials such as objects, strings, threads, numbers, input and output, data structures, system properties, date and time and so on. Networking, URLs, TCP and UDP sockets and IP addresses, internationalization, assistance for writing programs that can be localized for users worldwide.

Java SE is essentially a specification and various entities have provided their own implementations of that specification in the form of Java development kits, JDKs and Java runtime environments, JREs. As can be seen here, the Java SE is structured into the following components in layers.

At the bottom is the JVM or Java Virtual Machine. The JVM is responsible for running the Java byte code. Java byte code is the compiled output having taken your raw Java programming code and compiled it with the Java C command, more on that later. The next layout provides the base libraries and sitting on top of this layout are more specialized based libraries.

Next, we have even further specialized libraries for integration and user interface development. We then have our tooling and tool-based APIs that we use to compile package document and perform many other software development Java related tasks. And then at the very top is the Java language specification itself.

Another important grouping structure to understand is that of the JDK versus the JRE. JDK stands for Java Development Kit and JRE stands for Java Runtime Engine. The JRE is essentially a subset of the JDK being just the bits required to launch and run your application. For example, the runtime. The JDK consists of many other tools required to take your Java code and compile it into Java byte code that the JRE uses at runtime.

Drilling into the JDK we can see that it is composed of a set of major components used to build Java applications. The major components include the Java Core API or application programming interface, javac the Java compiler, java, the Java byte code interpreter or JVM, javadoc, use to generate documentation from source code, jar, used to create and extract Java archives, javap, used to disassemble class files, jdb a basic command line debugger, as well as many other tools.

Before a Java application can be executed it needs to undergo compilation. This process takes the Java source code files and converts them into byte code. Byte code is then loaded into the JVM, the JVM converts and optimizes the byte code into the underlying operating systems native code set at runtime. Each operating system has its own special JVM and it is this layer of abstraction that allows Java source code to be cross compatible.

Moving on to the JVM and its responsibilities, the JVM is responsible for loading and using of classes, including class resolution, preparation, and initialization, locating the entry point or main method and starting the execution at that point, garbage collection, reclaiming memory that is not being used anymore, security, protecting against uninitialized memory, illegal type conversions and illegal stack operations, and finally interfacing to native or platform-specific code.

When compared to more traditional non-virtual machine-based software languages, such as C++, Java is considered much more dynamic. For instance, a Java application is processed in a particular sequence before it is launched. The JVM or Java runtime will perform the following steps.

One: Java byte code is loaded into memory. Two: the JVM confirms that the byte codes are valid and follow specific security rules. Three, the JVM translates the byte code into native machine code specific to their host machine and performs final name resolution and linking. All of this happens before the application is ready to perform whatever it was designed to do so by the developer.

One of the unique processes that Java early on employed in its design at runtime as the process of garbage collection. Garbage collection essentially looks for unused objects and frees up the memory that was previously assigned or allocated to those objects. Garbage collection allows you as a developer to focus on the engineering of the application logic and not have to waste time writing memory management code. 

Another distinct advantage associated with using the Java platform is its ability to auto-generate documentation based on extracting and translating Java comments that you have supplied and embedded directly within the Java source code. For this to work, the comments need to follow a particular convention which is itself documented in the Java language specification.

Providing high quality documentation is essential to developing Java libraries for code reuse. The Javadoc tool is provided as part of the JDK and as the tool that is able to auto-generate browsable documentation, the Javadoc tool when executed over a code base generates an HTML based representation of the comments extracted from the source code that you have developed.

As you'll see in the next few slides, Javadoc can generate documentation for all abstraction layers, methods, classes, package, and modules. In doing so the documentation itself follows the same structure, making it easy to navigate through. Javadoc method-level documentation provides a description of what the method does, describes the parameters and their types, describes the return type of the method and describes any exceptions that might occur within the method.

Javadoc class level documentation provides a description of what the class does, describes the class inheritance path, describes the package and module that the class belongs to, and provides a list of fields, constructors and methods that it implements.

Javadoc package legal documentation provides an informative description of the package for the grouped classes within, provides a summary of related interfaces, classes, enums, and exceptions that exists and are used within the package. Javadoc module level documentation provides a summary of related packages and types, classes, abstract classes, interfaces, et cetera. Please note that modules were introduced in Java 9. 

Javadoc takes all of the method, class, package and module level documentation and links it all together, maintaining the same coding structure and exposes it with an entry level or top level page. This provides a clean and intuitive navigation system for drilling down into documentation.

Additional to the hyperlinking between the different abstraction layers within the Javadocs, the user can additionally use a search and find feature to discover the correct documentation. This feature caters for searching on module names, package names, class names, and/or class members.

As previously mentioned, Javadoc works by extracting and translating inline comments supplied by the developer that follow a particular convention. For example, here we see the author is exposed using the at author tag and the version is declared using the at version tag.

The comment of code from the previous slide is translated by the Javadoc tool into the following HTML rendering. This process is done and repeated automatically by the Javadoc utility for each and every method, class, package, and module.

Okay. That completes this introductory lecture. Take some time to consider the summarizing questions presented here. When you're comfortable with your answers close this lecture and we'll see you shortly in the next one.