JAVA APPLICATION

Java Decompiler and its Missing Documentation

2011-05-08T21:26:00.000-07:00

If you ever need a good decompiler for Java, there are plenty around. Nonetheless, I found one that integrates smoothly with Eclipse, which I’m guessing is not as common. The aptly named Java Decompiler is a newer one that has three parts: a core library (JD-Core), a GUI (JD-GUI) and an Eclipse plugin (JD-Eclipse). The purpose of the first two parts is fairly obvious. There is a core library that implements the decompiler and a GUI application you can use to view decompiled files. The Eclipse plugin is the most novel and interesting piece of the trio, so that’s what I’m going to discuss here.

It sounds like a great plugin, but what does it do?

That’s a good question, and it’s the natural one to ask when you’re looking for such a thing. The JD-Eclipse page makes an effort to help you through installing the promising plugin, but it tells no stories about what functionality it offers. Oddly enough, the page doesn’t even explain what settings are available for the plugin. In fact, it doesn’t even mention that there are any preferences (yet they do exist).

It turns out that JD-Eclipse is quite a nice plugin. It quietly and effectively handles many use cases. There are some quirks with it, but overall it’s a great tool to have around. The official JD-Eclipse website lacks documentation on what to expect when using the tool. To fill that void, here are some of the features of JD-Eclipse that I’ve stumbled upon so far.

Settings

The JD-Eclipse settings panel.

The plugin’s two settings are located in Window –> Preferences –> Java –> Decompiler. The Display line numbers setting is deceitfully obvious. The “line numbers” referred to actually appear to be the line numbers from the .class file. The .class file line numbers are placed to the left of the code in a column of comments. In Listing 1, notice that the first number is the line number in the decompiled source file. Toggling off the Display line numbers setting will remove the .class file line numbers.

86 /*          */   public void setTitle(String title)
87 /*          */   {
88 /* 126 */     this.title = title;
89 /*          */   }

Listing 1 - A snippet of decompiled source code.

The Display metadata setting is useful to keep on. This prompts JD-Eclipse to add a comment to the bottom of each decompiled file identifying precisely which .class file was decompiled, what version of Java was used, and what version of JD-Core was used. The comment will look similar to Listing 2.

/* Location:           C:\eclipse-workspace\library.jar
* Qualified Name:     com.example.SampleClass
* Java Class Version: 6 (50.0)
* JD-Core Version:    0.5.3
*/

Listing 2 - The JD-Eclipse metadata from the bottom of a decompiled source file.

One major caveat to understand with these settings is that they are not instantly applied. Unlike all other Eclipse preferences, you have to restart Eclipse for these to take effect. I recommend just turning both on and leaving them set, which is the default.

When and where does JD-Eclipse do its work for you?

This is the real question I wanted an answer to before I installed it. Here are the scenarios I’ve encountered so far where JD-Eclipse decompiles code automatically for you. I emphasize automatic because that is why JD-Eclipse is a great tool. The designer has done a good job of figuring out when you would need code decompiled and has incorporated that knowledge into the plugin.

Opening a Java type

The most common scenario is when you’re opening a Java type. Specifically, a type for which the source code is absent from the project. There are several ways to do this in Eclipse and they all result in the decompiled source being opened.

As an example, let’s use the JDK classes. Especially if you’re using a licensed JDK like IBM’s, you probably don’t have the source code available in your workspace. But what if you want to look at a method’s implementation in the String class? You certainly do have the compiled JDK code in your workspace and JD-Eclipse can find it and decompile the class automatically. Here is a list of the ways I know of where you could open the String class in Eclipse:

Use the Open Type dialog (Ctrl+Shift+T)
Use the Enterprise Explorer, Package Explorer or Navigator view to drill-down to and open the String class in the included JRE/JDK library.
Hover over the text of the class name “String” in a source file and left-click to open the class.
Open the String class from the result of a Java search.

I’m sure there are other ways to open a class in Eclipse, but this list covers the most common scenarios. In any case, the result is that you can see the source code for the String class, a feat that JD-Eclipse pulls off automatically and silently. The only way you even know that JD-Eclipse was involved is by the display of its signature coffee mug icon beside the class name.

The decompiled java.lang.String class in Eclipse with the JD-Eclipse coffee mug logo.

Debugging

This scenario was the most surprising to me. I expected that when I opened a class with no source code that I would get the decompiled source, but I assumed that’s where JD-Eclipse would stop. Pleasingly, the decompiler also works when debugging. The simple act of stepping into code with no source code present will cause JD-Eclipse to kick in. The debugger will happily then display the decompiled source code and break at the expected line. Impressive.

The "debug" perspective in Eclipse. The debugger is at a break point in the String class.

When does JD-Eclipse not work for you?

There are some times when JD-Eclipse doesn’t do what I hoped it would. The biggest short-coming I’ve seen so far is that the decompiled code doesn’t always work correctly with the debugger. I’ve had a few times where the debugger breaks at a non-sensical line such as a closing bracket. Why this is, I can’t say for sure. My guess is that the process of compiling and decompiling causes the line numbers to be off slightly. This may not even be the fault of JD-Eclipse, but it’s still a nuisance.

JD-Eclipse also appears to override Eclipse when you actually have source code attached to a library. Even when you’ve configured your project to reference source code for a library, JD-Eclipse always wins out and displays the decompiled code. Ideally, JD-Eclipse should recognize this setting and let the real source code open rather than intervening with its decompiled version.

The other scenario that JD-Eclipse doesn’t cover is JSP files. Unfortunately, I haven’t yet found a way to decompile a compiled JSP. Again, this may be more an issue with Eclipse than JD-Eclipse.

Conclusion

JD-Eclipse is a great tool to have if you work often in Eclipse. What struck me as most enticing about it is how nimbly and stealthy it does its job. Most times, it just does what you want it to do, which is show the source code. Oh, and I didn’t mention that it’s fast. I’ve never noticed a pause while JD-Eclipse is decompiling. The source just opens as if it were right there in my project.

Decompile java code with Cavaj

2011-05-08T21:24:00.000-07:00

Decompile java code with Cavaj

Decompilers are used commonly for reconstructing the lost code and is used across different programming languages and in all platforms.The use of decompilers in java programming language is quite high compared to other ones. I have written an article about Java Decompilers last year which talks about the best open-source and commercial decompilers. I missed an important freeware java decompiler called Cavaj which helps you decompile java source code from class files recovering the lost source code.

Cavaj reconstructs the source code with the Class View providing instant access to methods and fields in the form of a tree view. The good thing about Cavaj Java Decompiler is, it doesn’t require you to have Java installed to use the decompiler and it is just a light weight stand-alone application. Cavaj Java decompiler uses Jad as its Java decompiling engine which makes the application light weight and handy. Check it out guyz.

How To Extract Fla Files From Flash Files With Swf Decompiler

2011-05-08T21:20:00.001-07:00

What is a decompiler? Some people may ask. Well, decompiling is a common technique used to reverse engineer compiled files (.swf files), in order to retrieve a representation of the original code. Flash decompiling has been around since the first decompiler (Action Script Viewer) was released in May 2000. At present, there are several tools on the market, such as Eltima Decompiler Trillix, ASV and Flare.Discretion should be used though because as with everything, it can be used for less honorable purposes ( i.e. plagiarizing assets and code). For this reason, the issue of decompiling is a contentious one.

To its defence, a decompiler can have many benefits. It can be a good way to sneak a peek at other peoples code and learn new techniques. Also, if youve lost an .fla and only have the swf at hand, its a good way to recover code, from which you can reconstruct the piece of original work. Phew, what a relief!

Then we should also learn something about the difference between SWF files and FLA files.

First of all, the SWF file is more like a large collection of FLA files. The SWF is a package that contains FLA file and any other files or content you used when making a flash project (Action Script codes, images, text, sounds, etc). If it is to compare SWF with another popular extension, you could say that the SWF it is like the EXE file. So, when we talk about FLA we talk about the core structure of a SWF file (the exact same thing as for Adobe Photoshop and its PSD files).

Now, extracting FLA from SWF is not as simple as it sounds and without a powerful tool it would be almost impossible. A poorly designed application can extract damaged FLA files, files which are absolutely impossible to use for a different purpose.

Recently I had come across SWF Decompiler/ SWF Decompiler for Mac. And after testing, I found that I was not wrong to expect a lot from this SWF Decompiler/ SWF Decompiler for Mac as the software itself provides plenty of features, tools and options. It's absolutely incredible as for how easy it is to convert a Flash video to FLA files.

This SWF Decompiler/ SWF Decompiler for Mac is fast, reliable and really important, affordable. Usually, similar applications are extremely expensive and a simple home user cannot afford them. Because of that, common users have to buy random SWF Decompiler/ SWF Decompiler for Mac (cheaper but also poorly designed). However, the time for random decompiler is over. This SWF Decompiler/ SWF Decompiler for Mac can solve all these problems for you in a simple and professional way.

So, I would like to strongly recommend this SWF Decompiler/ SWF Decompiler for Mac for those who need to convert and decompile SWF files.

Learn how to download applets and decompile Java class files

2011-05-08T21:19:00.000-07:00

Update
This article is a little old now, so I've started a new series (as of April, 2010) on Java decompilers and obfuscators. Please follow that link for much more recent information. The content below is kept here only for legacy reasons.

Introduction
In our previous article, we demonstrated a simple method that can be used to easily download the class files of Java applets. In this article we'll show you how to decompile the Java class, turning the .class file back into a .java source code file.

Why do this?
If you're just joining us in Part 2 of our series, I feel the need to explain why we're doing this series in the first place:

First, we're a Java educational center. Telling you the bad about Java as well as the good is also educational. Whether it's bad or good, it is truth. The fact is that other people can decompile your Java classes, and you need to know that, and it's helpful to know how they can do it.
Second, and even more importantly, if you know how to decompile Java classes, you can also learn how to try stop it (assuming you're interested in stopping it).

Obtaining software to decompile Java class files
To decompile a Java class file, you're going to need some software specially made for decompiling Java class files (also called reverse-engineering). In this article we're going to show you how to decompile Java class files with a software package that goes by the name of Mocha.

Mocha is probably not the best decompiling software available today, but it is one of the first packages available - if not the first - and it's also free. Mocha is written in Java, so you'll also need a copy of the Java JDK, or the JRE.

Step 1: Download Mocha
Assuming that you already have a copy of the Java JDK, the first step in the decompilation process is to download Mocha. Click here to download Mocha.

Step 2: Install Mocha
After you've downloaded Mocha, install it in a directory according to the installation instructions that came with the Mocha software. At the time of this writing, the installation process simply consists of unpacking a ZIP file into a desired directory.

Decompiling a Java class file
In this article we're going to decompile the AnimatedAd.class Java class file we downloaded in Part 1 of this article. If you're at all familiar with our web site, you might know that the original source code for this class file is also available. This is good, because it gives us a chance to compare the original source code to the decompiled version of the source code.

If you're ready, let's begin the process of decompiling the class file. If you've installed Mocha properly, there's really very little to the process other than running Mocha.

Step 1: Open a DOS or Unix window
Running Mocha is very simple. Assuming you're using a Windows system, just open a DOS window, and move to the directory where you installed Mocha.

If you're using a version of Unix, open a Unix command-line window and move to the Mocha installation directory.

Step 2: Modify your CLASSPATH variable
In this step, modify your CLASSPATH environment variable to include the Mocha.zip file you just downloaded and installed.

For instance, using Visual Cafe 2.5 on a Windows95 computer system, I modified my CLASSPATH to look like this:

set CLASSPATH=C:\Apps\Win95\Symantec\VisualCafe2.5\BIN\COMPONENTS\SYMBEANS.JAR;
C:\Apps\Win95\Symantec\VisualCafe2.5\JAVA\LIB\CLASSES.ZIP;
C:\Apps\Win95\Symantec\VisualCafe2.5\JAVA\LIB;
C:\Temp\DevDaily\Java\Decompilers\Mocha.zip

This should all be one continuous line. (Actually, because my CLASSPATH is so long, I cheated and combined this step and the command from Step 4 into a DOS batch file named runmocha.bat.)

Step 3: Copy the class file to the Mocha installation directory
If you haven't done so already, copy the AnimatedAd.class file into the Mocha installation directory.

Step 4: Run the Mocha program
Once the CLASSPATH is set, you can run Mocha like this to decompile the AnimatedAd.class file:

java -classpath %CLASSPATH% mocha.Decompiler -v AnimatedAd.class
Notice that I included the -v option (verbose) to see a little more output than normal. It's not required, but it is helpful.

When Mocha runs, you'll see some output on your screen similar to Figure 1.

Decompiling AnimatedAd.class -> AnimatedAd.mocha
Method init....................................................................
................................................................................
................................................................................
................................................................................
................................................................................
........................
Method start................
Method stop..............
Method run.....................................................................
.........................................................................
Method mouseDown...............
Method pause........
Method drawMyString..............
Method paint................
Method numStringsUsed.........................
Method getRandomInt.................................................
Method <init>.............................

The decompiled source code
When Mocha runs, it also creates an output file named AnimatedAd.mocha. This file contains the decompiled Java source code - the source code it created by reading the AnimatedAd.class binary file.

The AnimatedAd.mocha file is too large to list here, but you can click here to view the reverse-engineered source code.

As a point of comparison, you can click here to view the original AnimatedAd.java source code.

Summary
I hope you enjoyed this two-part series on downloading and decompiling Java applets. If you have any questions or comments, please leave them in the comments section below.

(Editor's Note: The process of decompiling Java class files belonging to other businesses or individuals may be illegal in your city, state, or country. Frankly, I don't know for sure, because, to coin a phrase from Star Trek's (TM) Doctor McCoy, "I'm an editor, not a lawyer." In any case, this series of articles is not written to encourage that practice. These articles are presented only so you can learn to protect your own Java class files from reverse engineering.)

Protect Your Java Code from Reverse Engineering

2011-05-08T21:18:00.000-07:00

If you are developing java application, it is important to understand that the java class files can be easily reverse engineered using java decompilers. In this article, let us explore how a java class file is reverse engineered and how to protect your source code from being reverse engineered by someone.

The java source code is compiled to a class file that contains byte code. Java Virtual Machine needs only the class file for execution. The problem is that the class file can easily be decompiled into the original source code using java decompiler tools. The best solution to prevent reverse engineering is to obfuscate the class file so that is will be very hard to reverse engineer. According to the dictionary Obfuscate means “to make obscure or unclear”. That is exactly what lot of java obfuscator tool will do as explained below.

I. Decompile Java class file.

Before understanding how to obfuscate the java code, let us first try to understand how someone can reverse engineer your java application. Following 3 steps explains how a class file is reverse engineered to the original java source code.

1. Create HelloWorld.java as shown below.

public class HelloWorld {
    public static void main (String args[]) {
        String userMessage = "Hello World!";
        int userCount = 100;
        userCount = userCount + 1;
        System.out.println(userMessage);
        System.out.println(userCount);
    }
}
2. Compile HelloWorld.java program and execute it to make sure it works properly.

$ javac HelloWorld.java
$ java HelloWorld
Hello World!
101
Java class file contains only byte code. If you try to view a class file, it will be non-readable as shown below.

$ vi HelloWorld.class
ÃÃ¾ÂºÂ¾^@^@^@2^@
^@^G^@^P^H^@^Q ^@^R^@^S
^@^T^@^V^G^@^W^G^@^X^A^@^F<init>^A^@^C()V^A^@^DCode^A^@^OLineNumberTable
^A^@^Dmain^A^@^V([Ljava/lang/String;)V^A^@
SourceFile^A^@^OHelloWorld.java^L^@^H^@ ^A^@^LHello World!^G^@^Y^L^@^Z^@^[^G^@^\^L^@^]^@^^^L^@^]^@^_^A^@
HelloWorld^A^@^Pjava/lang/Object^A^@^Pjava/lang/System^A^@^Cout^A^@^ULjava/io/PrintStream;^A
^@^Sjava/io/PrintStream^A^@^Gprintln^A^@^U(Ljava/lang/String;)V^A^@^D(I)V^@!^@^F^@^G^@^@^@^@^@^B^@^A^@^H^@ ^@^A^@

3. Decompile HelloWorld.class file and view the original source.

For this demonstration let us use Jad decompiler which is free for non-commercial use. Download the appropriate jad for your platform. Use jad to reverse engineer the HelloWorld.class file to get the original source as shown below.

$ unzip jadls158.zip
$ ./jad HelloWorld.class
Parsing HelloWorld.class...
Generating HelloWorld.jad
$ vi HelloWorld.jad <This will show the reverse engineered original source code>
II. Obfuscate your java application

Let us review how to obfuscate and protect your source code from reverse engineering using ProGuard a free GPL licensed software.

1. Download and Install ProGuard

$ cd /home/jsmith
$ unzip proguard4.2.zip
2. Create a proguard config file

Create myconfig.pro that contains all the information about your java application.

-injar : Specify the location of your jar file. i.e the compiled java application that contains the class files
-outjar: This is the jar file proguard will create after obfuscation. This will contain all the mangled, obscure naming convention of the methods and variables in the class file if someone tries to reverse engineer.
-printmapping: ProGurad outputs all the mapping information in this file for your reference.
-keep: Indicate the class files or the methods that you don’t want ProGuard to obfuscate. For e.g. mypkg.MainAppFrame contains the entry point for the application with the main class, which will not get obfuscated in this example.
$ cat myconfig.pro
-injars /home/jsmith/myapp.jar
-outjars /home/jsmith/myapp-obfuscated.jar This is the obfuscated jar file
-libraryjars /usr/java/jdk1.5.0_14/jre/lib/rt.jar
-printmapping proguard.map
-verbose
-keep public class mypkg.MainAppFrame
3. Execute ProGuard.

$ cd /home/jsmith/proguard4.2/lib
$ java -jar proguard.jar @myconfig.pro
This creates the following two files:

myapp-obfuscated.jar: Contains the obfuscated class files of your application. You can distribute this without having to worry about someone reverse engineering your application easily.
proguard.map: This file contains the mapping information for your reference.
4. Sample proguard.map file

This is a sample proguard.map file that indicates the original name of the java source objects (classfile, methods, variable etc.) and the new obfuscated name.

myapp.AppToolBar -> myapp.ae:
javax.swing.JButton btnNew -> d
javax.swing.JButton btnOpen -> e
5. Sample java source code (myapp.AppToolBar) before obfuscation.

btnNew = changeButtonLabel(btnNew, language.getText("new"));
btnOpen = changeButtonLabel(btnOpen, language.getText("open"));
6. Sample java source code that was decompiled from the class file (myapp.ae) after obfuscation.

d = a(d, n.a("new"));
e = a(e, n.a("open"));
You can see that the line “btnNew = changeButtonLabel(btnNew, language.getText(“new”));” got translated to “d = a(d, n.a(“new”));”, by the ProGuard, which will not make any sense to someone who is using java decompiler tools to reverse engineer the class file.

Java Decompilers

2011-05-08T21:16:00.000-07:00

This article isn't anwhere near current but is still valid as general commentary on java decompilers. I'm not planning to re-review the modern crop, but I will note new programs as I become aware of them.

and are they worth worrying about

Generally, the object of decompiler is to accept a java .class file as input, and produce a compilable source file as its result. In the chaotic world of software development there are many reasons, legitimate and otherwise, to wish for such a tool. The transparent and information-rich structure of java .class files, which makes Java's dynamic linking so much better than previously common models, also makes such tools particularly easy to build.
What tools are available?

All of these tools are pure java, so the essential distribution consists of a java class library and instructions to invoke it. They're all a littly quirky to set up and use, a characteristic shared by many standalone java applications. Once set up, they more or less "just work", producing output that is nearly ready for the compiler.
Mocha is free. Unfortunately, its author is prematurely deceased, and its future as a product is in doubt.
WingDis, is a product of Wing Software. A "crippleware" demo is available. [April 2002, still available and supported]
DejaVu, is distributed as part of the OEW developement environment, but appears to be completely independant of it. OEW is available as a free trial, and DeJaVu continues to be functional when the trial has expired. I've reviewed OEW separately.
[April 2002, Open source decompiler Jreverse Pro]
Testing method

I chose a small utility library, consisting of about 15 classes, as my standard test set. I compiled the library using JDK 1.02, with -o and without -g. I decompiled with all three decompilers, then manually edited the decompiled sources until they could be successfully recompiled. I then decompiled these three sets of "second generation" binaries, with each of the three decompilers, yielding nine sets of "third generation" sources. I then manually compared various pairs of sources, looking for inconsistancies which might indicate incorrectly decompiled code. Since this was a "only a test", I had the luxury of referring to the original sources, and the double luxury that I wrote these sources myself; two advantages that would not generally be available to anyone using a decompiler in earnest.
The test set was not specifically designed to validate or torture decompilers, and there is no way to know if the results here are representative of all classes, or if the list of problems encountered is complete. It should, however, give you some idea what to watch for.

I organized decompilation errors according to the taxonomy below, based on the general idea that easy-to-spot and easy-to-fix errors were less significant than hidden or hard to fix errors. The very worst thing a decompiler can do is produce code that passes through a compiler without complaint, but which is not functionally equivalent to the original code.

Error Taxonomy
	Class 1 errors	Class 2 errors	Class 3 errors	Class 4 errors	Class 5 errors	Class 6 errors
general description	flagged by compiler, easily fixed	flagged by compiler, not easily fixed.	Ugly, Incomprehinsible, but correct code.	Suble misprints. Subtly Incorrect programs	Total failure.	Gross errors Severly damaged semmantics No warning, and hard to identify
example	boolean variable incorrectly identified as intmissing, but trivial type cast.	generating code containing goto	unreconstructed flow conrolunreconstructed use of + for string append	failing to use \ to escape characters in string constantsmisprinting character constants	crash without producing output	misuse or non-use of "this."other patently incorrect code

Decompiler Errors by type
	Class 1 errors	Class 2 errors	Class 3 errors	Class 4 errors	Class 5 errors	Class 6 errors
Mocha version beta 1	a few	no	no	no	yes, mocha crashes on some class files.	no
WingDis version 2.06	just one	no	overuse of if(x!=false) and similar construction	no	no	misuse or non-use of of "super." mistranslation of x=a++; to a++; x=a;
DeJaVu version 1.0	a few	no	major problem with flow analysis	yes	no	no

CONTENTS Introduction Bytecode Encryption- Straightforward But Totally Flawed Name Obfuscation String Encryption Code and Data Flow Obfuscation Strengthening Protection with Ahead-Of-Time Compilation Popular Obfuscators Further Reading Appendices: Obfuscation Examples Impact of Flow Obfuscation on Performance Protect Your Java Code - Through Obfuscators And Beyond

2011-05-08T21:15:00.000-07:00

Reverse engineering of your proprietary applications by unfair competition or malicious hackers may result in highly undesirable exposure of your algorithms and ideas, proprietary data formats, licensing and security mechanisms, and, most importantly, your customer's data. Here is why Java is particularly weak in this respect compared to C++:

Target Instruction Set
C++: Compiles to a low-level instruction set that operates on raw binary data and is specific to the target hardware, such as x86 or PowerPC	Java: Compiles to a higher-level portable bytecode that operates on classes and primitive types.
Compiler Optimizations
C++: Numerous code optimizations are performed at compile time. Inline substitution results in copies of the given (member) function being scattered around the binary image; use of the preprocessor combined with compile-time evaluation of expressions may leave no trace of the constants defined in the source code; and so on.	Java: Relies on dynamic (Just-In-Time) compilation for performance improvement. The standard `javac`compiler is straightforward, it does no compile time optimizations commonly found in C++ compilers. The idea is to enable the JIT compiler to perform all optimizations at run time, taking the execution profile into account.
Linkage
C++: Programs are statically linked, and metaprogramming facilities (reflection) are absent in the core language. So the names of classes, members, and variables need not be present in the compiled and linked program, except for names exported from dynamic libraries (DLLs/shared objects.)	Java: Dependencies are resolved at run time, when classes are loaded. So the name of the class and names of its methods and fields must be present in a class file, as well as names of all imported classes, called methods, and accessed fields.
Delivery Format
C++: An application is delivered as a monolithic executable (maybe with a few dynamic libraries), so it is not easy to identify all member functions of a given class or reconstruct the class hierarchy.	Java: An application is delivered as a set of jar files, which are just non-encrypted archives containing individual classes.

As a result, the decompilation of Java programs is a much simpler task compared to C++ and therefore may be fully automated. Class hierarchy, high-level statements, names of classes, methods and fields - all this can be retrieved from class files emitted by the standard javac compiler. Any person of ordinary skills in programming can download a Java decompiler, run your program through it and read the source code almost as if it was open source.

Let's see what can be done to prevent that.

Java Decompiler New features in version 3.11.11.95

2011-05-08T21:14:00.000-07:00

Java Annotation support. RuntimeVisibleAnnotations, RuntimeInvisibleAnnotations, RuntimeVisibleParameterAnnotations, and RuntimeInvisibleParameterAnnotations attributes are supported.
Improvements and many new features in "View" - "Attributes", "Methods, Interfaces and Constant Pool" and "Fields" forms. Added search capabilities in "Methods" and "Constant Pool" tabs. Specific information for attributes is available and annotations are displayed in Treeview. "Save to file" option added. Bugfix in "Exception Table" tab. "Attributes" form gives a complete description of all ClassFile attributes. Additional "Fields" tab is added.
Added a new search tool "Search for files inside compressed archives" (.JAR, .ZIP, .WAR, .EAR and .APK). This tool enables users to search for files by file name and a word or phrase in the file. The results list can be sorted by clicking at column header and includes detailed information about files.
Added a new tool "Imports Viewer". Lists import statements of selected class file.
Added a new tool "Methods Viewer". Shows the methods of selected class file with sorting capabilities. Lists access_flags, descriptors, method signatures, attributes and code length. The results list can be exported to tab-delimited text file.
Added capability to calculate .DEX file signature and checksum with "CRC MD5 SHA-1 Calculator" tool. Users can also calculate the Adler-32 and SHA-256 hashes of a file or string.
Improvements in "Export to HTML". Compared to the previous version - it is much more powerful now. Unicode conversion allows multi-language documents.
Added a drag-and-drop functionality in "Archiver" tool.
Added a "Tree View" button in "Archiver". Shows the selected archive (.jar, .zip, .war, .ear, .apk) in Treeview with export to .XML capability.
Added a "Whole class tree" option in "Decompile more files" tool. Decompiles all .class files located in all subdirectories of the selected directory and creates output files in subdirectories of the destination folder according to package names of classes.
"Browse for files" button added in "Run" tool. Useful to pass the file names as arguments to the main() method.
Bugfixes in syntax highlighting.

Java Decompiler

2011-05-08T21:05:00.000-07:00

Introduction

The “Java Decompiler project” aims to develop tools in order to decompile and analyze Java 5 “byte code” and the later versions.

JD-Core is a library that reconstructs Java source code from one or more “.class” files. JD-Core may be used to recover lost source code and explore the source of Java runtime libraries. New features of Java 5, such as annotations, generics or type “enum”, are supported. JD-GUI and JD-Eclipse include JD-Core library.

JD-GUI is a standalone graphical utility that displays Java source codes of “.class” files. You can browse the reconstructed source code with the JD-GUI for instant access to methods and fields.

JD-Eclipse is a plug-in for the Eclipse platform. It allows you to display all the Java sources during your debugging process, even if you do not have them all.

JD-Core, JD-GUI and JD-Eclipse are free for non-commercial use. This means that JD-Core, JD-GUI and JD-Eclipse shall not be included or embedded into commercial software products. Nevertheless, these projects may be freely used for personal needs in a commercial or non-commercial environments.

Main Features

JD-Core and JD-GUI are written in C++. This allows an extremely fast decompilation and a display.
JD-Core does not require the Java runtime environment for its functioning, therefore no special setup is required.
JD-Core works with most current compilers including the following:
jdk1.1.8
jdk1.3.1
jdk1.4.2
jdk1.5.0
jdk1.6.0
jdk1.7.0
jikes-1.22
harmony-jdk-r533500
Eclipse Java Compiler v_677_R32x, 3.2.1 release
jrockit90_150_06
JD-Core supports the following new features of Java 5:
Annotations
Generics
Type “enum”
JD-GUI supports Drag and Drop.
JD-GUI supports JAR files.
JD-GUI displays color coded Java source code.
JD-GUI allows you to browse the “class” files hierarchy.
JD-GUI displays “log” files, and allow you to decompile “class” files appearing in Java stack traces.
JD-Core, JD-GUI and JD-Eclipse use the excellent cross-platform wxWidgets toolkit.

Packaging and Distributing Java Desktop Applications

2011-04-18T06:15:00.001-07:00

Creating Executable JAR File

This part of the tutorial shows how you can create a distributable application in the IDE and then run that application from outside of the IDE. We will package the application in the form of an executable JAR file.

A JAR file is an archive file that can contain multiple files and folders. JAR files are similar to zip files, but JAR files can have additional attributes that are useful for distributing Java applications. These attributes include digitally signing JAR files, additional compression, multiplatform compatibility, etc.

In this exercise, you create an IDE project and then place two pre-written Java source files into that project. Then you will compile the classes and build an executable JAR file. Afterwards, you will learn how to run the JAR file from outside of the IDE.

The classes used in this tutorial implement features of the GNU grep utility, which can be used for searching text or regular expression patterns inside text files. The project contains both command-line and GUI versions of the application, so that you can see different ways of running the application.

Creating a Project with Existing Sources

Download the DeploymentTutorial.zip file and extract its contents on your system.
This zip archive contains source files for the application plus a few other files that will be used in the tutorial.
In NetBeans IDE, choose File > New Project.
In the Choose Category page, select Java Project With Existing Sources in the Java category and click Next.
On the Name and Location page of the wizard, type AnotherGrep as the project name and specify the project's location.
Leave the Set as Main Project checkbox selected and click Next.
The project folder does not have to be in the same location as the source files that you are importing into the project.
On the Existing Sources page of the wizard, specify the sources that will be in the project.
Click the Add Folder button that is to the right of the Source Package Folders field. Navigate to the DeploymentTutorial folder that you have just unzipped on your system, expand the folder, select the src folder, and click Open. The src folder is added to your Source Package Folders field.
Click Finish.
Note: If, for example, you want to exclude some source files from importing into the project, click Next to open the last Includes & Excludes window. In our case, we want to use all the source files in the src folder, so we click Finish to finish working in the New Project wizard.

The project opens in the IDE and becomes visibile in the Projects window. You can explore the contents of the project by expanding the project's Source Packages node, where you should see classes called Grep and xGrep. Grep.java is a console version of the application. xGrep.java is a GUI version of the application and uses methods defined inGrep.java.

Configuring the Project

There are a few configuration steps you need to do, such as:

Choose the Java platform that will be used to compile the sources.
Set the project's main class. By doing this, you ensure that the JAR file that you create when you build the project is executable.

Verifying the Java Platform

Our project needs to be compiled and run on Java 6 platform. Therefore, you need to make sure that Java 6 is used as the platform for this project.

Right-click the project's node and choose Properties.
On the Libraries tab, ensure that the Java Platform is JDK 6.
On the Sources tab, choose JDK 6 in the Source/Binary format.
Click OK to close the Properties window.

Setting the Main Class

In order for a user to easily run your JAR file (by double-clicking the JAR file or by typing java -jar AnotherGrep.jar at the command line), a main class has to be specified inside the JAR's manifest file. (The manifest is a standard part of the JAR file that contains information about the JAR file that is useful for the java launcher when you want to run the application.) The main class serves as an entry point from which the java launcher runs your application.

When you build a project, the IDE builds the JAR file and includes a manifest. When you set the project's main class, you ensure that the main class is be designated in the manifest.

To set the project's main class:

Right-click the project's node and choose Properties.
Select the Run panel and enter anothergrep.xGrep in the Main Class field.
Click OK to close the Project Properties dialog box.

When you build the project later in this tutorial, the manifest will be generated and include the following entry:

 Main-Class: anothergrep.xGRep

Building the Project and Creating the JAR File

Now that you have your sources ready and your project configured, it is time to build your project.

To build the project:

Choose Run > Build Main Project.
Alternatively, right-click the project's node in the Projects window and choose Build.

When you build your project:

build and dist folders are added to your project folder (hereafter referred to as the PROJECT_HOME folder).
All of the sources are compiled into .class files, which are placed into the PROJECT_HOME/build folder.
A JAR file containing your project is created inside the PROJECT_HOME/dist folder.
If you have specified any libraries for the project (in addition to the JDK), a lib folder is created in the dist folder. The libraries are copied into dist/lib.
The manifest file in the JAR is updated to include entries that designate main class and any libraries that are on the project's classpath.

Note: You can view the contents of the manifest in the IDE's Files window. After you have built your project, switch to the Files window and navigate todist/AnotherGrep.jar. Expand the node for the JAR file, expand the META-INF folder, and double-click MANIFEST.MF to display the manifest in the Source Editor.

 Main-Class: anothergrep.xGrep

(To find more about manifest files, you can read this chapter from the Java Tutorial.)

Running and Distributing the JAR File

Running the Application Inside of the IDE

When developing applications in the IDE, typically you will need to test and refine them before distributing. You can easily test an application that you are working on by running the application from the IDE.

To run the AnotherGrep project in the IDE, right-click the project's node in the Projects window and choose Run.

The xGrep window should open. You can click the Browse button to choose a file in which to search for a text pattern. In the Search Pattern field, type text or a regular expression pattern that you would like to match, and click Search. The results of each match will appear in the xGrep window's Output area.

Information on regular expressions that you can use in this application are available here and in many other places.

Running the Application Outside of the IDE

Once you have finished developing the application and before you distribute it, you will probably want to make sure that the application also works outside of the IDE.

You can run the application outside of the IDE by following these steps:

In your system's file manager (for example, in the My Computer window on Windows XP systems), navigate to PROJECT_HOME/dist and double-click the AnotherGrep.jarfile.

You will know that the application has started successfully when the xGrep window opens.

If the xGrep window does not open, your system probably does not have a file association between JAR files and the Java Runtime Environment. See Troubleshooting JAR File Associations below.

Distributing the Application to Other Users

Now that you have verified that the application works outside of the IDE, you are ready to distribute it.

Send the application's JAR file to the people who will use the application. The users of your application should be able to run it by double-clicking the JAR file. If this does not work for them, show them the information in the Troubleshooting JAR File Associations section below.

Note: If your application depends on additional libraries other than those included in JDK, you need to also include them in your distribution (not the case in our example). The relative paths to these libraries are added in the classpath entry of the JAR's manifest file when you are developing your applicaiton in the IDE. If these additional libraries will not be found at the specified classpath (i.e., relative path) at launch, the application will not start.
Create a zip archive that contains the application JAR file and the library and provide this zip file to users. Instruct the users to unpack the zip file making sure that the JAR file and libraries JAR files are in the same folder. Run the application JAR file.

Starting Your Java Application

The goal of this exercise is to show you some ways that you can start your application from the command line.

This exercise shows you how you can start a Java application in the following two ways:

Running the java command from the command line.
Using a script to a call a class in the JAR file.

Launching Applications From the Command Line

You can launch an application from the command line by using the java command. If you want to run an executable JAR file, use the -jar option of the command.

For example, to run the AnotherGrep application, you would take the following steps:

Open a terminal window. On Microsoft Windows systems, you do this by choosing Start > Run, typing cmd in the Open field, and clicking OK.
Change directories to the PROJECT_HOME/dist folder (using the cd command).
Type the following line to run the application's main class:
```
 java -jar AnotherGrep.jar
```

If you follow these steps and the application does not run, you probably need to do one of the following things:

Include the full path to the java binary in the third step of the procedure. For example, you would type something like the following, depending on where your JDK or JRE is located:
```
 C:\Program Files\Java\jdk1.6.0_23\bin\java -jar AnotherGrep.jar
```
Add the Java binaries to your PATH environment variable, so that you never have to specify the path to the java binary from the command line. See Setting the PATH Environment Variable.

Launching Applications From a Script

If the application that you want to distribute is a console application, you might find that it is convenient to start the application from a a script, particularly if the application takes long and complex arguments to run. In this section, you will use a console version of the Grep program, where you need to pass the arguments (search pattern and file list) to the JAR file, which will be invoked in our script. To reduce typing at the command line, you will use a simple script suitable to run the test application.

First you need to change the main class in the application to be the console version of the class and rebuild the JAR file:

In the IDE's Projects window, right-click the project's node (AnotherGrep) and choose Properties.
Select the Run node and change the Main Class property to anothergrep.Grep (from anothergrep.xGrep). Click OK to close the Project Properties window.
Right-click the project's node again and choose Clean and Build Project.

After completing these steps, the JAR file is rebuilt, and the Main-Class attribute of the JAR file's manifest is changed to point to anothergrep.Grep.

Java Web Start

2011-04-18T06:14:00.001-07:00

Java Web Start (JWS) and the underlying Java Network Launch Protocol (JNLP) enable Java application delivery from a standard Web server. The end user initiates application installation by clicking on an URL. If the Java Web Start engine is not present on the system, the user is prompted to download and install it. Once Java Web Start is in place, clicking on the same URL will initiate the application download and installation procedures. It may involve download and installation of the required version of the JRE and Optional Packages. Upon their successful completion, the application is launched. The application will be cached on the user's system so next time the user clicks on the same URL, the JWS engine will launch the local copy of the application from the cache, if it detects that the computer is offline or the application was not updated on the Web site.

Another important feature of JWS is its ability to run your application in asandbox - a restricted container based on Java security architecture. But, unlike an applet, your application can gain access to local system resources like the filesystem, printer and system clipboard using the JNLP API even if it comes from an untrusted environment, after prompting the user for confirmation.

Java Web Start is available for Windows, Linux, and Solaris, and is part of MacOS X since v10.1. There are also third-party implementations of the JNLP protocol, some of them also include tools that assist you in the creation and maintenance of JNLP packages.

That was the bright side. Now, what is not so good about JNLP? First off, for seamless operation both the browser and the Web server that hosts the JNLP-enabled application must support application/x-java-jnlp-file MIME type. Some hosting providers do not support it. Moreover, versioning and incremental updates require additional support from the Web server, which has to be implemented using servlets, cgi-bin scripts, etc.

On the client side, a major browser would be configured to recognize the above MIME type during installation of the JWS engine, but users of less popular browsers, such as Opera, may have to do that manually.

JNLP-enabling an application may involve minor changes in its code and (re)packaging it into a set of jar files.

Before J2SE 5.0, JWS had very little to offer in terms of desktop integration - all it could do was create a desktop icon and/or a Start Menu entry for the application. On Windows, the application will not show up in Add/Remove Programs, so end users would have to run the Java Web Start application manager in order to remove your application.

Finally, JWS user interface needs much polishing. As of J2SE 5.0, users still complain about ugly windows with incomprehensible messages.

To sum it up, JWS can be a viable option in a controlled environment, such as corporate intranet, but it is not ready for the consumer market, where you may be better off using

Advanced Debugging

2011-04-18T06:13:00.001-07:00

Skip all breakpoints

If you want to temporary de-activate all your breakpoints you can press the button "Skip all breakpoints" which is visible if you select the tab breakpoints.

If you press this button again the breakpoints will get activated again.

4.2. Breakpoint Properties

After setting a breakpoint you can select the properties of the breakpoint to for example use a condition to restrict when the breakpoint should get toggeled. In the properties you can for example restrict that the breakpoint should only be executed the 12 hit (Hit Count) or you can put in a conditional expression (which you can also use for logging if you want).

4.3. Watchpoint

A watchpoint is a breakpoint at which is stop whenever a field read or changed. You can set a watchpoint through a double-click on the left side before the field declaration. Via the properties of the watchpoint you can define if the breakpoint should be hit during read access (Field Access) or during write access (Field Modification).

4.4. Exception Breakpoint

The application is stopped if the specified exception is thrown. To define an exception breakpoint click on the following icon.

You can define if you want to stop and caught and / or uncaught exceptions.

4.5. Method Breakpoint

A method breakpoint is defined via double-click in the left border of the editor and the method head. You can define if you want to stop the program during method entry of after leaving the method.

4.6. Class breakpoint

A Class Load Breakpoint will stop when the class is loaded. Right-click on a class in the Outline View and choose "Toggle Class Load Breakpoint"

4.7. Hit Count

For every breakpoint you can define via the properties the hit count. If you use the hit count then the application is stop then the breakpoint is reached the number of times defined in the hit count.

4.8. Drop to frame

Eclipse allows you to select any level (frame) in the call stack during debugging and set the JVM to restart to that point.

This allows you to rerun a part of your program. Be aware that variables which have been modified by the code which you reset remain modified. The drop to frame will return to the the code. Changes made by the code, e.g. to variables / databases will not be reset.

To use the feature select the level in your stack and press the highlighted button.

Add dynamic Java code to your application

2011-04-18T06:12:00.002-07:00

JavaServer Pages (JSP) is a more flexible technology than servlets because it can respond to dynamic changes at runtime. Can you imagine a common Java class that has this dynamic capability too? It would be interesting if you could modify the implementation of a service without redeploying it and update your application on the fly.

The article explains how to write dynamic Java code. It discusses runtime source code compilation, class reloading, and the use of the Proxy design pattern to make modifications to a dynamic class transparent to its caller.

An example of dynamic Java code

Let's start with an example of dynamic Java code that illustrates what true dynamic code means and also provides some context for further discussions. Please find this example's complete source code in Resources.

The example is a simple Java application that depends on a service called Postman. The Postman service is described as a Java interface and contains only one method, deliverMessage():

 public interface Postman {     void deliverMessage(String msg); }

A simple implementation of this service prints messages to the console. The implementation class is the dynamic code. This class,PostmanImpl, is just a normal Java class, except it deploys with its source code instead of its compiled binary code:

 public class PostmanImpl implements Postman {
  
    private PrintStream output;          public PostmanImpl() {         output = System.out;     }          public void deliverMessage(String msg) {         output.println("[Postman] " + msg);         output.flush();     } }

The application that uses the Postman service appears below. In the main() method, an infinite loop reads string messages from the command line and delivers them through the Postman service:

 public class PostmanApp {
  
    public static void main(String[] args) throws Exception {         BufferedReader sysin = new BufferedReader(new InputStreamReader(System.in));
 
        // Obtain a Postman instance         Postman postman = getPostman();
 
        while (true) {             System.out.print("Enter a message: ");             String msg = sysin.readLine();             postman.deliverMessage(msg);         }     }
 
    private static Postman getPostman() {         // Omit for now, will come back later     }  }

Execute the application, enter some messages, and you will see outputs in the console such as the following (you candownload the example and run it yourself):

 [DynaCode] Init class sample.PostmanImpl Enter a message: hello world [Postman] hello world Enter a message: what a nice day! [Postman] what a nice day! Enter a message:

Everything is straightforward except for the first line, which indicates that the class PostmanImpl is compiled and loaded.

Now we are ready to see something dynamic. Without stopping the application, let's modify PostmanImpl's source code. The new implementation delivers all the messages to a text file, instead of the console:

 // MODIFIED VERSION public class PostmanImpl implements Postman {
 
    private PrintStream output;          // Start of modification     public PostmanImpl() throws IOException {         output = new PrintStream(new FileOutputStream("msg.txt"));     }     // End of modification
 
    public void deliverMessage(String msg) {         output.println("[Postman] " + msg);
 
        output.flush();     } }

Shift back to the application and enter more messages. What will happen? Yes, the messages go to the text file now. Look at the console

JDK 7 Support in NetBeans IDE 7.0:

2011-04-18T06:12:00.001-07:00

To enable JDK 7 support in the NetBeans IDE:

Download the JDK 7 binary for your platform from this page.
This is the latest promoted development build.
Install JDK 7 on your system.
In the IDE, choose Tools > Java Platforms from the main menu.
Click Add Platform and specify the directory that contains the JDK (e.g. on Windows, this is the JDK installation directory, default is C:\Program Files\Java\jdk1.7.0).
The directory that contains the Java platform is marked with the icon.
In the Platform Name step, verify that the default locations of the Platform Sources zip file and API documentation are valid.
Click Finish to close the Add Java Platform dialog box.
Ensure JDK 1.7 is chosen in the Platforms list and click Close.

Configuring the Project to Use JDK 7

Once you have registered JDK 7 in the IDE, you need to configure your project to use this JDK for compilation, running, and debugging.

Create a Java project. Choose File > New Project and select Java Application as the project type. Click Next.
Type SwitchTest as the project name and specify its location.
In the Files window, right-click the SwitchTest project's node and choose Properties > Libraries. On this tab, choose JDK 1.7 from the list of Java Platforms.
Switch to the Sources tab of the Project Properties window and choose JDK 7 as the Source/Binary Format.
Click OK to save changes. Your project is set to recognize new JDK 7 language features.

Using New JDK 7 Language Constructs: Switch Statement

JDK 7 brings a number of new features and enhancements in different areas, including internationalization, I/O and networking, security, etc. The best way to illustrate the JDK 7 support by the IDE's Java Editor is to demonstrate a few language changes introduced by Project Coin.

One of these changes is a "String in a switch". In the previous versions of Java, the argument of switch had to be only of the following primitive data types: byte, short, char,int, or enum. Starting from JDK 7, you can use arguments of type String in the expression of a switch statement.

Open SwitchTest.java and add the following code. This small sample displays RGB codes for several colors.
With JDK 7, the color variable can be a String.

 package switchtest;      public class SwitchTest {      public static void main(String[] args) {          String color = "red";         String colorRGB;         switch (color.toLowerCase()) {             case "black": colorRGB = "000000"; break;             case "red": colorRGB = "ff0000"; break;             case "green": colorRGB = "008000"; break;             case "blue": colorRGB = "0000ff"; break;             default: colorRGB = "Invalid color"; break;         }         System.out.println(colorRGB);         }     }

If the pasted code is formatted incorrectly in the editor, press Alt-Shift-F to reformat.

In the Files window, right-click the project's node and choose Run. You will see the output of the application, which is the RGB code for the red color.
You can see that the build is successful and the application works when the target platform and source format is JDK 7.
Let's rollback to using JDK 6 and test how the application is complied with the JDK 6 compiler.
In the Files window, right-click the project's node and choose Properties. On the Libraries tab, set the Java Platform to JDK 1.6 and on the Sources tab, set the Source Format option to JDK 6.
You can immediately see that the JDK6 parser does not recognize the syntax. The compilation fails because of the incompatible variable type.
Now, let's rewrite the code using the if-then-else statement instead of switch as shown in the picture.
With JDK 7 being the target platform, the IDE recognizes such cases and offers you to convert them to switch.
Click the hint and the if-then-else construct will be automatically converted to exactly the same switch that we had before.
Run the application with different values.

JDK 7 Support: More Examples

To demonstrate how the IDE's Java Editor recognizes and automatically fixes code to be compliant with the JDK 7 language spec, let's use a dummy code snippet, which is meaningless but contains all the major language improvements.

When walking through this dummy code snippet and applying editor hints, you will see the following examples of how to:

Take advantage of automatic type inference, when the Java compiler is able to infer the type of a generic instance without the need to explicitly specify it. The so-calleddiamond operator is used to flag the type inference case.
Use improved exception handling or multi-catch, when one catch block can be used for several types of exceptions.
Use the new syntax of resource closure statements introduced by the Automatic Resource Management feature.

Replace the previous application code in the same SwitchTest.java file with the following

 package switchtest;   import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.util.ArrayList; import java.util.HashMap; import java.util.List;   public class SwitchTest {       public static void main(String[] args) throws IOException {         List list = new ArrayList();         HashMap map = new HashMap();         HashMap map2 = new HashMap();         String a = "ehlo";          try {             throw new FileNotFoundException("adasdf");         } catch (FileNotFoundException fnfo) {             fnfo.printStackTrace();         } catch (IOException ioe) {             ioe.printStackTrace();         }          FileInputStream in = null;         try {             in = new FileInputStream("foo.txt");              int k;             while ((k = in.read()) != -1) {                 System.out.write(k);             }         } finally {             if (in != null) {                 in.close();             }         }     } }

Note that the IDE displays several hints of how you can optimize your code for the JDK 7 spec. Simply, click on each hint and select the suggested action.
Finally, after you accept all the suggestions, you should receive the JDK 7 compatible code that is similar to the one shown below.

Convert Java to EXE

2011-04-18T06:10:00.001-07:00

f you are sure you need a real EXE, go straight to AOT Compilers.

"How do I make an .EXE file from my Java application?", "Need help converting jar to exe", "Is it possible to create a Windows executable using Java?" --- these and similar questions are among the most popular topics on Java developer forums. Should you start such a topic today, you are likely to encounter the following three types of replies:

"You cannot"
"You should not, because that would kill the very purpose of Java"
"You can do that with third party software X and Y"

The truth is that there exist two completely different approaches to the creation of native executables from Java applications, addressing different sets of problems. Moreover, under certain conditions some of those problems may be solved without making an EXE. So the most correct way to reply to such a post would be a request for more information, namely what is the goal of conversion to EXE. And the most frequent answer would be

Debug

2011-04-18T06:09:00.001-07:00

Setting Breakpoints

To set breakpoints right click in the small left column in your source code editor and select toggle breakpoint. Or you can double click on this place.

3.2. Starting the Debugger

You can debug your application with selecting your Java file which contains a main method, right click it and select Run -> Debug.

Tip

If you have not defined any breakpoints this will run your program as normal. To debug the program you need to define breakpoints.

If you start the debugger the first time Eclipse will asked you if you want to switch to the debug perspective. Answer "yes", you should then see a perspective similar to the following.

You can use F5 / F6, F7 and F8 to step through your coding.

Table 1. Debugging Key bindings

Command	Description
F5	Goes to the next step in your program. If the next step is a method / function this command will jump into the associated code.
F6	F6 will step over the call, e.g. it will call a method / function without entering the associated code.
F7	F7 will go to the caller of the method/ function. So this will leave the current code and go to the calling code.
F8	Use F8 to go to the next breakpoint. If no further breakpoint is encountered then the program will normally run.

You can of course use the ui to debug. The following displays the keybindings for the debug buttons.

3.3. Stack

The current stack is displayed in the "Debug" view.

3.4. Variables

The view "Variables" displays fields and local variables from the current stack.

Use the menu to display static variables.

Via the menu you can also customize the displayed columns, e.g. you can show the acutual and the declared type.

Another nice feature is the the "New Detail Formater" in which you can define how a variable is displayed. For example the toString method in our counter shows something meaningless, e.g. "de.vogella.debug.first.Counter@587c94". Use right mouse click on the variable -> "New Details Formater"

Maintain the following code to get the output "0" (or whatever is field result holds at this point).

Sending Email From Your Application Using Java Mail

2011-04-18T06:08:00.001-07:00

Now a Day's informing the Clients about the successful updation of data or sending other automated information form your Java Programs, either from your Servlets or from your Applications has become a requirement, more than a feature. Here we show how to use the Java Mail API to send a Mail. To Test Program all you need to have is a SMTP address (Which your ISP Provides).

Before Using this Program, you need to have Javasoft's JavaMail class files which can be downloaded from here http://www.javasoft.com/products/javamail/index.html

You will also need the JavaBeans^TM Activation Framework extension or JAF (javax.activation). It is available at http://java.sun.com/beans/glasgow/jaf.html.

import javax.mail.*;
import javax.mail.internet.*;
import java.util.*;

public void postMail( String recipients[ ], String subject, String message , String from) throws MessagingException
{
    boolean debug = false;

     //Set the host smtp address
     Properties props = new Properties();
     props.put("mail.smtp.host", "smtp.jcom.net");

    // create some properties and get the default Session
    Session session = Session.getDefaultInstance(props, null);
    session.setDebug(debug);

    // create a message
    Message msg = new MimeMessage(session);

    // set the from and to address
    InternetAddress addressFrom = new InternetAddress(from);
    msg.setFrom(addressFrom);

    InternetAddress[] addressTo = new InternetAddress[recipients.length];
    for (int i = 0; i < recipients.length; i++)
    {
        addressTo[i] = new InternetAddress(recipients[i]);
    }
    msg.setRecipients(Message.RecipientType.TO, addressTo);

// Optional : You can also set your custom headers in the Email if you Want
msg.addHeader("MyHeaderName", "myHeaderValue");

    // Setting the Subject and Content Type
    msg.setSubject(subject);
    msg.setContent(message, "text/plain");
    Transport.send(msg);
}

To Send a Email, from your Program, just call the above method, With the following parameters,

String to -- Email Address of the Recipient

String subject -- Email Subject

String message -- Content or Body of the Message

String from -- Your (Senders) Email Address

smtp.jcom.net -- Replace this with your ISP's SMTP address.

That's it, you are all set to send a Email.

Deploying Wireless Java Applications

2011-04-18T06:07:00.003-07:00

Developers usually build, test, and evaluate an application on a platform similar to the one on which it will be deployed and run. Development of wireless Java applications is more challenging because they typically are developed on one platform (such as Solaris or MS Windows) but deployed on a totally different one (such as a cell phone or PDA). One consequence is that, while emulators enable developers to do some of their testing on the development platform, ultimately they must test and evaluate the application in the very different environment of a live wireless network.

The aim of this article is to show you the different ways you can download local and network applications to J2ME-enabled devices, for both testing and final deployment. After a brief review of wireless Java applications and their development life-cycle, the article shows you how to:

Deploy wireless applications remotely
Download local and remotely deployed applications
Download applications over the air

Wireless Java Applications

Wireless Java applications fall into two broad categories:

Local applications (also called stand-alone applications) perform all their operations on a handheld wireless device and need no access to external data sources through a wireless network. Examples include calculators and single-player games.
Network applications consist of some components running on a wireless device and others running on a network, and thus depend on access to external resources. An example would be an email application, with a client residing on a wireless phone that interacts with a Simple Mail Transfer Protocol (SMTP) server to send messages.

Although these two types of applications are different, they are deployed in the same way. The big difference shows up later: Local applications are easier to test than network applications. For example, a calculator application can run on a wireless phone even when it is not connected to any network, but an email client won't work without a connection to the SMTP server that actually transmits the messages.

Wireless Java Applications Development Lifecycle

The development life-cycle of MIDlets and other wireless Java applications comprises three steps:

Write the application. Use your favorite wireless application development environment and tools to develop the application. My favorite is the J2ME Wireless Toolkit. It has a simple and intuitive user interface that makes it easy to start developing wireless applications. More importantly, it includes several emulators for testing your applications. (Some of what follows will assume you use this toolkit too. If you use another development environment, you'll have to adapt what you read here to that environment.)
Test the application in an emulation environment. Once the application compiles nicely, the best place to begin testing it is an emulator. The J2ME Wireless Toolkit comes with several, including Motorola i85s, PalmOS device, and RIM Blackberry. It is important to note, however, that these emulators do not simulate perfectly all of the features of the corresponding devices. They are merely skins with the appropriate dimensions, so the following step is crucial.
Download the application to a physical device and test it. Once you are happy with the application's performance on one or more emulators, download it to a real device and test it there. If it's a network application, test it on a live wireless network to ensure that its performance is acceptable.

This article's focus is on that last step: deploying and testing the application on a physical device.

Deploying and Running Remote Applications

The J2ME Wireless Toolkit enables you to run your local wireless application from within the development environment; the JAD and JAR files are available on your own system (if you're using the J2ME Wireless Toolkit, in <toolkit>/apps/YourProject/bin). If you wish to market your wireless applications, however, you need to deploy them where users from all over the world can access them.

Remote Deployment

To deploy your wireless applications remotely:

Upload your application files (JAD and JAR) to a remote web server. If your project is named games, for instance, upload the files: games.jad and games.jar from the bin directory of your project home (for example, <toolkit>/apps/games/bin). Note that the two files must end up in the same directory on the server.

Reconfigure the web server so that it recognizes JAD and JAR files:

For the JAD file type, set the file extension to .jad and the MIME type to text/vnd.sun.j2me.app-descriptor.
For the JAR file type, set the file extension to .jar and the MIME type to application/java-archive.

How you configure the web server depends on which one you're using. For example, if you're using Tomcat, make sure your web.xml file includes the following lines:

 <mime-mapping>    <extension>jad</extension>    <mime-type>text/vnd.sun.j2me.app-descriptor</mime-type> </mime-mapping> <mime-mapping>    <extension>jar</extension>    <mime-type>application/java-archive</mime-type> </mime-mapping>

Change your JAD file's MIDlet-Jar-URL property to specify the URL of your JAR file. For example, in the copy of games.jad you uploaded to the server, change...
MIDlet-Jar-URL: games.jar
...to...
MIDlet-Jar-URL: http://YourWebServerAddress:port/pathTo/games.jar

Running Remotely Deployed Applications

To see whether your application deployed correctly, open an ordinary web browser and enter the JAD file's URL. The J2ME Wireless Toolkit's default emulator should appear and the remotely deployed application should run in it.

J2ME-enabled devices (the Motorola/Nextel i85s, for example) include a Java Application Manager (JAM) responsible for downloading, installing, and configuring applications. The J2ME Wireless Toolkit includes a sample JAM you can run in the default emulator. To see how the user will download and manage your application, open a command prompt, change the current directory to <toolkit>/bin, and enter the command:

emulator -Xjam

The emulator appears and you see the JAM's main screen. In version 1.0.4 of the toolkit, the main screen looks like this:

Figure 1: The J2ME Wireless Toolkit Java Application Manager's Main Screen

Select the Install soft button and you will be prompted for the application's URL, as shown in Figure 2. Enter the URL of a web page that contains a hyperlink to the application's JAD file.

Figure 2: Entering the URL for the Application's JAD File

Entering a long URL into a wireless phone is inconvenient. A faster and easier way to get started is to use a command in this form:

emulator -Xjam:install=http://yourWebServerAddress:port/yourApp.jad

Without further entry, the JAM downloads the JAR file specified in the JAD file and installs the application. The next time you start the emulator, simply select the JAM's Menu button, then use the menu to run the application, remove it, or perform the other functions shown in Figure 3:

Figure 3: The JAM's Main Menu

It is important to note that this syntax allows you to install only one MIDlet at a time. Entering a URL allows you to view a web page that may contain several MIDlets you can choose from. As an example, consider the following HTML file (midlets.html) that contains links to three JAD files:

 <html> <head> <title>Midlets</title> </head>  <body>  Download midlets: <p> <a href="http://127.0.0.1:8080/games.jad">Games.jad</a> <p> <a href="/mobility/midp/articles/deploy/calc.jad">Calc.jad</a> <p> <a href="/mobility/midp/articles/deploy/browser.jad">Browser.jad</a>  Thank you.  </body> </html>

It is important to note that the hyperlinks point to the application's JAD file. Now, enter the URL into the install window as shown in Figure 4. (The IP address 127.0.0.1 is equivalent to localhost.)

Figure 4: Entering a URL in the Install Window

The JAM reads the HTML doccument (midlets.html), parses the hyperlinks, and displays a list of MIDlets you can download:

Figure 5: Links to Downloadable MIDlets

Now you can select a MIDlet to download. The JAM reads the JAD file to discover whether the device is capable of handling the application. If so, it downloads and installs the JAR file specified in the JAD file. Once the games MIDlet is downloaded and installed, you will see a display similar to Figure 6. Note that games.jad is the MIDlet suite that comes with the J2ME Wireless Toolkit.

Figure 6: The MIDlet Suite of Games Downloaded and Installed

The JAM is smart enough to notify you if you try to install a MIDlet that's already on your device, as in FIgure 7. It will, however, allow you to download an updated version of the MIDlet.

Figure 7: Warning That MIDlet Is Already Installed

Deploying and Running Applications on Physical Devices

Deploying and running applications in an emulation environment is a very good way to test the logic and flow of your application generally, but you won't be certain it will satisfy users until you test it on a real physical device connected to a wireless network. Your application's performance may be stunning in the emulator, which has all the processing power and memory of your desktop machine at its command, but will it perform well on the handheld device, with its limited memory and processing power, low bandwidth, and other constraints?

To perform realistic tests you need a J2ME-enabled physical device, and a data cable to connect it to your desktop. For this article

I used a Motorola/Nextel i85s cell phone, available from Nextel, which offers several models and rate plans.

Deploying Local Applications

If you have a Motorola J2ME-enabled phone, you can download stand-alone applications using the Motorola Java Application Loader Lite (JAL Lite). Note that JAL Lite limits filename lengths to 16 characters, and expects an application's JAD and JAR files to be in the same directory.

Connect the phone to your desktop and start JAL Lite on your desktop. You'll see a window like the one in Figure 8:

Figure 8: Motorola JAL Lite

The application displays the MIDlets already installed on the device. To install a new application, click on the Connect button, then the Download button. The application loader lets you browse your hard disk and select a JAD file. As soon as you do, it begins downloading the application and displays a progress indicator as shown in Figure 9:

Figure 9: JAL Lite Downloading an Application to the Phone

Once the download is complete, click on the Disconnect button, and disconnect the phone from the data cable. When you browse through the Java applications available on the phone, you should see the application you just downloaded. Select it and you will be asked if you wish to install it. If you answer yes, the application will be installed and you can start using it. The application remains on the phone until you explicitly remove it.

Buying and Deploying Remote Applications

You can use JAL Lite and the data cable to download local applications to a wireless phone from your desktop, including freely available applications you first download to your desktop using HTTP or FTP. Many useful applications are accessible only if you use special tools, however, usually because developers and wireless carriers wish to charge people for downloading them. There are two ways to download remotely deployed applications:

Download your own remotely deployed applications: You can use the Motorola iDEN Java Application Loader to download local and remotely deployed applications, much as you use JAL Lite to download local applications. Motorola's iDEN web site provides detailed information on how to become a member of iDEN's Developer Program and start downloading.
Buy and download others' applications: Motorola and Nextel have a large database of wireless applications available for download. Some are free. Check out iDEN Update, a web-based service with a client-side download application – itself a free downloadable application! – that enables you to download new features, applications, and enhancements. You can browse the site, select features and applications you'd like, and update your phone over the Internet. You'll need the iDEN Update client software and an update data cable. A snapshot of the iDEN wireless marketplace appears in Figure 10:

Figure 10: Motorola iDEN Update
(click for full size)

Downloading Applications Over The Air

For some time, wireless portals in Europe such as Midletcentral have allowed customers to download applications directly to their phones, over the air. Over-the-air provisioning of wireless applications (OTA) is finally available in North America. Nextel customers, for example, can download network-aware wireless applications without an update data cable.

OTA is the deployment of wireless Java applications (MIDlet suites) from the Internet to wireless devices over a wireless network. Users need not connect their devices to the desktop with a data cable or visit a service center to install or upgrade software. See Over The Air User Initiated Provisioning Recommended Practice for the Mobile Information Device Profile for details.

To take advantage of OTA, you must equip your handheld device with a mechanism to discover MIDlet suites available for download, using the device's browser (such as a WAP browser) or a resident application written specifically to identify downloadable MIDlet suites.

The process of downloading MIDlets over the air is illustrated in Figure 11.

Figure 11: Over-the-Air Provisioning of MIDlets
(click for full size)

Conclusion:

Many Java-enabled wireless devices are already out there, and the necessary wireless infrastructure is in place to begin deploying wireless applications. This article discussed several ways to deploy and test local and remote wireless Java applications.

To succeed in the wireless market, you need to develop relationships with other developers, device manufacturers, content developers, and wireless carriers. Several device manufacturers (such as Nokia) and wireless carriers (such as Nextel) offer developer programs that can help you market your dazzling wireless Java application.

Server load balancing architectures, Part 2: Application-level load balancing

2011-04-18T06:07:00.001-07:00

The transport-level server load balancing architectures described in the first half of this article are more than adequate for many Web sites, but more complex and dynamic sites can't depend on them. Applications that rely on cache or session data must be able to handle a sequence of requests from the same client accurately and efficiently, without failing. In this follow up to hisintroduction to server load balancing, Gregor Roth discusses various application-level load balancing architectures, helping you decide which one will best meet the business requirements of your Web site.

The first half of this article describes transport-level server load balancing solutions, such as TCP/IP-based load balancers, and analyzes their benefits and disadvantages. Load balancing on the TCP/IP level spreads incoming TCP connections over the real servers in a server farm. It is sufficient in most cases, especially for static Web sites. However, support for dynamic Web sites often requires higher-level load balancing techniques. For instance, if the server-side application must deal with caching or application session data, effective support for client affinity becomes an important consideration. Here in Part 2, I'll discuss techniques for implementing server load balancing at the application level to address the needs of many dynamic Web sites.

Intermediate server load balancers

In contrast to low-level load balancing solutions, application-level server load balancing operates with application knowledge. One popular load-balancing architecture, shown in Figure 1, includes both an application-level load balancer and a transport-level load balancer.

Figure 1. Load balancing on transport and application levels (click to enlarge)

The application-level load balancer appears to the transport-level load balancer as a normal server. Incoming TCP connections are forwarded to the application-level load balancer. When it retrieves an application-level request, it determines the target server on the basis of the application-level data and forwards the request to that server.

Listing 1 shows an application-level load balancer that uses a HTTP request parameter to decide which back-end server to use. In contrast to the transport-level load balancer, it makes the routing decision based on an application-level HTTP request, and the unit of forwarding is a HTTP request. Similarly to the memcachedapproach I discussed in Part 1, this solution uses a "hash key"-based partitioning algorithm to determine the server to use. Often, attributes such as user ID or session ID are used as the partitioning key. As a result, the same server instance always handles the same user. The user's client is affine or "sticky" to the server. For this reason the server can make use of a localHttpRequest cache I discussed in Part 1.

Listing 1. Intermediate application-level load balancer

class LoadBalancerHandler implements IHttpRequestHandler, ILifeCycle {    private final List<InetSocketAddress> servers = new ArrayList<InetSocketAddress>();    private HttpClient httpClient;     /*     * this class does not implement server monitoring or healthiness checks     */     public LoadBalancerHandler(InetSocketAddress... srvs) {       servers.addAll(Arrays.asList(srvs));    }    public void onInit() {       httpClient = new HttpClient();       httpClient.setAutoHandleCookies(false); }      public void onDestroy() throws IOException {       httpClient.close();    }     public void onRequest(final IHttpExchange exchange) throws IOException {       IHttpRequest request = exchange.getRequest();        // determine the business server based on the id's hashcode       Integer customerId = request.getRequiredIntParameter("id");       int idx = customerId.hashCode() % servers.size();       if (idx < 0) {          idx *= -1;       }        // retrieve the business server address and update the Request-URL of the request       InetSocketAddress server = servers.get(idx);       URL url = request.getRequestUrl();       URL newUrl = new URL(url.getProtocol(), server.getHostName(), server.getPort(), url.getFile());       request.setRequestUrl(newUrl);        // proxy header handling (remove hop-by-hop headers, ...)       // ...         // create a response handler to forward the response to the caller       IHttpResponseHandler respHdl = new IHttpResponseHandler() {           @Execution(Execution.NONTHREADED)          public void onResponse(IHttpResponse response) throws IOException {             exchange.send(response);          }           @Execution(Execution.NONTHREADED)          public void onException(IOException ioe) throws IOException {             exchange.sendError(ioe);          }       };        // forward the request in a asynchronous way by passing over the response handler       httpClient.send(request, respHdl);    } }    class LoadBalancer {     public static void main(String[] args) throws Exception {       InetSocketAddress[] srvs = new InetSocketAddress[] { new InetSocketAddress("srv1", 8030), new InetSocketAddress("srv2", 8030)};       HttpServer loadBalancer = new HttpServer(8080, new LoadBalancerHandler(srvs));       loadBalancer.run();    } }

In Listing 1, the LoadBalancerHandler reads the HTTP id request parameter and computes the hash code. Going beyond this simple example, in some cases load balancers must read (a part of) the HTTP body to retrieve the required balancing algorithm information. The request is forwarded based on the result of the modulo operation. This is done by the HttpClientobject. This HttpClient also pools and reuses (persistent) connections to the servers for performance reasons. The response is handled in an asynchronous way through the use of an HttpResponseHandler. This non-blocking, asynchronous approach minimizes the load balancer's system requirements. For instance, no outstanding thread is required during a call. For a more detailed explanation of asynchronous, non-blocking HTTP programming, read my article "Asynchronous HTTP and Comet architectures."

Another intermediate application-level server load balancing technique is cookie injection. In this case the load balancer checks if the request contains a specific load balancing cookie. If the cookie is not found, a server is selected using a distribution algorithm such as round-robin. A load balancing session cookie is added to the response before the response is sent. When the browser receives the session cookie, the cookie is stored in temporary memory and is not retained after the browser is closed. The browser adds the cookie to all subsequent requests in that session, which are sent to the load balancer. By storing the server slot as cookie value, the load balancer can determine the server that is responsible for this request (in this browser session). Listing 2 implements a load balancer based on cookie injection.

Listing 2. Cookie-injection based application-level load balancer

class CookieBasedLoadBalancerHandler implements IHttpRequestHandler, ILifeCycle {    private final List<InetSocketAddress> servers = new ArrayList<InetSocketAddress>();    private int serverIdx = 0;    private HttpClient httpClient;     /*     * this class does not implement server monitoring or healthiness checks     */     public CookieBasedLoadBalancerHandler(InetSocketAddress... realServers) {       servers.addAll(Arrays.asList(realServers));    }     public void onInit() {       httpClient = new HttpClient();       httpClient.setAutoHandleCookies(false); }     public void onDestroy() throws IOException {       httpClient.close();    }     public void onRequest(final IHttpExchange exchange) throws IOException {       IHttpRequest request = exchange.getRequest();         IHttpResponseHandler respHdl = null;       InetSocketAddress serverAddr = null;        // check if the request contains the LB_SLOT cookie       cl : for (String cookieHeader : request.getHeaderList("Cookie")) {          for (String cookie : cookieHeader.split(";")) {             String[] kvp = cookie.split("=");             if (kvp[0].startsWith("LB_SLOT")) {                int slot = Integer.parseInt(kvp[1]);                serverAddr = servers.get(slot);                break cl;             }          }       }        // request does not contains the LB_SLOT -> select a server       if (serverAddr == null) {          final int slot = nextServerSlot();          serverAddr = servers.get(slot);           respHdl = new IHttpResponseHandler() {              @Execution(Execution.NONTHREADED)             public void onResponse(IHttpResponse response) throws IOException {                // set the LB_SLOT cookie                response.setHeader("Set-Cookie", "LB_SLOT=" + slot + ";Path=/");                exchange.send(response);             }              @Execution(Execution.NONTHREADED)             public void onException(IOException ioe) throws IOException {                exchange.sendError(ioe);             }          };        } else {          respHdl = new IHttpResponseHandler() {              @Execution(Execution.NONTHREADED)             public void onResponse(IHttpResponse response) throws IOException {                exchange.send(response);             }              @Execution(Execution.NONTHREADED)             public void onException(IOException ioe) throws IOException {                exchange.sendError(ioe);             }          };       }        // update the Request-URL of the request       URL url = request.getRequestUrl();       URL newUrl = new URL(url.getProtocol(), serverAddr.getHostName(), serverAddr.getPort(), url.getFile());       request.setRequestUrl(newUrl);        // proxy header handling (remove hop-by-hop headers, ...)       // ...        // forward the request       httpClient.send(request, respHdl);    }     // get the next slot by using the using round-robin approach    private synchronized int nextServerSlot() {       serverIdx++;       if (serverIdx >= servers.size()) {          serverIdx = 0;       }       return serverIdx;    } }   class LoadBalancer {     public static void main(String[] args) throws Exception {       InetSocketAddress[] srvs = new InetSocketAddress[] { new InetSocketAddress("srv1", 8030), new InetSocketAddress("srv2", 8030)};       CookieBasedLoadBalancerHandler hdl = new CookieBasedLoadBalancerHandler(srvs);       HttpServer loadBalancer = new HttpServer(8080, hdl);       loadBalancer.run();    } }

Unfortunately, the cookie-injection approach only works if the browser accepts cookies. If the user deactivates cookies, the client loses stickiness.

James Gosling riffs at TSSJS keynote

2011-04-10T02:03:00.001-07:00

ames Gosling gave the keynote address at TheServerSide Java Symposium on Wednesday, touching on topics including Oracle's stewardship of Java, the importance of Java Virtual Machine (JVM), JDK 7 and cloud computing.

On Oracle's ownership of Java: One of Gosling's slides read: "No clue what Larry (Ellison) will do. But he won't shoot himself. I hope."

"It's in their own self-interest to not be really aggressively stupid," Gosling said, prompting audience laughter. "But it's been clear that it's been something of a learning experience. It's been clear that they didn't understand what they bought, what it meant to deal with communities and people and all the arguing and discussion and consensus building that's involved in communities."

On JVM: Gosling said that in the Java world, what he really cares about is JVM.

"That's what ties it all together," he said. "It makes all kinds of languages able to coexist."

Gosling added that in the non-JVM world, being able to go back and forth between different languages is much more difficult. But with JVM, it is "remarkably straightforward" to write a piece of your program in Java, in JavaScript and in Ruby.

On SOA and REST: "They've sedimented down and they've become the bedrock that so much stuff rests upon."

But he added that his big problem with SOA and REST today is that "people get service-happy. They start building thousands of services that should be coalesced into fewer services."

On JDK 7: "The Oracle folks have been doing a pretty good job of getting that marching forward. The JDK had been stuck on a bunch of JDP procedural issues."

Also: "They decided they wanted to get things out sooner rather than later, so the feature list isn't everything we wanted, but it will get there."

On cloud computing: "The word cloud has become really annoying. Every marketer has a new take on it. It will cure cancer. It will find the fountain the youth."

"There are a bunch of interesting things in clouds," he added. "I am a fan."

"It's this combination of real management and dynamics that really set clouds apart," he said.

On social media: "I'm about the geekiest guy you could imagine, but all the successful things out there, if you were to ask me about them, I would say they are really stupid. I just don't get Zynga. I just don't get FarmVille. I just don't get it."

But that doesn't discourage him.

"The Web these days - and this is kind of cool - is now the domain of the artists and the social scientists," he said. "For myself as an engineer, I'm just kind of a plumber in the basement of the place. And yeah, you can get a little depressed about that, but it really is exciting. It opens things up to people who are differently able, who have different skills from me."

SOURCE:http://www.theserverside.com/news/2240033442/James-Gosling-riffs-at-TSSJS-keynote

Web Application Testing Tools - Open Source

2011-04-10T01:58:00.001-07:00

Many organizations are surprised to find that it is more expensive to do testing using tools. In order to gain benefits from testing tools, careful thought must be given for which tests you want to use tools and to the tool being chosen.

Anteater is a testing framework designed around Ant, from the Apache Jakarta Project. It is basically a set of Ant tasks for the functional testing of Web sites and Web services (functional testing being: hit a URL and ensure the response meets certain criteria). One can test HTTP parameters, response codes, XPath, regexp, and Relax NG expressions. Anteater also includes HTML reporting (based on junitreport) and a hierarchical grouping system for quickly configuring large test scripts. When a Web request is received, Anteater can check the parameters of the request and send a response accordingly. This makes it useful for testing SOAP and XML applications.

The ability to wait for incoming HTTP messages is something unique to Anteater, which makes it especially useful when building tests for applications that use high level SOAP-based communication, like ebXML or BizTalk. Applications written using these protocols usually receive SOAP messages and send back a meaningless response. It is only later that they inform the client, using an HTTP request on the client, about the results of the processing. These are the so-called asynchronous SOAP messages, and are the heart of many high-level protocols based on SOAP or XML messages.

Written in Java, HttpUnit emulates the relevant portions of browser behavior, including form submission, Javascript, basic HTTP authentication, cookies, and automatic page redirection, and allows Java test code to examine returned pages either as text, an XML DOM, or containers of forms, tables, and links.

jWebUnit is a Java framework which facilitates creation of acceptance tests for Web applications. It provides a high-level API for navigating a Web application combined with a set of assertions to verify the application's correctness. This includes navigation via links, form entry and submission, validation of table contents, and other typical business Web application features. It utilizes HttpUnit behind the scenes. The simple navigation methods and ready-to-use assertions allow for more rapid test creation than using only JUnit and HttpUnit.

Bugkilla is a tool set to create, maintain, execute, and analyze functional system tests of Web applications. Specification and execution of tests is automated for both the Web frontend and business logic layers. One goal is to integrate with existing frameworks and tools (an Eclipse Plugin exists)

The Grinder, a Java load testing framework freely available under a BSD-style Open Source license, makes it easy to orchestrate the activities of a test script in many processes across many machines, using a graphical console application. Test scripts make use of client code embodied in Java plugins. Most users of The Grinder do not write plugins themselves; they use one of the supplied plugins. The Grinder comes with a mature plugin for testing HTTP services, as well as a tool which allows HTTP scripts to be automatically recorded.

Jameleon is an automated testing tool that separates applications into features and allows those features to be tied together independently, creating test cases. These test cases can then be data-driven and executed against different environments. Jameleon breaks applications into features and allows testing at any level, simply by passing in different data for the same test. Because Jameleon is based on Java and XML, there is no need to learn a proprietary technology.

It's an acceptance testing tool for testing the functionality provided by applications, and currently supports the testing of Web applications. It differs from regular HttpUnit and jWebUnit in that it separates testing of features from the actual test cases themselves. If I understand it correctly, you write the feature tests separately and then script them together into a reusable test case. Incidentally, you can also make these test cases data-driven, which gives an easy way of running specific tests on specific environments.

The framework has a plugin architecture, allowing different functional testing tools to be used, and there is a plugin for testing Web applications using HttpUnit/jWebUnit. The test case scripting is done with XML and Jelly.

Jameleon combines XDoclet, Ant and Jelly to provide a potentially powerful framework for solid functional testing of your Webapp. It strikes a good balance between scripting and coding, and allows you to set up multiple inputs per test by providing input via CSV files. Along with the flexibility come a complexity and maintenance overhead, but you are getting your Webapp tested for you.

LogiTest is the core application in the LogiTest suite. LogiTest is designed to aid in the testing of Web site functionality. It currently supports HTTP and HTTPS protocols, GET and POST methods, multiple document views, custom headers, and more. The LogiTest application provides a simple graphical user interface for creating and playing back tests for testing Internet-based applications.

Solex is a set of Eclipse plugins providing non-regression and stress tests of Web application servers. Test scripts are recorded from Internet browsers, thanks to a built-in Web proxy. For some Web applications, a request depends on a previous server's response. To address such a requirement, Solex introduces the concept of extraction and replacement rules. An extraction rule tied to an HTTP message's content will bind an extracted value with a variable. A replacement rule will replace any part of an HTTP message with variable content.

The tool therefore provides an easy way to extract URL parameters, Header values, or any part of a request or a response, bind their values with variables, and then replace URL parameters, Header values, or any part of a request with the variable content. The user has the ability to add assertions for each response. Once a response has been received, all assertions of this response will be called to ensure that it is valid. If not, the playback process is stopped. Several kinds of rules and assertions are provided. The most complicated ones support regular expressions and XPath.

Tclwebtest is a tool for writing automated tests of Web applications in Tcl. It implements some basic HTML parsing functionality to provide comfortable commands for operations on the HTML elements (most importantly forms) of the result pages.

TagUnit is a framework through which custom tags can be tested inside the container and in isolation from the pages on which they will ultimately be used. In essence, it's a tag library for testing tags within JSP pages. This means that it is easy to unit test tags, including the content that they generate and the side effects that they have on the environment, such as the introduction of scripting variables, page context attributes, cookies, etc.

Web Form Flooder is a Java console utility that analyzes a Web page, completes any forms present on the page with reasonable data, and submits the data. It crawls links within the site in order to identify and flood additional forms that may be present. It is great for load testing of Web forms, checking that all links work and that forms submit correctly.

XmlTestSuite provides a powerful way to test Web applications. Writing tests requires only knowledge of HTML and XML. The authors want XmlTestSuite to be adopted by testers, business analysts, and Web developers who don't have a Java background. XmlTestSuite supports "test-driven development". It lets you separate page structure from tests and test data. It can also verify databases. It's like JWebUnit, but has simple XML test definitions and reusable pages. The problems with raw HTTPUnit or JWebUnit are that:

    It's very hard to get non-programmers to write tests.
    Tests are so ugly you can't read them. (Trust me; HttpUnit test classes are a nightmare to maintain.)
    Web tests generally change far more often than unit tests, and so need to be altered, but your refactoring won't change them automatically (i.e., changing a JSP in IDEA will not cascade to the test like changing a class will).

http://www.brainjava.com/index.php?option=com_content&task=view&id=39&Itemid=35

Developers still skeptical of Oracle’s stewardship of Java

2011-04-10T01:57:00.001-07:00

LAS VEGAS – Java developers say they are still wary of how Oracle will shepherd the Java programming languages despite Oracle executives' claims that they plan to keep Java "vibrant."

It has been more than a year since Oracle completed its acquisition of Sun Microsystems and, hence, of Java. Some developers at TheServerSide Java Symposium in Las Vegas this week said they haven't seen as much of a commitment to the Java community as they would like, and they're skeptical about Oracle's intention with Java.

"The community aspect of Java is disappearing," said Deva, senior developer for a health care company who didn't want his last name or company name used because of corporate rules about speaking to the press. "The way Oracle is handling Java is making developers really nervous."

Deva continued, saying that he thinks Oracle is pushing hard on the marketing side of Java and not as much on the open source aspect of it, which, he said, "has been the soul of Java."

Stephen Wilson, systems engineer for a leading software company, said he wonders what Oracle CEO Larry Ellison's "end game" is. "You wonder if he's going to bring everyone into Java, and then flip a switch and say, 'Sorry, now you have to pay for it'."

"(Ellison) wants to own every piece of the IT organization," Wilson added. "He's not out there to be a philanthropist."

Not everyone agrees, however.

"Initially I figured that Oracle just wanted to profit on Java," said Carlos Alfonzo Ortiz, architect at Cartagena Regional Port in Columbia. "After hearing them today, I think they have a good plan for their platform."

James Gosling, considered the father of Java, said during his keynote session at the Java Symposium that it is in Oracle's own interest to "not be really aggressively stupid." But he said it's been clear that Oracle didn't exactly know what it was getting into with the acquisition of Java.

"It's been clear that they didn't understand what they bought; what it meant to deal with communities and people, and all the arguing and discussion and consensus building that's involved in communities," he said.

Oracle executives said they understand the skepticism among developers but feel that if they keep releasing new features of the Java platform that eventually people will come around. Adam Messinger, VP of development for Oracle Fusion Middleware, acknowledged that most people see Oracle as a company that is focused first and foremost on making money. He didn't deny the claim in any way, saying only that the company seeks to develop and support Java simply because Java is the foundation for so much of what Oracle offers in the middleware and application space.

"On the strategy, it's not like it's benevolent exactly," he said. "It is more or less enlightened self-interest."

He later added that "the focus is definitely on keeping the businesses that we had already built on top of Java healthy and growing."

SOURCE:http://www.theserverside.com/news/2240033465/Developers-still-skeptical-of-Oracles-stewardship-of-Java

Java Application Testing Tools

2011-04-10T01:56:00.001-07:00

Many organizations are surprised to find that it is more expensive to do testing using tools. In order to gain benefits from testing tools, careful thought must be given for which tests you want to use tools and to the tool being chosen.

One of the most widely-used tools is Abbot, a framework for testing Java GUIs. Using simple XML-based scripts, we can launch a GUI, play back arbitrary user actions on it, and examine its state. It also includes a script editor (Costello) that records user actions. The framework may be invoked directly from Java code (JUnit) or accessed without programming through the use of scripts. It is suitable for use both by developers for unit tests and QA for functional testing, especially with JFC swing. This tool has an excellent development team, which constantly updates the software.

DejaGnu is a framework for testing applications such as Tcl, C, C++, Java, and network applications, and cross testing embedded systems. Its purpose is to provide a single frontend for all tests. Think of it as a custom library of Tcl procedures crafted to support writing a test harness. A "test harness" is the testing infrastructure that is created to support a specific program or tool. Each program can have multiple test suites, all supported by a single test harness. DejaGnu is written in Expect, which in turn uses Tcl, Tool Command Language. There has not been a new release in quite a while, although the snapshots are quite stable.

The JavaTest™ harness is a general purpose Open Source Java API for creating Java test software, a fully-featured, flexible, and configurable test harness very well suited for most types of unit testing, especially Technology Compatibility Kit (TCK) test suites. The JavaTest harness is an excellent tool for configuring, sequencing, and running test suites that consist of large numbers of discrete, independent tests. It is especially good at testing APIs and compilers. Originally developed as a test harness to run the JCK test suite, it has since evolved into a general-purpose test platform well suited for use with all TCK test suites.

JFunc is an extension to the JUnit testing framework to make it easier for use with functional tests. Functional testing (also called integration testing) significantly differs from unit testing in a number of respects. Part of this project is dedicated towards putting together code to address these differences; the other part of this project is putting together methodologies for functional testing.

Marathon is a general-purpose tool for both running and authoring acceptance tests geared at the Java Platform Version 1.3 or later. Included with marathon is a rich suite of components to help you interact with your application at the User interface Level (GUI). To aid with the regression testing of existing applications, Marathon comes bundled with a recorder to capture events as you use and interact with your application. These events are then converted into a valid Marathon test, which can subsequently be played back.

Pounder is a utility for testing Java GUIs. It allows developers to dynamically load components, record scripts, and then use those scripts in JUnit. It supports custom components, drag-and-drop, and the examination of test runs in source.

QAT was developed to ease the issues encountered by having to perform Quality Assurance tests across a variety of hardware and software combinations. The way to achieve this is to abstract the process of running the test on a machine. So, from a tester's point of view, there is one test suite, which the tester executes, and then gets the results for further analysis. The specifics of the machine on which the test will be run is completely hidden, and is necessary for running the test.

The QAT tool can be divided into two main sections, the Agent, responsible for actually running each test or group of tests, and the Harness, which is responsible for test selection, management, results, and agent co-ordination. It can be accessed via a browser interface if remote access to the harness is required.

First, each test case is written in a platform-independent way in a simple scripting language, very similar to C shell, although it could be implemented as any language you want. All references to platform-specific items are delayed by referring to one or more configuration files. A configuration is then built for each test based on the architecture and operating system of the target machine. So, instead of directly executing a command within the test, we refer to variables, which will only be defined at the time of running the test.

Once the test case is ready, the test is transferred to whatever machine we want to run it on (agent). This is achieved by developing a relatively stupid agent that can respond to a limited set of requests from the harness via TCP sockets. Some examples are GETFILE, SENDFILE, DELFILE, EXECUTE, etc. The test script running on the harness may then use this command set to build a desired environment on the agent. We are able to transfer files, unzip files, delete files, set environment variables, and any of the other good things we need to run a test. Once the test is run, a result is decided on and sent back to the harness for processing.

Since the agent is written in Java, it runs on any architecture supporting a JVM, including restricted ones running pJava, kJava, and various other slimmed-down versions.

SOURCE:http://www.brainjava.com/index.php?option=com_content&task=view&id=38&Itemid=35

How to fix the JCP? Participate

2011-04-10T01:55:00.001-07:00

During a keynote panel at TheServerSide Java Symposium on Thursday, Patrick Curran, James Gosling and Reza Rahman all said that participation is key to making the JCP work as it should, in a democratic fashion.

"We have a responsibility to keep an eye on what's going on," Rahman, a Java consultant and author. said. "Democracy is participation. If you don't participate and just complain about it, you're just on one side of that two-way street."

Cameron McKenzie, editor of TheServerSide.com, moderated the panel.

One attendee asked how busy Java developers can really get involved before a certain Java Specification Request (JSR) is fully baked. Curran, the head of the JCP, had a suggestion.

"The simplest way is to follow a JSR that you're interested in," he said. "You can read the spec, you can comment on it. I think the main thing is to watch what's happening."

Gosling, considered the father of Java, added that oftentimes the comments come too late, after the JSR is fully baked. To which Gosling replied: "There was a huge review cycle and you didn't show up?"

Overall we're trying to make sure people participate in the process smoothly. Most important we want to make it open so people can see what's happening.

Patrick Curran, head of the Java Community Process (JCP)

That said, all three said there were ways in which the JCP could improve. Curren, for example, said that the majority of JSRs out there have someone from Oracle as the spec lead. While he and Rahman said they wished there were more spec leads from other companies, they agreed that, as Rahman put it, it is somewhat of a "necessary evil" that Oracle is so prominent.

"A significant portion of the work to be done should be done by Oracle," Curran said.

Gosling added that one way to improve the JCP would be for participants to keep their conflicted interests separate.

"Number 1 is to leave the politics at the door," he said. "Number 2 is transparency. One of the problems all the expert groups get into is that you have people who with one hat they're engineers, and the other hat they're employees of some corporation. So there are competing agendas."

Curran agreed with Gosling's call for transparency.

"Overall we're trying to make sure people participate in the process smoothly," he said. "Most important we want to make it open so people can see what's happening."

SOURCE:http://www.theserverside.com/news/2240033488/How-to-fix-the-JCP-Participate

SCJP Exam for J2SE 5-A Concise, Comprehensive Study Guide for The Sun Certified

2011-04-10T01:54:00.001-07:00

# Paperback: 350 pages
# Publisher: Apress; Study Gd edition (May 30, 2006)
# Language: English
# ISBN: 1590596978
# Product Dimensions: 9.2 x 7.4 x 0.9 inches

Best selling author, Paul Sanghera, offers cohesive, concise, yet comprehensive coverage of all the topics included in the Sun Certified Programmer for Java 5 exam (CX 310-055). With a laser sharp focus on the exam objectives, the Study Guide goes beyond just being an "exam cram." The material is presented in a logical learning sequence: a section builds upon previous sections and a chapter on previous chapters. All concepts, simple and complex, are defined and explained when they appear the first time. There is no hopping from topic to topic and no technical jargon without explanation. No prior knowledge of Java programming is assumed. The single most difficult aspect of this exam is to read and understand the code in the exam questions in a limited amount of time. To help you get fluent and comfortable with the code, the book offers complete runnable code examples distributed over all the chapters and a codewalk quicklet feature at the end of each chapter.

Although the primary purpose of the book is to help you pass the SCJP exam, it will also serve as a good reference after the exam.

Special features include

Hundreds of questions modeled after the real exam with fully explained answers.
A complete practice exam with questions modeled after the real exam and fully explained answers.
Hundreds of complete runnable code examples, explained in the book, that you can download and experiment with. This is a code-intensive exam.
The Codewalk Quicklet feature based on the process-based codewalk philosophy to prepare you for efficient response to the code-based questions in the exam.
The Exam Quick Prep feature which recaps all the important points for the last hour of preparation before taking the exam.
Useful information and analysis for the programmers who are considering updating the J2SE 1.4 certification to J2SE 5.

Download:
http://rapidshare.com/files/1259710/Apress.SCJP.Exam.for.J2SE.5.May.2006.rar

SOURCE:http://www.brainjava.com/index.php?option=com_smf&Itemid=30&?topic=4.0

JAVA APPLICATION

Java Decompiler and its Missing Documentation

It sounds like a great plugin, but what does it do?

Settings

When and where does JD-Eclipse do its work for you?

Opening a Java type

Debugging

When does JD-Eclipse not work for you?

Conclusion

Decompile java code with Cavaj

Decompile java code with Cavaj

How To Extract Fla Files From Flash Files With Swf Decompiler

Learn how to download applets and decompile Java class files

Protect Your Java Code from Reverse Engineering

Java Decompilers

Error Taxonomy

Decompiler Errors by type

Java Decompiler New features in version 3.11.11.95

Java Decompiler

Packaging and Distributing Java Desktop Applications

Creating Executable JAR File

Creating a Project with Existing Sources

Configuring the Project

Verifying the Java Platform

Setting the Main Class

Building the Project and Creating the JAR File

Running and Distributing the JAR File

Running the Application Inside of the IDE

Running the Application Outside of the IDE

Distributing the Application to Other Users

Starting Your Java Application

Launching Applications From the Command Line

Launching Applications From a Script

Java Web Start

Advanced Debugging

Skip all breakpoints

4.2. Breakpoint Properties

4.3. Watchpoint

4.4. Exception Breakpoint

4.5. Method Breakpoint

4.6. Class breakpoint

4.7. Hit Count

4.8. Drop to frame

Add dynamic Java code to your application

An example of dynamic Java code

JDK 7 Support in NetBeans IDE 7.0:

Configuring the Project to Use JDK 7

Using New JDK 7 Language Constructs: Switch Statement

JDK 7 Support: More Examples

Convert Java to EXE

Debug

Setting Breakpoints

3.2. Starting the Debugger

Tip

3.3. Stack

3.4. Variables

Sending Email From Your Application Using Java Mail

Deploying Wireless Java Applications

Wireless Java Applications

Wireless Java Applications Development Lifecycle

Deploying and Running Remote Applications

Remote Deployment

Running Remotely Deployed Applications

Deploying and Running Applications on Physical Devices

Deploying Local Applications

Buying and Deploying Remote Applications

Downloading Applications Over The Air

Server load balancing architectures, Part 2: Application-level load balancing

Intermediate server load balancers

Figure 1. Load balancing on transport and application levels (click to enlarge)

Listing 1. Intermediate application-level load balancer

Listing 2. Cookie-injection based application-level load balancer

James Gosling riffs at TSSJS keynote

Web Application Testing Tools - Open Source

Developers still skeptical of Oracle’s stewardship of Java

Java Application Testing Tools

How to fix the JCP? Participate

SCJP Exam for J2SE 5-A Concise, Comprehensive Study Guide for The Sun Certified