Converting Java byte code to source code, flavours of JVM, and JVM runtime arguments
In the Java, JDK, JRE, JIT, and JVM basics post we looked at:
- Why use Java?
- Is Java 100% object oriented?
- What does Java comprise of?
- What is the main difference between the Java platform and the other software platforms?
- How would you differentiate JDK, JRE, JVM, and JIT?
Q. Is it possible to convert byte code into source code?
A. Yes. A Java decompiler is a computer program capable of reversing the work done by a compiler. In essence, it can convert back the byte code (i.e. the .class file) into the source code (i.e the .java file). There are many decompilers that exist today, but the most widely used JD - Java Decompiler is available both as stand-alone GUI program and as an eclipse plug-in.
Q. How do you protect your class files from illegally decompiled?
A. If you want to protect your Java class files from being decompiled, you can take a look at a Java obfuscator tool like yGuard or ProGuard, otherwise you will have to kiss your intellectual property good bye.
Q. When would you use a decompiler?
- When you have *.class files and you do not have access to the source code (*.java files). For example, some vendors do not ship the source code for java class files or you accidentally lost (e.g deleted) your source code, in which case you can use the Java decompiler to reconstruct the source file.
- Another scenario is that if you generated your .class files from another language like a groovy script, using the groovyc command, you may want to use a Java decompiler to inspect the Java source code for the groovy generated class files to debug or get a better understanding of groovy integration with Java.
- To ensure that your code is adequately obfuscated before releasing it into the public domain.
- Fixing and debugging .class files when developers are slow to respond to questions that need immediate answers. To learn both Java and how the Java VM works.
Q. What are the two flavors of JVM?
A. Client mode is suited for short lived programs like stand-alone GUI applications and applets. Specially tuned to reduce application start-up time and memory footprint, making it well suited for client applications. For example:
c:\> java -client MyProgram
Server mode is suited for long running server applications, which can be active for weeks or months at a time. Specially tuned to maximize peak operating speed. The fastest possible operating speed is more important than fast start-up time or smaller runtime memory footprint.
c:\> java -server MyProgram
Q. How do you know in which mode your JVM is running?
c:\> java -version
java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
Note: -client or -server must be the first argument or option of the JVM.
Q. What are the two different bits of JVM? What is the major limitation of 32 bit JVM?
A. JVMs are available in 32 bits (-d32 JVM argument) and 64 bits (-d64 JVM argument). 64-bit JVMs are typically only available from JDK 5.0 onwards. It is recommended that the 32-bit be used as the default JVM and 64-bit used if more memory is needed than what can be allocated to a 32-bit JVM. The Sun Java VM cannot grow beyond ~2GB on a 32bit server machine even if you install more than 2GB of RAM into your server. It is recommended that a 64bit OS with larger memory hardware is used when larger heap sizes are required. For example, >4GB is assigned to the JVM and used for deployments of >250 concurrent or >2500 casual users.
Q. What are some of the JVM arguments you have used in your projects?
A. To set a system property that can be retrieved using System.getPropety("name");
$java -Dname=value MyApp
To set the JVM mode: -client or -server
$ java -server MyApp
To set the classpath: -cp or -classpath
$java -cp library.jar MyApp
To set minimum and maximum heap sizes:
$java -Xms1024 -Xmx1024 MyApp
To set garbage collection options:
$ java -Xincgc MyApp
To enable assertion:
In the next post
- How to monitor the JVM?