How Java gets the classes?

In this article we are going to see how classes are found/work in JAVA with java tools. So, we will discussing about java, javac, javadoc tools which work directly with java classes and java source code.

As we know, first we make source code in to byte code(class file or jar file) and then run byte code.
Java Source ->Java Byte Code ->Running byte code in JVM.

Besides the source code generated class files, there are three type of classes.
1. User Classes , which are defined by developers(our made byte code). We can set location by -classpath option
2. Extension Classes, which are used by user classes or environments. These are 3rd party extensions that helps for a particular purpose. (usually as .jar files under jre/lib/ext folder)
3. Bootstrap classes, which comes with Java Run-time Environment(in rt.jar).

Security Factors : Class loaders loads Classes and interfaces to use them with a security policy. A program can load a class/interface by calling loadClass method of a class loader object. It calls internal class loader that applies the security policy. (I will provide separate post for security policy implementation example)
-If enabled, policy is configured by system and user policy files
-If policy is not enabled, by default all are "Trusted"
-Bootstrap classes are always "Trusted"

For Java command : (to run byte code)
When we run java launcher(java command), it first look for bootstrap classes, then extensions and then user classes. Java command reads system property (from sun.boot.class.path) and gets the bootstrap class first. We can redefine using -Xbootclasspath.(helpful when we need to run with different version of JRE)
Java command loads extensions using extension mechanism . Byte code must be in JAR files(loose class files will not be found). We can not change the location. Same name classes under different JARs are undefined.
For User class, Java command follow -classpath for JARs/Class files. The user class contains fully qualified names(with package name) and stored in tree formation folder followed by the name.(A dot will create a child folder. i.e. If a qualified class name = com.package.MyClass , then the my class will be com/package/MyClass.java file. and byte code will be com/package/MyClass.class). Java command puts the user class path string in the java.class.path system property. where
- The default  ".", means that user class files are all the class files in the current directory (or under it, if in a package).
-The value of the CLASSPATH environment variable, which overrides the default value.
-The value of the -cp or -classpath option overrides both the default value and the CLASSPATH value.
-The JAR is specified by -jar option, which overrides all other values. If this option is used, all user classes must come from the specified archive.
 If , classes are in a JAR file, java command gets class list from manifest (I will provide a separate post for JAR file specification)
In general, classes referenced by a
-The JAR files in the JAR-class-path are searched after any earlier class path entries, and before any entries that appear later in the class path.
-If the JAR-class-path points to already searched JARs ,then these will not be searched again. (For  optimization and avoiding circular searches)
-If a JAR file is installed as an extension, then any JAR-class-path it defines is ignored.(it will not be consider as user class, will be handled like as other extensions are handled)

For Javac and Javadoc : (to compile source code)
-Like as java, javac and javadoc loads class files to run
-For source code processing both need object type used in source code.
-The class files are used to resolve source code references but,
-Both resolve references to classes and interfaces that may be present in class files, source files, or both (though have nothing to do with implementation of javac or javadoc)
-The tools classes in tools.jar are only used to run javac and javadoc.
-Both javac and javadoc supports bootstrap and extension class path changing with -bootclasspath and -extdirs options. (not modify to the classes that runs the javac or javadoc themselves).
-If a referenced class is found in both a class file and source file, javadoc always uses the source file but javac uses class files(automatically recompiles any out of date class files , these rules have specifications)
-By default, javac/javadoc search the user class path for both class and source unless -sourcepath is specified (for source files only)

Thanks...:)

apt-Annotation Processing Tool in Java

In this article we are going to elaborate the apt command tool which is a part of JAVA commands (comes with jdk package). This article is the continuation of this previous article.

As we know the standard format of commands in java, the apt command also have the format(in command prompt). 
apt [options] [source file]

apt is a java annotation processor which are used in the source file using reflective API. This provides a build time , source based, read only view of programs structure that follows java generics. First apt determines used annotations, then look annotation processing factories and get what annotations they process , then ask a factory to provide an annotation processor . That creates new source code/other files. If the processors have generated new source files, apt will repeat this process until no new source files are generated.

