Should I add try/catch around when casting on an attribute of JSP implicit object?

Question

Hi all:

Basically what I mean is like this:

List<String[]> routes = (List<String[]>)application.getAttribute("routes");

For the above code, it tries to get an attribute named "routes" from the JSP implicit object - application. But as everyone knows, after this line of code, routes may very well contains a null - which means this application hasn't got an attribute named "routes".

Is this "casting on null" good programming practice in Java or not?

Basically I try to avoid exceptions such as java.io.InvalidCastException

I reckon things like this are more as "heritage" of Java 1.4 when generic types were not introduced to this language. So I guess everything stored in application attributes as Objects (Similar to traditional ArrayList). And when you do "downcast", there might be invalid casts.

What would you do in this case?

Update:

Just found that although in the implicit object application I did store a List of String arrays, when I do this :

List<double[]> routes = (List<double[]>)application.getAttribute("routes");

It doesn't produce any error... And I felt not comfortable already...

And even with this code:

out.print(routes.get(0));

It does print out something strange :

[Ljava.lang.String;@18b352f

Am I printing a "pointer to String"? I can finally get an exception like this:

out.print(routes.get(0)[1]);

with error :

java.lang.ClassCastException: [Ljava.lang.String;

Because it was me to add the application attribute, I know which type should it be cast to. I feel this is not "good enough", what if I forget the exact type? I know there are still some cases where this sort of thing would happen, such as in JSP/Servlet when you do casting on session attributes. Is there a better way to do this?

Before you say:"OMG, why you don't use Servlets???", I should justify my reason as this: - because my uni sucks, its server can only work with Servlets generated by JSP, and I don't really want to learn how to fix issues like that. look at my previous question on this , and this is uni homework, so I've got no other choice, forget all about war, WEB-INF,etc, but "code everything directly into JSP" - because the professors do that too. :)

Answer 1

Java uses type erasure to store collections. That is, the compiler enforces type safety, but reduces collections down to collections of Objects. So when you pull a list object out of your bean, it's a List<Object> rather than a List<Double>.

Because it's a collection, you can get the nth element (as you're doing). However the object you get is not what you expect. So when you pull out an element from the collection and cast it (to Double instead of String), the runtime will finally object.

[Ljava.lang.String;@18b352f is a reference to a String array, btw. (the '[' indicates an array).

For this reason (and others) I don't like storing collections of collections of types. I would prefer to create a particular object type (a container) and then ask that object for the elements I require. So you'll only have to cast once upon pulling the object from the bean, and then the complexity of handling arrays of doubles within lists is managed within this object (you can ask the container object to find elements for you, the logic of extracting/casting is in one place etc.)

Answer 2

Create a class ( Application ), store it once on ServletContext, and then call methods on that class in regular Java style.

In that Application class add a method.

// Make sure that ATTRIBUTE_NAME is somewhat unique.
private final static String ATTRIBUTE_NAME =
    Application.getClass( ).getName( );

List< String > myList;

public saveToAppContext ( ServletContext context )
{
    context.setAttribute( ATTRIBUTE_NAME, this );
}

public static Application getAttribute ( ServletContext context )
{
    return (Application) context.getAttribute( ATTRIBUTE_NAME );
}

// Because you store object in application scope, ensure that
// access methods are thread-safe
//
// This is just an example, you may need something with better
// performance
synchronized List< String > getStringList ( )
{
    return new ArrayList<String>(myList);
}

Now setup ServletContextListener that initializes and destroys your Application object when the ServletContext is loaded/unloaded

The contextInitialized method should create Application object and save it as an attribute on a ServletContext.