Ujjwal's Blog: April 2009

Wednesday, April 29, 2009

Running java applications as services

Java Service Wrapper allows a Java application to be run as a Windows service or a Unix daemon. It works under FreeBSD, GNU-Linux, MacOS X, Solaris, AIX, Windows NT/2000/XP/2003, Irix, HP-UX and DEC OSF1.

Accessing system tray using java

SysTray for Java enables Java applications to create an icon in the system tray under Windows and KDE 3. It supports the creation of submenus, multiple independent menus, checkable menus, and everything can be changed at runtime. The JAR and the DLL needed to run systray4j on Windows are LGPL. The code for KDE is GPL.

Baloon tool tips in java : Jbaloon

jBallon is a new LGPL library that allows you to have balloon-style tooltips instead of the standard Java tooltips - and there´s no need to change a single line of Java code from your application. No recompilation is needed, either. To use JBalloonToolTips in your project you have to add this line to the project's startup script: -Xbootclasspath/p:jBalloon.jar You can also mix standard and balloon tooltips in one app if you want.

Friday, April 24, 2009

The size of a java.util.Calendar is 432 bytes

Calendar's are cool. They're one of the few objects (in any language) which I consider to have solved the datetime problem. So many datetime objects require extra work from the programmer for (seemlingly) simple queries such determining whether x occurred before or after a month ago. You typically can't simply add a year/month/date/hour/etc. and you always have to be careful of whether an index value is 0, 1, or -1900 based. Calendar lets you focus on the date operations you are performing rather than devising tricks to get around other people's laziness. You can add just about any date/time quantity, there are static fields for month values, and you can compare two Calendar's via the before and after methods.
But, recently, my love of Calendar's took a big hit.

This was shortly after I stumbled upon Java Tip 130: Do you know your data size?

I was tempted to discount this article due to it's age---5.5 years---so much has changed since then in the Java world. But, after running the SizeOf code and discovering that memory consumption for the various basic objects Vladimir Roubtsov tested hadn't changed, I re-read his article carefully and took every word to heart. That an empty String consumes 40 bytes took me by surprise. But, it wasn't until I tested Calendar that I was truly shocked. In the current system I'm working on, I am storing hundreds-of-thousands of objects with Calendar's as fields. No wonder they consumed so much memory! Now I understand whence that outlandish consumption came.
Going forward, I won't stop using Calendar's, but I'll be much more careful about my usage of them. No more throwing a Calendar into an object that I'll allocate thousands of times...

UseCompressedOops

learned of a nifty Hotspot option recently, -XX:+UseCompressedOops
It sounds like this largely solves the bloat problem that happens when you go from 32-bit to 64-bit with Java as this option tells Hotspot to allow heap sizes up to 32 gig, use the eight extra registers that are available with AMD64 and to use 32-bit pointers/references whenever possible to limit bloat. From what I've heard, tests indicate that the bloat is much smaller (~10% compared to the 50%+ you get with vanilla 64-bit) and performance is comparable. Here's a longer post by Ismael Juma to fill you in on the details:

32-bit or 64-bit JVM? How about a Hybrid?

Note that, as of recently, this option was only available in the Hotspot "performance" release, but is slated to be added to the main release.

Monday, April 13, 2009

Comments in java

We all use comments to describe the Java code. There are three types if comments in Java as demonstrated in this Java tutorial by SUN:

// text

where the compiler ignores everything from // to the end of the line

/* text */

where the compiler ignores everything from /* to */ and

/** documentation */

which is ignored by the compiler the same way as the previous comment type. This one is a special comment as this indicates a documentation comment. The JDK javadoc tool uses doc comments when preparing automatically generated documentation.

I am not going to tell you how to use them. There are many articles and documentation written about that. We all know how to use them and most of us use them on a daily basis. Over time we can develop a stereotype. Mine looks like this:

/** first name */
private String firstName;

/** last name */
private String lastName;

/**
* Constructs and returns the full name
* @return full name
*/
public String getFullName() {
if (firstName == null) {
if (lastName == null) {
// user does not have a name specified
return "[no name]";
}
else {
return lastName;
}
}
else {
if (lastName == null) {
return firstName;
}
else {
// construct full name from first and last name
return firstName + " " + lastName;
}
}
}

As you can see, I use doc comments to describe the meaning and function of my class members. I also like to use line comments, rather than block comments. Even if my comment spans multiple lines I prefer to use // comments. It's due to my IDE settings. When I press Ctrl+/ it un-/comments the selected lines. It's very neat feature and I use it a lot.

