java5 « WordPress.com Tag Feed

Criar objeto JSON com XStream

cadocruz — Tue, 21 Jul 2009 14:28:20 +0000

Para criar um objeto JSON a partir de um objeto java é muito simples com o XStream. Primeiro precisa

Enum in Java 5 - Comparing == or .equals

Shan Kandaswamy — Fri, 10 Jul 2009 23:04:43 +0000

Its been a long time since I blogged and decided to start sharing my thoughts and experience on blogs starting today….

I had a interesting discussion with one of my developer yesterday and ended up in a heated discussion as in why we should use = = comparison for comparing two ENUM objects vs using .equals method. First of all to give a background on this topic, Java 5 introduced so called ENUM objects which is a very useful type-safety objects we can use in our development to control the values where in old school way we use to have static constants around….Read more on this http://java.sun.com/docs/books/tutorial/java/javaOO/enum.html

Difference between using == comparison and .equals comparison is that when we use == operator, we are actually comparing and verifying whether the references of the two objects are pointing to the same or not versus using .equals will actually check the value for tell if they are the same objects.

String str1 = "abc"; String str2 = "def";
if ( (str1 + str2) == "abcdef" )  // Bad way
{    ......}
if ( (str1 + str2).equals("abcdef") ) // Good way
{   .....
}

Now how is it good to compare Enums using == is same as .equals and what is the preferred way of comparing…..

Enums are single instance which holds only one value at a time. that being said you can actually check if the references of two enums are pointing to the same which is good…

In real practice do we aks our developers to use == comparison for enums only since it is ok to d so and use .equals for other object comparison.. I dont agree with that..why confuse people with two different standards…

I think thats why the author of Enum (Josh Bloch) has thought about the same and has overridden the .equals method and hascode to actually to do the == comparison under the hood so that the developers will get in to standard practice of using .equals for all the objects including Enum objects.

I personally prefer to use .equals for enums also… pen your thoughts…..

-Shan

Free Downloadable Java, J2EE, Struts, Spring, AJAX, JavaScript, CSS, XML EBooks

javadairy — Mon, 18 Aug 2008 16:16:00 +0000

Free Downloadable Java, J2EE, Struts, Spring, AJAX, JavaScript, CSS, XML EBooks

JBoss guide: How to enable SSL (HTTPS) on JBoss, as well as other "nice-to-know" configurations

roneiv — Thu, 03 Jan 2008 17:42:03 +0000

From time to time you might have the need of running a web application over https, or there can be requests of having Single-Sign-On between multiple web applications running on your server. This small jboss-guide will give you some clues on how to solve tasks like this, with configurations for both jboss-4.0.4.GA and jboss-4.2.2.GA. Since the name of the server instance might differ and it’s also possible to use custom names, I’ll refer to it as jboss/server/<NAME>/, but what I mean here is for example jboss/server/default/.

Changing the port that jboss runs on

For 4.0.4 you should locate the server.xml inside jboss/server/<NAME>/deploy/jbossweb-tomcat55.sar/, and then change the port=”8080″ parameter in the HTTP Connector to your wishes, for example port 80 as I have done it here.

For 4.2.2 you do exactly the same, but the server.xml is located inside jboss/server/<NAME>/deploy/jboss-web.deployer/ instead.

Make tomcat able to compile java5 – by default it doesn’t

If you have the need of using java5 (jdk 1.5), you need to set the source-level of the compiler. If you don’t do this and have deployed web-applications with java5 code, you will get exceptions during startup. For 4.0.4 edit the web.xml in jboss/server/<NAME>/deploy/jbossweb-tomcat55.sar/conf. Locate the jsp servlet by searching for <servlet-name>jsp</servlet-name>, and uncomment the section that enables jdk1.5 features:

  
      
         compilerSourceVM
         1.5

For 4.2.2 you find the web.xml inside jboss/server/<NAME>/deploy/jbossweb-deployer/conf. Locate the same servlet, and make sure that the parameters both for source & target compiler are set like this:

   	
        jsp
        org.apache.jasper.servlet.JspServlet
        
            fork
            false
        
        
            xpoweredBy
            false
        
        
         compilerSourceVM
         1.5
        
  	
         compilerTargetVM
         1.5

Activate support for Single Sign-On

