Java Native Font Viewer

Hi,

I just published a Java Applet that allows you to see how text looks when displayed using native fonts in various sizes.

The reason behind developing this applet is to experiment with ability to customize Swing application with better looking fonts that fonts used by default L&F.

Getting UNIX process ID in Java

We encountered a need to kill process spawned by Runtime.getRuntime().exec() in java in a bit friendlier way than Process.destroy() provides for. To do this, easiest way is to execute "kill -number PID".
Process ID is not available as part of the interface, and below is outlined hack to get that information:

public class test
{
public static void main( String[] str )
{
try
{
Runtime r = Runtime.getRuntime() ;
Process p = r.exec( "sleep 200" ) ;
java.lang.reflect.Method m = p.getClass().getDeclaredMethod( "ac cess$100" , new Class[] { p.getClass() } ) ;
m.setAccessible(true);
Object ret = m.invoke( p , new Object[] { p } ) ;
System.out.println( "process ID " + ret ) ;
System.out.println( "Press Ctrl-Z and ps to confirm" ) ;
Thread.sleep( 100000 ) ;
}
catch( Exception e )
{
e.printStackTrace() ;
}
System.exit(1);
}

}

Java, HashSet, Equals and hashCode

Today, I was working on the code that attempts to add 2D points to java.util.HashSet and test if HashSet contains them.
Point implemented equals method correctly, and accoding to java.util.Set documentation contains should: "Returns true if this set contains the specified element. More formally, returns true if and only if this set contains an element e such that (o==null ? e==null : o.equals(e))."

Well, documentation is wrong - and for a good reason - to implement specification as documented one would need to iterate all objects (in the set) for check for equality. What java.util.Set does is to use hashCode() value to index objects and compare them.

Therefore, if your class does not implement hashCode correctly, following test will fail:

ArrayList points = new ArrayList() ;
points.add( new IntPoint2D( 2, 2 ) ) ;
assertTrue(points.contains(new IntPoint2D(2,2)));


A dilemma is what to return as hashCode? I opted, knowing that my data will be local to implement hashCode as:

public int hashCode()
{
return (x & 0xffff) | ((y & 0xffff)<<16) ;
}


That will be good enough solution for the problem I'm facing.

There is corollary of this implementation:
1. if one assumes that hashCode() is natively implemented to return a pointer to underlying objects, and one tests for identity of the objects contained in the set (often the case) than Set works great.
2. if one needs to overload hashCode() and stuff more complex object in it, it needs to be aware of remote or not-so-remote chance that hashCode will return same value for two different objects, thereby yielding incorrect code.

Java and backward/forward compatibility

I just faced an issue with OrbitBehavior. Older Java3D don't have a field MOUSE_WHEEL_LISTENER, but it is a feature that I find very useful for my project (blog).

Here is a code on how I solved dynamical determination if runtime version of Java3D supports this new field without throwing an exception.

void addMouseWheelListener( int flags )
{
 int listenerFlags = MOUSE_LISTENER | MOUSE_MOTION_LISTENER | flags ;
 try
        {
  String field = "MOUSE_WHEEL_LISTENER";
  Class parent = getClass().getSuperclass(); 
         if( parent.getDeclaredField(field) != null )
         {
          int flag = parent.getDeclaredField(field).getInt(this);
          listenerFlags |= flag ;
         }
        }
        catch (SecurityException e)
        {
        }
        catch (NoSuchFieldException e)
        {
        }
        catch (IllegalArgumentException e)
        {
        }
        catch (IllegalAccessException e)
        {
        }
 setListenerFlags(listenerFlags);  
}

As you can see I use reflection to check first if the field exist, and if and if it does I modify my listenerFlags with field's value.

Even if the field is visible in this class it does not need to be declared there. In my case field is declared in superclass.

Double clicking on JNLP not working on MacOS X

This is 2nd or 3rd time we have faced this problem - double-clicking on JNLP file does not start on a MacOS X.

Well, this time I think we got the culprit - /Applications/Utilities/Java folder had an "Java SE 6" file in it - a left-over file from installation of Java 6 SDK Developer Preview. Removing that file solved the problem.

So, people, if you have a problem w/ running JNLP - that may be the solution.