Recently, I was doing some code modifications and I wanted to re-visit some code later. I decide to break the code by putting a comment in the middle if it, so it would not compile and I would be forced to come back to it.

I did somethig like this:

myObject.getAnother()/* change to ID */.getName();

To my surprise the code did not break. Even when I changed it to

myObject.getAnother()./* change to ID */getName();

Obviously, when I did this

myObject.getAnother().ge/* change to ID */tName();

the code broke. At the end I made it to break in a nice way, anyway

myObject.getAnother()./* change to ID */.getName();

Keep it simple

Recently I saw pieces of code that could be simplified. I see such code often, however, recently I came across code that seemed to follow the same pattern

The patern was as in the following example:

private boolean someFlag;...public boolean isSomeFlagSet() { if (someFlag) { return true; } else { return false; }}Why not simply write:

public boolean isSomeFlagSet() { return someFlag;}It is so much simpler!

Similarly to boolean flags, there where occurencies of other object types being used and methods invoked on them in the following manner:

public String getCity() { if (address == null) { return null; } else { return address.getCity(); }}This can be also simplified (applying "change if-else to ?:" refactoring) to:

public String getCity() { return address == null ? null : address.getCity();}

How to get the server's timezone

The problem
How to get the server's timezone display name correctly and display it to the user in his locale.

server's default timezone
Firstly, you need to get the server's default timezone. This is easily achieved by the following call

final TimeZone timeZone = TimeZone.getDefault();
use daylight time?
Secondly, you need to find out if this timezone uses daylight time. This is important as some timezones change their names during daylight saving. Don't use the TimeZone.useDaylightTime() method

//final boolean daylight = timeZone.useDaylightTime();
This method works fine only for systems where the timezone never changes. If the administrator changes the time on the server, this change won't be reflected in subsequent calls. What you need to do instead, is to find out is the daylight savings is on right now.

final boolean daylight = timeZone.inDaylightTime(new Date());
user's locale
The last important step is to get the right locale, the locale you want this timezone name to display in. You could call Locale.getDefault(), but this returns server's default locale. You want the locale that the user is using. In a web application, the user's locale can be obtained from getLocale() method of ServletRequest object.

final Locale locale = servletRequest.getLocale();
final step - timezone display name
Now we can call getDisplayName method with all required parameters.

return timeZone.getDisplayName(daylight, TimeZone.LONG, locale);
Solution
To put this all together, the final solution may look like this method

private String getServerTimeZoneDisplayName(){ final TimeZone timeZone = TimeZone.getDefault(); final boolean daylight = timeZone.inDaylightTime(new Date()); final Locale locale = servletRequest.getLocale(); return timeZone.getDisplayName(daylight, TimeZone.LONG, locale);}

References

Java TimeZone class
JEE ServletRequest class
JRA-15488 - Shows incorrect time (zone) when subscribing to filter

Sunday, April 12, 2009

New API for camera tools using JAVA

Hi,

Here's a new API for accessing any digital camera using java..

http://jphoto.sourceforge.net/

how to detect usb device connected to system using java code

Hi Friends,

Here's d code..

import java.io.*;

/**
* Waits for USB devices to be plugged in/unplugged and outputs a message
*
*
*@author Ujjwal Soni
*@version 1.0, 16/04/2009
*/
public class FindDrive
{
/**
* Application Entry Point
*/
public static void main(String[] args)
{
String[] letters = new String[]{ "A", "B", "C", "D", "E", "F", "G", "H", "I"};
File[] drives = new File[letters.length];
boolean[] isDrive = new boolean[letters.length];

// init the file objects and the initial drive state
for ( int i = 0; i < letters.length; ++i )
{
drives[i] = new File(letters[i]+":/");

isDrive[i] = drives[i].canRead();
}

System.out.println("FindDrive: waiting for devices...");

// loop indefinitely
while(true)
{
// check each drive
for ( int i = 0; i < letters.length; ++i )
{
boolean pluggedIn = drives[i].canRead();

// if the state has changed output a message
if ( pluggedIn != isDrive[i] )
{
if ( pluggedIn )
System.out.println("Drive "+letters[i]+" has been plugged in");
else
System.out.println("Drive "+letters[i]+" has been unplugged");

isDrive[i] = pluggedIn;
}
}

// wait before looping
try { Thread.sleep(100); }
catch (InterruptedException e) { /* do nothing */ }

}
}
}