For both versions, locate server.xml (4.0.4 = jboss/server/<NAME>/deploy/jbossweb-tomcat55.sar/, 4.2.2 = jboss/server/<NAME>/deploy/jboss-web.deployer/). Find the “Host” section, and uncomment the following Valve:

Then in your jboss-web.xml it’s important that all the web applications that are going to “exchange” credentials points to the same security-domain:


 	java:/jaas/USE_THE_SAME_APPLICATION_POLICY_HERE
	/YOUR_APPLICATION_ROOT

If you now open and logon to one application, going to another one running on the same server should not prompt you for username/password again. Note that there are alternatives also if you have applications running on different servers/locations – check the other Valves.

Enable SSL on JBoss

In this example I’m only using a self-signed certificate, but the procedure would be more or less the same even if you are going to use a certificate from a Certification Authority.

Generate the keystore with the following command

keytool -genkey -alias tomcat -keyalg RSA -keystore NAME_OF_KEYSTORE -validity NUMBER_OF_DAYS

Copy the file into the jboss/server/<NAME>/conf/ directory
Edit the server.xml (4.0.4 = jboss/server/<NAME>/deploy/jbossweb-tomcat55.sar/, 4.2.2 = jboss/server/<NAME>/deploy/jboss-web.deployer/).For 4.0.4 the SSL-connector should be configured like:
```
 
      
```
For 4.2.2, configure it like this:
```
 
```
Now you should be able to access your application through https. Remember to use https:// instead of http:// in your browser-url, or else it will fail.
Remember that if you want to disable the non-secured port 8080 (or custom), making sure that people can only access through https, comment and disable that connector in the same server.xml.

Tell jboss 4.2.2 to not use the bundled JSF 1.2 implementation

By default this version of jboss comes bundled with the Glassfish JSF 1.2 implementation. If you deploy web applications that use other implementations, like myfaces, you should tell jboss to use the implementations(s) deployed together with the web applications instead. Do this by adding the following to the web.xml of your application(s):

  
     org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL
     true

Access jboss-4.2.2GA using ip address instead of localhost – use the “-b” parameter

I’ve been using the 4.0.4 version for some time, and I could start it on my machine (accessing it through localhost:8080), and access it from other machines in my network it by using the ip-address of my machine instead of localhost. With 4.2.2, you can start it the same way and it will work from your machine by going localhost. But trying to start the application remotely from other machines by using the ip-address would fail, giving you a 404.

This is because before 4.2.2.GA, jboss was always bound to the any address “0.0.0.0″. But this was considered a security issue, and this default behavior was removed. It’s now up to the user to explicitly configure this.

What you need to do to solve it is to start the jboss with another parameter, you need to set the bind address for the jboss services. The following command would start a jboss server named “myserver” on ip 192.168.100.100:

  run.bat -c myserver -b 192.168.100.100

If you now try to start the application from other machines by using this IP it works! If you use the server named default you can leave out the -c parameter. It’s also possible to revert back to the “old configuration” by using -b 0.0.0.0, but this is not recommended.Ok, I hope that this small guide might be of help to someone!

Usage of new Java5 method - inheritedChannel()

Rajs — Fri, 28 Dec 2007 17:21:16 +0000

Posted in blog city on September 3rd 2004

I am struggling to understand how to use the new method inheritedChannel() in java.lang.System.
Any example code on the usage? The method returns an instance of Channel interface which has only two methods close() and isOpen(). So, unless one knows the exact class that is returned by this method (SocketChannel, DatagramChannel, ServerSocketChannel etc), there is nothing much that can be done with inheritedChannel method.

So, are developers expected to somehow “detect” (instanceof?) the exact class that is being returned and use this method? If that is indeed the intention, not sure what is the purpose of returning an interface that is useless.

Comments

