Sunday, January 25, 2015

Java Evolution: JDK and JRE File Structure

"JDK and JRE File Structure" describes the most important files and directories required to develop applications for the Java platform. In [1], it states that there will be new changes in coming Java 9 such as:
  • JRE and JDK images now have identical structures.
    • Previously a JDK image embedded the JRE in a jre subdirectory; now a JDK image is simply a run-time image that happens to contain the full set of development tools and other items historically found in the JDK.
  • The internal files rt.jar, tools.jar, and dt.jar have been removed.
  • The extension mechanism has been removed.
  • The endorsed-standards override mechanism has been removed.

In this article, we will take one step back to see how "JDK and JRE File Structure" has evolved from Java 6 to 8. Note that the file structure of the JRE is identical to that of the JDK's jre directory.

Java 6


Assuming the JDK software is installed at /jdk1.6.0, here are some of the most important directories:[2]


               jdk1.6.0
        ___________|____________________ ________________________
       |           |                    |                        |
      bin         lib                  jre                     include     
       |           |          __________|_____________________
   java.exe    tools.jar     |                                |        
   javac.exe   dt.jar       bin                              lib                
   javap.exe            _____|____ __________         ________|_______ ________ ________        
   javah.exe           |          |          |       |        |       |        |        |
   javadoc.exe     java.exe    client      server  rt.jar    ext  security  applet    fonts
                   java.dll       |          |   charsets.jar |                  
                   awt.dll     jvm.dll    jvm.dll        localedata.jar      

Java 7


As part of the Java 7 release, the Java Development Kit (JDK) now includes the SDK for developing JavaFX applications and, more importantly, the JavaFX Runtime is now installed with the JRE.[3] In addition, there is new db sub-folder under the root directory of JDK software installation.

Assuming the JDK software is installed at /jdk1.7.0, here are some of the most important directories:[4]


               jdk1.7.0
        ___________|____________________ __________________________ _______
       |           |                    |                          |       |

      bin         lib                  jre                      include    db
       |           |          __________|________________________
   java.exe  ant-javafx.jar  |                                   |        
   javac.exe   dt.jar       bin                                 lib                
   javap.exe tools.jar  _____|____ __________          __________|_______ ________ ________        
   javah.exe           |          |          |        |          |       |        |        |
   javadoc.exe     java.exe    client      server   rt.jar      ext  security  applet    fonts
                   java.dll       |          |    charsets.jar   |                  
                   awt.dll     jvm.dll    jvm.dll   jfxrt.jar  localedata.jar      

Java 8


In Java 8, jfxrt.jar has become one of the optional packages (what used to be known as standard extensions).[6] So, it has been moved into /lib/ext.

Assuming the JDK software is installed at /jdk1.8.0, here are some of the most important directories:


               jdk1.8.0
        ___________|____________________ __________________________ _______
       |           |                    |                          |       |

      bin         lib                  jre                      include    db
       |           |          __________|________________________
   java.exe  ant-javafx.jar  |                                   |        
   javac.exe   dt.jar       bin                                 lib                
   javap.exe tools.jar  _____|____ __________          __________|_______ ________ ________        
   javah.exe           |          |          |        |          |       |        |        |
   javadoc.exe     java.exe    client      server   rt.jar      ext  security  applet    fonts
                   java.dll       |          |    charsets.jar   |                  
                   awt.dll     jvm.dll    jvm.dll              localedata.jar    
                                                               jfxrt.jar

Directory Summary


Directory
Contains
Setup
<jdk1.x.0>/bin
Executables for all the development tools contained in the JDK.
The PATH environment variable should contain an entry for this directory.
<jdk1.x.0>/lib Files used by the development tools.
<jdk1.x.0>/jre Root directory of the Java Runtime Environment (JRE) used by the JDK development tools. This is the directory referred to by the java.home system property.
<jdk1.x.0>/jre/bin Executable files for tools and libraries used by the Java platform.
The executable files are identical to files in /jdk1.x.0/bin.

This directory does not need to be in the PATH environment variable.
<jdk1.x.0>/jre/lib Code libraries, property settings, and resource files used by the JRE.
<jdk1.x.0>/jre/lib/ext Default installation directory for extensions to the Java platform.
See The Extension Mechanism
<jdk1.x.0>/jre/lib/security Contains files used for security management. These include the security policy java.policy and security properties java.security files.
<jdk1.x.0>/jre/lib/amd64 Contains the .so (shared object) files used by the architecture amd64 release of the Java platform

