DateFormat question

[hrosser]

I have used code like:
DateFormat df = DateFormat.getDateInstance( );
which according to the API: "Gets the date formatter with the default
formatting style for the default locale". My question is: Since the
DateFormat class is abstract, what is going on behind the curtains? I
have to assume that some un-named but concrete subclass of the
DateFormat class is created, compiled, and instantiated, then assigned
to the df reference variable.
Is this the case?

 

[Daniel Dyer]

I have used code like:
DateFormat df = DateFormat.getDateInstance( );
which according to the API: "Gets the date formatter with the default
formatting style for the default locale". My question is: Since the
DateFormat class is abstract, what is going on behind the curtains? I
have to assume that some un-named but concrete subclass of the
DateFormat class is created, compiled, and instantiated, then assigned
to the df reference variable.
Is this the case?

It's something along those lines (although the class won't be dynamically
compiled).

The class isn't necessarily unnamed. It may be an anonymous inner class,
it could be a named static nested class, or maybe it is a package scope
top-level class that isn't documented in the API. Or it could just be
that you get an instance of SimpleDateFormat, which is a public class that
you can instantiate directly. I don't know exactly which type is
returned, but the idea is that you don't need to know. If you are
curious, you can call getClass() on the object returned and print out its
type.

If you want to know exactly what happens, the source code is included in
the src.zip file that is installed with the JDK (assuming you check the
source option when you install it).

Dan.

 

[Tom Hawtin]

just be that you get an instance of SimpleDateFormat, which is a public
class that you can instantiate directly. I don't know exactly which
type is returned, but the idea is that you don't need to know. If you
are curious, you can call getClass() on the object returned and print
out its type.

It's not entirely true that you don't need to know. If you want to do
some constrained input you need to more information than DateFormat, so
casting to SimpleDateFormat would be useful. Also if you serialise it,
you need to know whether you can deserialise it, and whether you are
likely to be able to deserialise it on other machines.

(IIRC, Sun's DateFormat implementation always returns SimpleDateFormat
instances, currently.)

Tom Hawtin

 

[Daniel Dyer]

It's not entirely true that you don't need to know. If you want to do
some constrained input you need to more information than DateFormat, so
casting to SimpleDateFormat would be useful. Also if you serialise it,
you need to know whether you can deserialise it, and whether you are
likely to be able to deserialise it on other machines.

Fair point, but *usually* it's enough just to know that you're getting a
DateFormat of some kind and in these cases you don't care what the
concrete type is.

In general, if you do need to cast to a more specific type than a method
declares to return, it raises questions about the design of the API or the
way you are using it. It's not necessarily wrong, you can't do much else
with interfaces like Serializable or java.util.RandomAccess. However, in
the case of casting the result of DateFormate.getDateInstance (a poorly
named method IMO) to SimpleDateFormat, perhaps you should just use
SimpleDateFormat directly if you need to be certain about the type?

Dan.

 

[Hal Rosser]

Fair point, but *usually* it's enough just to know that you're getting a
DateFormat of some kind and in these cases you don't care what the
concrete type is.

In general, if you do need to cast to a more specific type than a method
declares to return, it raises questions about the design of the API or the
way you are using it. It's not necessarily wrong, you can't do much else
with interfaces like Serializable or java.util.RandomAccess. However, in
the case of casting the result of DateFormate.getDateInstance (a poorly
named method IMO) to SimpleDateFormat, perhaps you should just use
SimpleDateFormat directly if you need to be certain about the type?

Dan.

===========
Thanks for the input, guys - I was just a little curious because the class
is abstract.
I use SimpleDateFormat because I can instantiate it and use the
parse(string) method in some date apps.
I'll look at the source code of DateFormat (when the fish stop biting).
=========

 

[Hal Rosser]

"Daniel Dyer" <"You don't need it"> wrote in message

I have used code like:
DateFormat df = DateFormat.getDateInstance( );
which according to the API: "Gets the date formatter with the default
formatting style for the default locale". My question is: Since the
DateFormat class is abstract, what is going on behind the curtains? I
have to assume that some un-named but concrete subclass of the
DateFormat class is created, compiled, and instantiated, then assigned
to the df reference variable.
Is this the case?

It's something along those lines (although the class won't be dynamically
compiled).

The class isn't necessarily unnamed. It may be an anonymous inner class,
it could be a named static nested class, or maybe it is a package scope
top-level class that isn't documented in the API. Or it could just be
that you get an instance of SimpleDateFormat, which is a public class that
you can instantiate directly. I don't know exactly which type is
returned, but the idea is that you don't need to know. If you are
curious, you can call getClass() on the object returned and print out its
type.

Your suggestion worked..
if I add this code after the line shown above:::
System.out.print(df.getClass().getName());
I see its an instance of SimpleDateFormat
Case closed! - and thanks