#1	‘‘ posted this on Sat 4 Sep 2004, 12:37 am What would be the point of giving it a less specific return type? It gives the programmer a good idea about what is going on. Most types do not specialise Channel.The idea, I believe, is that a program would be written to expect the inherited channel to be something specific. Obviously giving a nice error message in the case of that expectation not being reached is a good idea. So a logind style program may start up a Java program as a particular user inheritting a SocketChannel. Listening to ports less than 1024 is not allowed for user programs under UNIX, therefore a web server may inherit a ServerSocketChannel bound to port 80. It’s tough if you want two channels, for instance to support both HTTP and HTTPS. Tom Hawtin [tackline@claranet.com]
#2	‘Rajs‘ posted this on Thu 9 Sep 2004, 4:06 pm To me looks like this is violating some fundamental principles of OO. The API is kind of forcing it’s users to always check for the return type. With out this one cannot do anything. It is kind of same as returning java.lang.Object. Ideally it would have better if there is some other interface or base class from which all these different channels are derived OR there should have been more methods that Channel interface must be enforcing. To me, it looks like a design issue.
#4	‘Rajs‘ posted this on Mon 4 Oct 2004, 2:50 am Anon, I am aware of the SelectorProvider api when I wrote this blog. That’s exactly the problem I was talking about. One has to do an “instance of” kind of operation to figure out which among the ServerSocketChannel, SocketChannel and DatagramChannel is returned. There is no other way to figure out.Rajs

Bnd is now Java5 aware

cdivilly — Wed, 29 Aug 2007 11:20:40 +0000

Update: Turns out not long after I wrote this, Bnd did gain awareness of Java 5 constructs. I found this out recently when rebuilding some code for the first time since late 2007. Maven as it is wont, updated its plugins to the latest versions, including the maven-bundle-plugin (which uses Bnd) and code which has not been changed in over a year suddenly stopped building. The Culprit? Undeclared dependencies on annotations, which previously went unnoticed by Bnd, were now being spotted by Bnd and duely reported as errors.

Peter Krien’s Bnd utility is a nice piece of work, one feature is that it can pretty accurately compute the correct set of packages for the Import-Package directive of a bundle. Just be aware that it is designed for Java 1.4 and earlier and therefore does not examine new language constructs introduced in Java5 such as annotations and static imports.

If you forget this then you won’t see any problems until run-time (in the case of annotations with run-time retention), at the time when whatever introspection code consumes your annotated classes. Since the packages where the annotations were declared were omitted from the Import-Package declaration they will not be visible in the bundle’s class loading scope. Rather than failing to load the annotated class the JVM will instantiate the class as normal, but omit the annotation reflection data, i.e. Class.getAnnotation() will return null.

The solution is of course to add the packages where the missing annotations are declared to the Import-Package directive, you need to use an explicit package name, a wild-card pattern will not suffice (since Bnd attempts to refine all wild card patterns down to the subset of actual uses).I generally use a statement something like:

Import-Package: com.foo.annotations.pkg, *

This makes Bnd add the explicit import for the missing annotation package and leaves it to compute all other imports for you

Improper use of Generics could breach type safety

Deepak Anupalli — Tue, 20 Mar 2007 02:31:51 +0000

I was going through Java discussion forums and happened to come across an interesting discussion related to Generics. It was about a loop hole in the Java Generics feature that allows a method to throw a Checked Exception without declaring it in the throws clause.

This is definitely going to be freaky and I wouldn’t encourage you to take advantage of this in your development. Initially I thought this could be a loop hole in the Compiler implementation, but later realized that the behavior is inherent with the Generics design.

public class RethrowCheckedException {
    public static void rethrow(Throwable t) {//No throws clause
        RethrowCheckedException.<RuntimeException>throwing(t);
    }

    public static <T extends Throwable> void throwing(Throwable t) throws T {
        throw (T)t;
    }
    public static void main(String[] args) {
        try {
            throw new Exception("dummy");
        } catch (Exception e) {
            rethrow(e);
        }
    }
}

Using the rethrow() method we can make java.lang.Exception to escape from main() without declaring it in its throws clause. The type <RuntimeException> specified while invoking the throwing() method is know as “explicit type argument”. (which is complementary to the type inference discussed below)

Type Inference

To understand how the above thing works, we need to get an idea about type inference and explicit typing. Take a look at the the following example

public class ArrayStore {
    public static <T> void store(T[] array, T item) {
        if (array.length > 0)
            array[0] = item;
    }
    public static void main(String[] args) {
        store(new String[1], "abc"); //ok
        store(new String[1], new Integer(10)); //??
    }
}

