Running Javac from Java !

Oh Long time, No post .. So I decided to go for one :). I suspended the thread of JVM Part-N because some of my friends told that these things are also written in book, write something extra. For writing extra, I don't have knowledge :D

Anyway, as we all know Scripting language is the most powerful language for running real application and most of the time I get it challenging to convert that script code into Java code, but believe me I am always ready to take this challenge. So this time my challenge was to run set of Java codes from a single Java Program. In general we run java code by opening cmd and doing those javac,java.

Again, its a damn easy job for a scripting language, but ... Ah come on you are a java programmer. And here the result, though currently I am running one Java code only from other Java Program (sorry for writing the code in a bad way)

import java.io.*;

class JavaCode {
public static void main(String[] args1)
{
com.sun.tools.javac.Main javac = new com.sun.tools.javac.Main();
File file = new File("V.java");
String filename = file.getName();
String classname = filename.substring(0, filename.length()-5);
String[] args = new String[] { filename };
int status = javac.compile(args);
System.out.println(status);
}
}

(Some bad naming convention, some crap hard coding.. but you can pardon me for that :D ). Some unused part of code like taking classname, I am going to use it further to run the code. Ok this code is compiling and telling the status of V.java ...some Helloworld code (please put both in same location :) )

Ok so next is to run and print Hello World ... Not a tough job :)

JVM Internals – Part II (Space Organization)

(Click on the main title to go for Part I)

In my previous post, I forgot to write about JVM specification (mind it, it’s a specification, Sun implementation of this is HotSpot, there are many others). JVM specification is written by Tim and Frank (The JavaTM Virtual Machine Specification, this is a free download book written by them). This specification is basically written in three parts ...saying:

~ A set of instructions – Bytecode
~ A binary format – Class file format
~ An algorithm for identifying programs that can’t compromise the integrity of the JVM – verification.


Yes, so coming to the point. JVM is divided into 4 conceptual data spaces:

# Class Area – where the code and constants are kept
# Heap – home for object
# Java Stack – keep tracks on method invocation and data associated with that
# Native Method Stacks – Something to do with native method

Lets take an example … where is our lovely class Foo :)

Class Foo {

public static void main(String[] args)
{
System.out.println(“Hello World(s)”);
}
}

So tell me how many object we have?

We have 3 objects: args, out and Hello World(s). All goes into Heap.

Class Area:

Class: Foo
Method: main ( actually we have main method descriptor here)

Java Stack:

It has stack handling the push and pop of local variables like Hello World(s), out and args.

Native Method Stack: I am relaxing :)

Stack going up and down is a bogus story.

So, I am directly moving on Garbage Collector >>>

JVM Internals - Part I

Beginning of New Year seems to be challenging for me. I am not getting enough time to recollect my ideas and write a blog on that. But in the end of last year, I decided to write blogs on JVM internals from very basic, so that a person who knows Hello World in Java can understand it. And here it goes:

Everything is sequential in this story and the most difficult is to find the entry point. Most of us are taking VM as a black box but looking inside this black box in not a tough job (neither an easy job).

VM is a machine dependent code that sacrifices itself to make java application machine independent. Lets first see the Hotspot into programmers perspective than latter we will analyze it on designer/architect perspective. Around 160 MB of this code written in C++ has 3 major parts:
~ Runtime Compilers
~ Garbage collectors
~ Everything else (JNI code, assembler code, oop (ordinary object pointer) code)

I will talk about all these later in my blog. So the folder structure goes something like this:
- vm
---- gc
---- runtime
---- compiler (communicates with other code of VM)
---- code (for Justin Time Compiler)
---- optimization
---- JNI (Java Native Interface to interact Java with c, c++ and vice-versa)
---- asm (assembler generated by VM)
---- oop (ordinary object pointers are java objects written in C++)
---- ...
---- ...

Understanding VM means understanding these parts. I will try to cover all of them in my upcoming blogs. In Sun, teams are dedicated for all these and believe me runtime people even don’t talk with gc people.