apt Options : apt accepts all javac options. Following are apt specific options.
-s [dir] : Set  root directory for generated source(sub-directories are created based on package) -nocompile : Do not compile source to class .
-print : Prints (as text) specified types and performs no annotation processing or compilation.
-A[key[=val]] : Key and value passing to annotation processor(Not interpreted by apt , but set for individual processors)
-factorypath [path] : Set path to find annotation processor factories(classpath is not searched for factories)
-factory [classname] : Used Annotation Processor Factory Name

Debugging apt options :
-XListAnnotationTypes : Shows found annotation types
-XListDeclarations : Shows declarations
-XPrintAptRounds : Prints initial and recursive apt rounds
-XPrintFactoryInfo : Prints about annotations that asked a factory to process

Shared javac's options:
-d [dir] : Set location to place processor and javac generated classes.
-cp/-classpath [path] : Specify where to find class files and annotation processor factories.

Where we use annotation and processing :
1. Framework implementation(annotations in a framework perform some task depend on annotations. Ex-spring, hibernate or others.)
2. Reporting(making reports function results like Unit Test results, program output, application/function states) with different type of files.
3. Debugging(to see inner states of the functions with annotations)
4. Run time processing
5. Compile time and Deploy time processing
6. Compiler state information.

I will make separate post about annotations and  how to create a annotation processor.

Thanks...:) 

idlj, IDL-to-Java Compiler

In this article we are going to elaborate the idlj command tool which is a part of JAVA commands (comes with jdk package). This article is the continuation of this previous article.

As we know the standard format of commands in java, the idlj command also have the format(in command prompt). 
idlj [options] [idl-file]

A IDL file contains identification written in Interface Definition Language.

idlj builds IDL file to JAVA. Previously it was named as idltojava. idlj is a compiler that reads an OMG(Object Management Group) IDL(Interface Definition Language) file and translates / maps to a Java interface. It creates stub, skeleton, helper, holder and other necessary files. The specified pdf formatted OMG  file defines the interface file(.java). The mapping overview is in here.

jdlj Options : 
-d [symbol] : Is same as #define symbol in a idl file.
-emitAll : Emit all types along with files found in #include
-f[side] : Defines bindings to emit. A side can be client, server, serverTIE, all, or allTIE. fserverTIE and -fallTIE cause delegate to be emitted.(-fclient is not specified)
-i [include-path] : To add another directory for scanning with default one.
-keep : To set not to overwrite an existed file.
-noWarn : Set No warning messages.
-oldImplBase : Generates skeletons compatible with pre-1.4 JDK ORBs.(backward-compatibility to  ImplBase Inheritance Model classes)
-pkgPrefix [type] [prefix] : Generates Java package name with prefix for all files generated for that type(type is the simple name of either a top-level module, or an IDL type defined outside of any module)
-pkgTranslate [type] [package] : Replaces type module in the identifier with package for all generated Java package files
Note -pkgPrefix changes are made first. If more than one translation matches an identifier, the longest match is chosen.
-td [dir] : To set dir as output directory
-verbose : Verbose mode(Same as -nowarn)
-skeletonName [xxx%yyy] : Naming pattern for skeleton. The defaults are: %POA for the POA base class (-fserver /-fall), _%ImplBase for the oldImplBase class (-oldImplBase and -fserver /-fall)

-tieName [xxx%yyy] : Naming pattern for tie .The defaults are: %POATie for the POA tie base class (-fserverTie /-fallTie), %_Tie for the oldImplBase tie class (-oldImplBase and -fserverTie /-fallTie)

Notes:
-Escaped identifiers in the global scope may not have the same spelling as IDL primitive types, Object, or ValueBase as the symbol table is pre-loaded with these identifiers
-The fixed IDL type is not supported.
-No import for global identifiers. When we invoke on an unexported local impl,we will get exception, (due to a NullPointerException in the ServerDelegate DSI code)

Uses: When we are using old OMG IDL code to rewriting new java code. Spatially used while converting old codes/definitions. Some time it is used to followup old interface.

Thanks...:)