Surprisingly, both the store method invocations shown, compile. Compiler infers T to String for the first store() invocation as both the arguments are Strings, this process is known as “type inference”. We expect the second one to fail as T cannot be evaluated to both a String as well as an Integer. But, the Compiler infers T to a common super class or interface other than java.lang.Object. As String and Integer have Serializable and Comparable as super interfaces, Compiler deduces T to be a Serializable or Comparable and allows compilation. The result of which is an ArrayStoreException at runtime, defying the whole point of Generics and type safety.

How do we resolve this problem? We can use the “explicit type argument” in such cases.

ArrayStore.<String>store(new String[1], new Integer(10)); //compilation Error

Explicitly specifying the type argument as String, forces the compiler to evaluate T to String (overriding the compiler’s type inference mechanism) and hence compilation fails.

Now that we got a hang on type inference, we’ll get back to the loop hole.

public static <T extends Throwable> void throwing(Throwable t) throws T {
    throw (T)t;
}

The throwing() method defines type <T extends Throwable> which is declared in its throws clause and is no way related to the argument passed. The rethrow() method explicitly specifies the type as RuntimeException, making the method signature of the throwing() method to appear as shown below, at compile time.

public static void throwing(Throwable t) throws RuntimeException {
    throw (RuntimeException)t;
}

Compiler evaluates the method signature by replacing the type variable T with its inferred or explicitly specified type, which is RuntimeException in our case. As a result of this Compiler doesn’t enforce exception handling or re-throwing it in the rethrow() method. After compilation and type erasure, all the generic type information is erased as shown below.

public static void throwing(Throwable t) throws Throwable {
    throw (Throwable)t;
}

Some thoughts
Type inference or explicit type argument could do some damage when the Generic type information is not captured properly. In the loop hole case, since the exception argument passed to the throwing() method is not related to the Generic type (T), compiler was blind folded. If we modify the method signature as shown below, method invocation fails to compile.

public static <T extends Throwable> void throwing(T t) throws T {
    throw (T)t;
}

Similarly, in the ArrayStore example we cannot expect the programmer to invoke the store method by explicitly specifying the type everytime at the calling context. A better way of capturing the generic type information in this case is to establish a relationship between Type variables(T’s), to enforce expected compile time checks.

public static <T, S extends T> void store(T[] array, S item) { ... }

And interestingly, the following generic type declarations work as expected unlike the ArrayStore example.

public static <T> setMap(Map<T, T> map) { ... }
public static <T> addToList(List<T> list, T element) { ...}

addToList(new ArrayList<String>(), new Integer(10)); //fails to compile

Java Language Specification(JLS) 3.0, 15.12.2.7 states “The process of type inference is inherently complex.”

Yes indeed it is really complex to understand type inference. All this appeals for better understanding of the type inference mechanism and how it applies. Probably you can get more information from FAQ by Angelika Langer.

Technorati : deepjava, java, java5
Del.icio.us : java, java5

Understanding Generics with Collections

Deepak Anupalli — Fri, 22 Dec 2006 06:09:06 +0000

In Java (prior to 5.0), a lot of times you are compelled to downcast your object to a more specific one. For example, when you add a String to a List, and when you want to retrieve your String back then you need to downcast.

List myList = new ArrayList();
myList.add("abc");
String str = (String)myList.get(0);

Downcast is inevitable. Moreover, adding objects of any type to the list is allowed and the developer is responsible to remember the type of each object and perform the appropriate downcast while retrieving them. This gives a way to the type safety problems in Java, as every downcast in the code is a potential case for the wicked ClassCastException. Generics have been introduced to rescue us from these situations, they let you mark the collection to contain elements of a particular data type only, say a List of Strings. The syntax to specify a List of Strings would look like this. (Note: ‘type’ refers to any class definition in Java, e.g. String, Integer, Collection, MyClass etc. are all denoted as types.)

List<String> myList = new ArrayList<String>();
myList.add("abc");
String str = myList.get(0);

The syntax is fairly simple, you need to specify the ‘type’ of the Collection in the angular brackets following the Collection type. Such types are known as Generic types or Parameterized types. We’ll get to know more about defining collection types and substitution in the following sections.

With the above syntax, it is not allowed to add objects or retrieve objects of any other type other than String to the above List and doing that would result in a compile-time error. This is much better than the ClassCastException at runtime, and would definitely save a lot of your development time, isn’t it? And more importantly the downcast should be made extinct now, as the type of the elements within the collection is explicity informed to the compiler through the Generic syntax.

