Thursday, December 18, 2008

Online Image Manipulators

Today, I was just googling for the online image manipulators and found this blog entry worth keeping track of. Thanks for the info. Just to copy the most relevant information from that page:

A list of free online image editors:

* Snipshot
* Picnik
* FotoFlexer
* Pixer.us
* Pixlr
* Phixr
* WebPicTool
* Splashup
* Resizr
* Photoshop Express
* Imageeditor.net

Thursday, May 15, 2008

JNDI and OC4J

Got stuck into something and considered it interesting to keep a note of. If you are a J2EE developer and using Oracle Application server (OC4J) then the following information may be useful.

In OC4J if you have user created threads (not implicit threads of Servlet etc) and you want to do a JNDI lookup in that thread, then an OC4J start-up option needs to be set, otherwise the lookup would fail. The option is "-userThreads" and can be set using EM console (OC4J -> Administration -> Server Properties -> Start-parameters: OC4J Options).

Here is the detail of all such available OC4J options.

Tuesday, April 8, 2008

IoC and DI

Good read on IoC and DI

http://martinfowler.com/bliki/InversionOfControl.html
http://martinfowler.com/articles/injection.html

Something that cleared my thought process (an excerpt from one of the articles)
Inversion of Control is a key part of what makes a framework different to a library.

Tuesday, February 12, 2008

Autoboxing and Equality

Tiger(JDK 5) has introduced a lot of features and in turn lots more to dig into. Here I want to explain the issues that arise due to equality comparisons and Autoboxing/Auto-unboxing.

Since, equality operator (==) can be used with reference variables and primitive types, the first question is what happens when we equate reference wrapper variable with its corresponding primitive type.

int i = 1;
Integer iObj = new Integer(i);
System.out.println(i==iObj);


Here, the iObj will be unboxed to a primitive type and the result of the expression would be similar to the comparison of int value with iObj.intValue().

If we equate two reference wrapper variables it is not the value comparisons but object comparison.

Also, JLS recommends that the same wrapper objects should be returned on autoboxing for lower values of the integer primitives. This accounts for some of the unusual behaviour of the equality expressions.

The program and the output below self-explains the issues

package autoboxing;

public class EqualityTest {

public static void main(String[] args) {
// any arbitrary value
int i = 236459;
Integer iObj = new Integer(i);

/*
* if wrapper object is equated with primitive
* types wrapper object would be converted to
* primitive type and then compared
*/

if(i == iObj) {
System.out.println("Integers are equal: " + i);
}

for(int loop = -128; loop < Integer.MAX_VALUE; loop++) {
Integer iObj1 = loop;
Integer iObj2 = loop;

/*
* this is a reference equality check and not value
* comparison
*/
if(iObj1 == iObj2) {

} else {
System.out.println("Integers are not equal: " + loop);
break;
}
}

for(int loop = -128; loop < Integer.MAX_VALUE; loop++) {
Integer iObj1 = new Integer(loop);
Integer iObj2 = new Integer(loop);

/*
* this is a reference equality check and not value
* comparison
*/
if(iObj1 == iObj2) {

} else {
System.out.println("Integers are not equal: " + loop);
break;
}
}
}
}


Output:
Integers are equal: 236459
Integers are not equal: 128
Integers are not equal: -128

Thursday, January 24, 2008

Calling non-public methods

A very small and simple hack to call non-public methods in Java.

Problem
~~~~~~~
A non-public method of a class has to be called from another class. Both the classes are in different packages.

package apipackage;
public class APIClass {
void methodA() {
System.out.println("methodA Called");
}
}

package clientpackage;
public class ClientClass {
void methodACaller() {
...
...
...
}
}


Fill in the dotted lines to call methodA of APIClass.

Solution
~~~~~~~~
package clientpackage;
// import statements
public class ClientClass {
void methodACaller() {
apipackage.APIClass apiObject = new apipackage.APIClass();
Method methodA = apipackage.APIClass.class.getDeclaredMethod("methodA", null);
methodA.setAccessible(true); // this makes it possible to invoke methodA
methodA.invoke(apiObject, null);
}
}

One important thing to remember is to call "getDeclaredMethod" and not "getMethod" to obtain the Method object.

From Java docs:
"getMethod returns a Method object that reflects the specified public member method of the class"

/*
This would not work
Method methodA = apipackage.APIClass.class.getMethod("methodA", null);
*/

Friday, October 26, 2007

JavaSpecialists Notes - II

Issue 18: Class names don't identify a class

We can also let these two "A" classes have a common superclass. For example, 
say we have a superclass called Parent.java located in the root directory:

//: Parent.java
public class Parent {
public String toString() {
return "Thanks for caring... but what do you want??? ";
}
}

And our A.java classes are now written as:

//: a1/A.java
public class A extends Parent {
public String toString() {
return super.toString() + "This is the first class";
}
}
//: a2/A.java
public class A extends Parent {
public String toString() {
return super.toString() + "This is the second class";
}
}

We then need to have a common parent ClassLoader which we use to load the
Parent.class file. We have to specify the location to start looking for
Parent.class, and the locations are searched in a hierarchical fasion. Note that the
compile-time Parent class is loaded with a different ClassLoader to the one loaded
with the URLClassLoader called "parent" so they refer to a different class
altogether, which means we cannot type-cast an instance of "A" to a Parent. Also, if
we load the class "Parent" without using the classloader, we will see that it is not
equal to the superclass of "c1".

//: Loader.java
import java.net.*;
public class Loader {
public static void main(String[] args) throws Exception {
ClassLoader parent = new URLClassLoader(
new URL[] {new URL("file:./")}, null);
ClassLoader a1 = new URLClassLoader(
new URL[] {new URL("file:a1/")}, parent);
ClassLoader a2 = new URLClassLoader(
new URL[] {new URL("file:a2/")}, parent);
Class c1 = a1.loadClass("A");
Class c2 = a2.loadClass("A");
System.out.println(c1.newInstance());
System.out.println(c2.newInstance());
System.out.println(
c1.getSuperclass().equals(c2.getSuperclass()));
System.out.println(
Class.forName("Parent").equals(c1.getSuperclass()));
try {
Parent p = (Parent)c1.newInstance();
} catch(ClassCastException ex) {
ex.printStackTrace();
}
System.out.println("We expected to get ClassCastException");
}
}

Thanks for caring... but what do you want??? This is the first class
Thanks for caring... but what do you want??? This is the second class
true
false
java.lang.ClassCastException: A
at Loader.main(Loader.java:18)
We expected to get ClassCastException

Note that the super classes of both "A" classes are equal.

Where is this all this useful? It is very useful when you have an application server
into which you want to deploy business objects written by different people. It is
entirely feasible that you have two developers with different versions of classes
deploying their applications onto the same server. You don't necessarily want to
start a new VM for each deployment, and so with ClassLoaders it is possible to have
lots of classes with the same name running in the same memory space but not
conflicting with one another. They would also share the common JDK classes with one
another, so we would not have to have a java.util.ArrayList class loaded for each of
the ClassLoaders.

Monday, October 22, 2007

JavaSpecialists Notes - I

This is the first part of a series of blogs that I would write in order to keep the crux of all the JavaSpecialists Newsletters at one place for a quick reference. It would include the links and excerpts from the original newsletter.

Issue 1: Deadlocks

In Swing, all GUI components have to be changed from within the Swing thread.
This means that you cannot execute jLabel1.setText("blabla") from within any thread
besides the Swing thread.
If you have change any GUI from another thread you should rather say:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
jLabel1.setText("blabla");
}
}

Issue 2: Anonymous Inner Classes

If you wanted to pass in a Collection instead of an array it would look as follows:

Collection temp_names = new Vector(3);
temp_names.add("Heinz");
temp_names.add("John");
temp_names.add("Anton");
universityRegistration.addNames(temp_names);

The ability to avoid local temporary variables with arrays was always a strong
deciding factor in defining interfaces to my classes because I could get away with
one line of code instead of five, and the less lines of code the better. I would
therefore rather define addNames(String[] names) than addNames(Collection names) even
if it meant I would have to convert backwards and forwards between arrays and
collections. However, with anonymous inner classes we can get the same effect seen
above but with collections:

universityRegistration.addNames(new Vector(3)
{{ add("Heinz"); add("John"); add("Anton"); }});

Issue 8: boolean comparisons

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (pentiumTMcpu == true) {
/* work out incorrect salary using double */
}

This will compile fine in Java, but so will the following, which assigns true to
pentiumTMcpu and will always work out the salary using the Pentium bug (younger
readers would not remember):

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (pentiumTMcpu = true) {
/* this code will always be executed */
}

Instead, it would be a lot safer to write

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (pentiumTMcpu) {
/* work out incorrect salary using double */
}
.........
.........
.........
There is a technique used alot in Microsoft's C++ libraries in which they would have
written the comparison as:

boolean pentiumTMcpu = Utils.isCpuAPentium();
if (true == pentiumTMcpu) {
/* work out incorrect salary using double */
}

More would follow as and when I would read other issues. :)