<jdk1.x.0>/jre/lib/amd64/server Contains the .so file used by the Java HotSpot VM server.
<jdk1.x.0>/jre/lib/applet JAR files that contain support classes for applets can be placed in the lib/applet/ directory.
This reduces startup time for large applets by allowing applet classes to be preloaded from the local file system by the applet class loader and provides the same protections as though they had been downloaded over the Internet.

<jdk1.x.0>/jre/lib/fonts Font files used by the platform.


References

  1. Project Jigsaw: Modular run-time images
  2. JDK and JRE File Structure (Java 6, Linux version)
  3. Java 7 Now Includes JavaFX
  4. JDK and JRE File Structure (Java 7, Linux version)
  5. JDK and JRE File Structure (Java 8, Linux version)
  6. Extension Mechanism Architecture
  7. WebLogic's Classloading Framework (Xml and More)
  8. java.lang.UnsatisfiedLinkError: Setting Environment Variable (Xml and More)

Tuesday, January 20, 2015

JAXP 1.6: Use of the Service Provider Loader Facility Is Required

In this article, we will first cover the pluggability layer supported in JAXP 1.5 (bundled with Java SE 7).[1] Then discuss new requirements in JAXP 1.6 (bundled with Java SE 8) for service providers.[2] Finally, we will touch upon Jigsaw project to understand JCP's decision to undertake such changes in JAXP 1.6, which aims to smooth the eventual transition to modules in Java 9.

Pluggability Layer


Designed to be flexible, JAXP allows you to use any XML-compliant processors from within your application. It does this with the factory APIs provided in jaxp-api.jar. High-level factory APIs will remain stable and are not subject to change. This jar contains:
  • javax.xml.datatype
  • javax.xml.namespace
  • javax.xml.parsers
  • javax.xml.stream
  • javax.xml.transform
  • javax.xml.validation
  • javax.xml.xpath
packages.

These packages contain the factory APIs that give applications a consistent way to obtain instances of XML processing implementations. Each factory class is an abstract class that has a static newInstance() method that enables you to obtain a concrete instance of the abstract factory class. This static method uses an ordered lookup procedure to determine which concrete implementation of the abstract factory class to load.

This procedure applies to all factory classes. For example, xmlparserv2.jar in Oracle XDK for Java has the following factory types supported:[4]
  • SAXParserFactory
  • DocumentBuilderFactory
  • TransformerFactory
Using SAXParserFactory as an example, the service provider mechanism works in JAXP 1.5 as follows:[7]
  1. Use system property
    • E.g. -Djavax.xml.parsers.SAXParserFactory=.
  2. Use the properties file "lib/jaxp.properties" in the JRE directory
    • This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above.
    • The jaxp.properties file is read only once by the JAXP implementation and it's values are then cached for future use. If the file does not exist when the first attempt is made to read from it, no further attempts are made to check for its existence. It is not possible to change the value of any property in jaxp.properties after it has been read for the first time.
  3. Use the Services API (as detailed in the JAR specification)
    • The Services API will look for a classname in the file META-INF/services/javax.xml.parsers.SAXParserFactory in jars available to the runtime.
  4. Use Platform default SAXParserFactory instance.
Once an application has obtained a reference to a SAXParserFactory it can use the factory to configure and obtain parser instances.

Transition to Modularization


As described in [3], the project Jigsaw[9] was postponed to Java 9. This project is to design and implement a standard module system for the Java SE Platform and to apply that system to the Platform itself, and to the JDK.

To smooth the transition to Java 9, JAXP 1.6 bundled in Java SE 8 has adopted JEP 162[5] recommended changes—one of which requires the use of the service provider loader facility defined by java.util.ServiceLoader[6] to load services from service configuration files.
  • The rationale for this is to allow for future modularization of the Java SE platform where service providers may be deployed by means other than JAR files and perhaps without the service configuration files.
  • Note that the JAXP has always specified the use of the 'Services API' without reference to a specific API or service provider loading facility.
There are several APIs in the JDK that have their own service provider mechanism rather than using java.util.ServiceLoader. The various FactoryFinders in pre-1.6 JAXP's are examples. These provider loading mechanisms are problematic for modules because they are non-standard. Therefore, JEP 162[5] has proposed to change these APIs to use java.util.ServiceLoader. So, the description of step 3 in the previous-stated "service provider mechanism" should be changed in JAXP 1.6 to:
3, Use the service-provider loading facilities