Purpose of Generics
Generics make your program well formed enabling the compiler to perform enough type checks based on the static type information provided and avoids unexpected type errors that could occur at runtime. Let us get into more practical matters.

Collections and Substitution rules
Collections are the primary motivation for Generics in Java.

Let us take a look at some substitution rules. The following are some legal assignments:

List<Integer> li = new ArrayList<Integer>();
Collection<Integer> ci = new LinkedList<Integer>();
Collection<Integer> cs = new HashSet<Integer>();
List lst = new ArrayList<Number>();
List<Integer> li = new ArrayList();//warning

Here is the substitution principle for collections, (Rule 1) RHS of the assignment should contain a Collection implementation compatible with that of LHS and generified with the same type as that of LHS. The last assignment two assignments are valid, these are allowed to provide compatibility of non-generic (prior to Java 5) code with the new generic approach and vice versa. But, if you compile your code with -Xlint:unchecked option, the last assignment results in a unchecked conversion warning. (Rule 2) Do not ignore such compilation warnings, as they indicate your code to be unsafe (could break at runtime with ClassCastExceptions).

List<String> ls = new ArrayList<String>();//1 
ls.add("abc");//2 
ls.add("xyz");//3 
Iterator its = ls.listIterator();//4 
while(its.next()) {//5 
    String s = its.next();//6 
    System.out.println("Element: "+s);
}

Does this compile? No, Iterator is not a generic type and hence the assignment of iterator’s element to the String ’s’ (line 6) fails with a compilation error. Basically, in line 4 we lost the type information while obtaining the iterator and so we need an explicit cast here. Hence, you need to make the Iterator parameterized with String type to avoid the explicit cast.

Iterator<String> its = ls.listIterator();//4

(Rule 3) When you get an iterator, keySet, entrySet or values from a collection, assign to an appropriate parameterized type as shown above. This is because, these methods are modified to return their corresponding generic types to benifit no-cast code. Most of the Java 5 aware IDEs can do this job for you automatically, rely on them.

The following assignments are invalid:

Set<String> ss = new HashSet<Integer>();//Incompatible Types
List<Object> lo = new ArrayList<String>();//compile-time error

Though String is a subtype of Object, the second assignment is not allowed. Collection of Objects is a bigger set comprising of elements of various types (Strings, Integers, Cats, Dogs etc.), but a Collection of Strings strictly contains Strings and both of these cannot be equated (Rule 4). In programmatic sense if this were allowed, we would end up adding objects of any type to a List of Strings, defying the purpose of generics and hence this is not allowed.

Well, with the above restriction, how would you implement a method that accepts a collection of any type, iterate over it and print the elements? For such purposes, Wildcards are introduced for generic types to represent unknown collections.

Wildcards
We know that Object[] is the supertype of all arrays, similarly Collection<?> is the supertype of all generic collections which is pronounced as “Collection of unknown”. (Note: Collection<?> represents List<?>, ArrayList<?>, HashSet<?> etc. And Collection<?> is only a reference type and you cannot instantiate it, i.e. new ArrayList<?>() or new HashSet<?>() is not allowed.) (Rule 5) Collections parameterized with wildcards cannot be instantiated.

Using Collection<?> we can implement the iterate and print method as shown below.

public void printElements(Collection<?> c) {
    for(Object o : c) {
        System.out.println(o);
    }
}
...
List<String> ls = new ArrayList<String>();
List<Cat> lc = new ArrayList<Cat>();
...
printElements(ls);
printElements(lc);

Is Collection<?> same as plain old Collection? No, there are lot of differences between the plain old Collection, Collection<?> and Collection<Object>.

The following are the differences between them:

Collection<?> is a homogenous collection that represents a family of generic instantiations of Collection (i.e. Collection<String>, Collection<Integer> etc.)
Collection<Object> is a heterogenous collection or a mixed bag that contains elements of all types, close to the plain old Collection but not same
Collection<?> ensures that you don’t add aribtrary objects, as we do not know the type of the collection (Rule 6)
Collection<?> cannot be treated as a read-only collection, as it allows remove() and clear() operations
You can assign Collection<String> or Collection<Number> to a Collection<?> reference type, but not to a Collection<Object> (Refer to Rule 4)

List<String> list = new ArrayList<String>();
list.add("Tiger");
list.add("Mustang");
Collection<?> c = list;
Object o = c.get(0); //returns "Tiger" downcasted to Object
c.contains("Tiger"); //returns true
Iterator itr = c.iterator();
while(itr.hasNext()) {
    Object o = itr.next();
    System.out.println(o);
}
c.remove("Mustang"); //removes "Mustang" from the List
c.add("Dolphin"); //compile-time error (as per Rule 6)

Collection<?> appears very restrictive as you do not known the type information. When you obtain your elements from this collection you need to work with objects and would sometimes end up in explicit cast. So, strictly encourage Collection<?> when you need no type specific operations (Rule 7). But, there would be very few such use-cases in practice, where as more frequently you may need to perform operations on a base interface and you do not bother about the implementation type. In such cases you can benifit with the ‘bounded wildcards’.

Bounded wildcards
List<? extends Number> is an example of a bounded wildcard. This represents a homogenous List that contains elements that are subtypes of Number. Bounded wildcards only indicate an unknown type which is a subtype of Number.

public void addInteger(List<? extends Number> lnum) {
    Number num = lnum.get(0);
    byte b = num.byteValue();
    lnum.add(new Integer(10));//not allowed, compile-time error
}

So, we can obtain elements from the collection assuming the type to be a Number. But, you are not allowed to add anything to the collection as we do not know which subtype of Number the collection contains.

Differences between List<Number> and List<? extends Number>:

List<Number> is a heterogenous collection of Number objects (i.e. it can contain instances of Integer, Float, Long, etc.)
List<? extends Number> represents a homogenous collection of Number or its subtypes. It is instantiated with any of List<Integer>, List<Float> etc.

“? extends Type” is known as the upper bound, and we also have “? super Type” which is the lower bound where the unknown type denotes a super type of the specified Type. This is rarely useful with collections but could come handy when we define our own generic types.

We’ll see more about defining generic types, generic methods and type erasure semantics in my next posts.

Bootstrapping static fields within enums

Deepak Anupalli — Fri, 08 Dec 2006 14:51:54 +0000

In my earlier post on enums in Java 5, we have seen that static fields cannot be accessed within the enum constructor. With this restriction we could run into few initialization problems discussed below.

The other day Rajiv found it difficult to initialize a static cache during enum bootstrap. The following is his enum:

public enum Tag {
    KEYWORDS(2, 25, true),
    DATE_CREATED(2, 55, false),
    HEADLINE(2, 105, false),
    …
    private int recordNo;
    private int datasetNo;
    private int isRepeat;

    private Tag(int recordNo, int datasetNo, int isRepeat) {
        this.recordNo = recordNo;
        this.datasetNo = datasetNo;
        this.isRepeat = isRepeat;
    }
    …
    public static Tag getTag(int recordNo, int datasetNo) {
        for(Tag tag : Tag.values()) { //$REVIEW$ optimize
            if(tag.getRecordNo() == recordNo && tag.getDatasetNo() == datasetNo){
                return tag;
            }
        }
    }
}

Rajiv says, “Deeps, check my implementation of getTag(int recordNo, int datasetNo). I would have liked to make a static map of (recordNo<<8 + datasetNo) vs Tag to make this method fast. Unfortunately, I cannot access that static map from the constructor.”

So, he would like to have a static cache of enums for easy retrieval based on their properties. But, the concern is where do we initialize this cache/map? In the discussion following the earlier post, we discussed that “enums are initialized before any static initializers are run”. Bang! We can initialize this cache in a static block as shown below (actually derived from Neal Gafter’s discussion on forum).

public enum Tag {
    KEYWORDS(2, 25, true),
    DATE_CREATED(2, 55, false),
    HEADLINE(2, 105, false),
    …
    private static Map<Integer, Tag> cache;
    static {
        cache = new HashMap<Integer, Tag>();
        for(Tag tag : values()) {
            int key = tag.getRecordNo()<<8 + tag.getDatasetNo();
            cache.put(key, tag);
        }
    }
    …
    public static Tag getTag(int recordNo, int datasetNo) {
        int key = recordNo<<8 + datasetNo;
        return cache.get(key);
    }
}

Enum constants are already constructed, by the time static block initializer is run. This is a ridiculous pattern to follow though, when you need to boot strap your static fields within enums.

Type Safe Enumerations in Java 5.0

Deepak Anupalli — Tue, 21 Nov 2006 17:12:33 +0000

The new enum construct in Java 5.0 is used to define enumerations. Enumerations are not new to programming langugages, they existed in C, C++, SmallTalk etc. In Java 5.0 they had to be introduced to overcome safety and ease of use concerns in using the earlier enumeration approaches. Let us take a look at how we used to define enumeration constants prior to Java 5.0.

Type Safety concern for enumerations
In programming sense, enumerations can be treated as just a sequence of integers. Let us define an enumeration that represents a sample of Colors (RED, BLUE, YELLOW, GREEN, ORANGE & PURPLE).

public interface Colors {
    final int RED=1, BLUE=2, YELLOW=3, GREEN=4, ORANGE=5, PURPLE=6;
}
public interface Shape {
    void applyColor(int color);
    …
}
Shape box = new Rectangle();//Rectangle implements Shape
box.applyColor(Colors.RED);

Whereever we need a color, we use the constants defined in Colors. But, what if an integer that is not defined for any of the constants is passed to the applyColor() method? Say box.applyColor(8), It fails. Shape.applyColor() method takes any integer, there is no “Type Safety”.

So, it is not true to say enumerations are a sequence of integers. Enumerations should be treated as a separate type. Let us re-define the enumeration to take care of Type Safety.

Enumerated Pattern before Java 5

Prior to Java 5 release, enumerations were defined using the Enumerated pattern described in the book, Effective Java. Enumerated pattern takes care of type safety.

public final class Color
{
    public static final Color RED = new Color(1);
    public static final Color BLUE = new Color(2);
    private int color;

    //ensures singleton and no instantiations
    private Color(int color) { this.color = color; }
    public int getColor() { return color; }
    //overridden to give meaningful values
    public String toString() {
        switch (getColor()) {
            case 1: return “RED” break;
            …
        }
    }

public boolean equals(Object obj) { return this == obj;}
}

public interface Shape {
//The method takes a Color type, not integer
void applyColor(Color color);
}

This enumerated pattern ensures that the Color type is Singleton and provides type safe enumerated constants RED, BLUE, YELLOW, GREEN etc. The toString() method is overriden to provide meaningful information when the constants are printed and the equals() method checks the reference equality of enumerated types, as these are singleton instances.

Is this all enough to define a complete enumerated type? No.

Disadvantages of the above enumerated pattern
The enumerated pattern approach has the following drawbacks:

Enumerated types are not Serializable and Comparable by default
Incase, if we make them Serializable, Serialization of Color creates a new instance of the same Color. The equals() method fails to identify the equality of a serialized and a non-serialized Color. (Ofcourse, we can fix this by custom serialization of enumerated types. But, this leads to writing more boiler plate code for each enumerated type)
Color instances cannot be directly used in the switch-case statements, instead you need to use the color value
If a new color is added between existing constants or if the order of Colors is changed, clients must be recompiled. (a.k.a Brittleness)
No support for iterating over the defined enumerated constants

Java 5 enum
enum provides a cleaner syntax to define enumerations in Java. And also overcomes all the drawbacks set by the earlier Enumerated pattern.

enums are type safe
enums provide default implementation for toString(), equals(), hashCode() methods (Umm.. no extra work)
enums are Comparable and Serializable by default
enums are allowed to be used in switch-case statements
enums are allowed to implement interfaces
Adding new enum constants, does not require re-compilation of the client code
A static values() method is provided that returns an array of defined enumerated constants

Let us define the Color enumeration using Java 5 enum construct.
public enum Color {
RED, BLUE, YELLOW, GREEN, ORANGE, PURPLE
}

The enumerated types RED, BLUE, YELLOW etc. are of type Color.

java.lang.Enum is the supertype of all enums and the Color enum implicitly extends java.lang.Enum. java.lang.Enum provides implementation for equals(), toString(), and hashCode() methods and it implements Serializable and Comparable interfaces. Enums are full-fledged java classes and can have arbitrary methods and fields. Enums can implement interfaces. Enums can have constructors and they take arguments in the declaration as shown below.

public enum Color {
    RED(625, 740),
    ORANGE(590, 625),
    YELLOW(565, 590),
    …

//Electro-magnetic Spectrum wavelength in nm

    int startWavelength;
    int endWavelength;
    Color(start, end) {
        this.startWavelength = start;
        this.endWavelength = end;
    }
    public int getStartWavelength() { return startWavelength; }
    public int getEndWavelength() { return endWavelength; }
    public static void main(String[] args) {
        System.out.println(“Red color’s wavelength range, “
            + RED.getStartWavelength()+” ~ “+RED.getEndWavelength());
    }
}

If the Enumerated types have any attributes, a constructor is used to associate these attributes and the Getter methods expose these attributes.

Constant specific methods
If the implementation of methods vary for each Constant, then you can implement the methods specific to a constant.
public enum Color {
    RED { public Color complimentary() { return GREEN; }},
    BLUE { public Color complimentary() { return ORANGE; }},
    YELLOW { public Color complimentary() { return PURPLE; }},
    …
    public abstract Color complimentary();
}

Each color has its own complementary color and to implement this we can use constant specific methods to return the complementary color. The method complementary() has to be either defined as an abstract method within Color enum or could be a method in one of the implemented interfaces.

Restrictions on enum types
Though enum types are full-fledged classes, the following are not allowed with enums:

enums cannot be subclassed
enums cannot have public constructor
enums are not allowed to be instantiated (using new)
enums cannot be cloned

All of these are enforced during compile-time.

Serialization of enums
Serialization mechanism ensures that new enum instances are not created on serialization and de-serialization (ensuring singleton behaviour). In a distributed environment when an enum is serialized from one JVM to another JVM, enum’s state is not serialized. Hence, it is not encouraged to have state with enums which is updated by the applications. You can only have constant attributes that are initialized by the constructor.

Collections built for enums
java.util.EnumMap and java.util.EnumSet are the collections added for use with enum types. They provide a compact and efficient implementation for enum types. These collections are not synchronized and when used in multi-threaded environment, applications should take care of synchronizing the operations on the collection.

EnumMap and EnumSet are homogenous collections of the same enum type. They cannot be used to operate on different enum types at the same time.

public enum Color {
RED, BLUE, YELLOW, GREEN, ORANGE, PURPLE;

private static EnumSet<Color> primary;
private static EnumSet<Color> secondary;

    public static EnumSet<Color> getPrimaryColors() {
        if(primary == null)
            return EnumSet.of(RED, BLUE, YELLOW);
        return primary;
    }

    public static EnumSet<Color> getSecondaryColors() {
        if(secondary == null)
            return EnumSet.complementOf(getPrimaryColors());
        return secondary;
    }

    public static void main(String[] args) {
        System.out.println(“Primary Colors: “+Color.getPrimaryColors());
        System.out.println(“Secondary Colors: “+Color.getSecondaryColors());
        System.out.println(“Universe: “+EnumSet.allOf(Color.class));
    }
}

Few gotchas about enums
However, there are few things which could probably be improved in the coming versions of Java.

Currently null can be passed as a method parameter or assigned where an enum is expected. A compile-time verification for null enum assignment would probably avoid all those extra null checks that we need to incorporate in our code.
Static fields within enums cannot be accessed in its constructor. But, static methods are allowed to be invoked. The compiler enforces verification only for static fields and not methods.
However, enum constructors are invoked before static initialization is performed and hence the static fields would not be initialized. So, if you invoke static methods from the constructor which inturn access static fields, they would all be un-initialized.

Enum syntax
public enum <your_enum> {
    <enum_constant1> (<constructor_params>) {
        <anonymous_class_declaration>
    },
    <enum_constant2> (…) {…},
    …;
    //enum constructor [optional]
    <your_enum> (<constructor_param_defs>) {
        //static fields within enum cannot be accessed
    }
    <class body> [optional]
}

Dalších par ukázek z Javy 5

Pavel Kolesnikov — Thu, 21 Apr 2005 10:18:03 +0000

Co třeba takovýto (svou jednoduchostí už na úrovni skriptovacích jazyků) kód vypisující řádky textového souboru:

TextFile textfile = new TextFile(new File(f), "UTF-8");
int lineNumber = 0;
for(String line : textfile) {
   System.out.printf("%6d: %s%n", ++lineNumber, line)
}

Tento příklad a povídání o dalších vybraných novinkách “Tygří” javy najdete v článku Davida Flanagan na OnJava.com nazvaném Five Favorite Features from 5.0