Deprecated Classes

[rick.huby]

I have been developing Java for a few years now and every now and then
I will come across a useful class and find that it is Deprecated.
Sometimes I will look for an alternative but sometimes I don't.

OK - so I am sure that whatever useful functionality I found will be
present somewhere else, but my question is, is there actually any
reason not to use such classes? JVM will surely never totally drop
these classes so why the need for the compiler to flag them?

 

[Matthias Fraass]

Hi Rick,

OK - so I am sure that whatever useful functionality I found will be
present somewhere else, but my question is, is there actually any
reason not to use such classes?

Yep. The flag "deprecated" means that the class or method might (read:
will) be removed in the next version. So if you wish your software to
run on later versions of the API without changes, you should stay clear
of deprecated classes and methods.

Matthias

 

[Thomas Weidenfeller]

I have been developing Java for a few years now and every now and then
I will come across a useful class and find that it is Deprecated.

I think you mean methods. There are much more individual methods
deprecated than whole classes.

Sometimes I will look for an alternative but sometimes I don't.

Yes, sometimes there is non. E.g. in cases where it later turned out
that it is impossible to provide a reliable implementation across all
possible platforms.

OK - so I am sure that whatever useful functionality I found will be
present somewhere else, but my question is, is there actually any
reason not to use such classes?

Some are just deprecated to comply to naming conventions, e.g. for
JavaBeans (e.g. methods in AWT/Swing). But quite a number of methods are
deprecated because they never worked, never worked in a reliable, cross
platform way, or simply do something in the completely wrong way.

Fo example, thread handling has a bunch of deprecated methods because
they can't be implemented in a reliable way - and there is no
replacement. Date had a much to naive view of the date/time handling in
the world. Or String and IO Streams had methods which messed up
character encodings and didn't correctly distinguish between bytes and
chars.

JVM will surely never totally drop
these classes so why the need for the compiler to flag them?

Because using them is indeed often dangerous, for reasons explained
above. A deprecated warning from the compiler is something which
deserves an intensive look.

Regarding the complete removal of them from the VM. Well, at some point
Sun might indeed start to do this. Java would not be the only language
where features first had been declared obsolete or deprecated and then
removed a few years and major revisions later - to get rid of the cruft
which had accumulated over time.

Maybe it happens in ten years, maybe in one, or maybe never. But better
save than sorry.

/Thomas

 

[Ryan Stewart]

I have been developing Java for a few years now and every now and then
I will come across a useful class and find that it is Deprecated.
Sometimes I will look for an alternative but sometimes I don't.

OK - so I am sure that whatever useful functionality I found will be
present somewhere else, but my question is, is there actually any
reason not to use such classes? JVM will surely never totally drop
these classes so why the need for the compiler to flag them?

If you're talking about the core Java API, then sure, it will probably be around
for some time. Language designers have to be extremely careful about removing
features. Independent code libraries, on the other hannd, may remove things
*much* faster. If you use Struts for example, and plan on upgrading, you better
clean up your deprecations ASAP. Those people seem to enjoy dropping things from
their code.

 

[rick.huby]

I see all of your points - but taking the Date example (which is what I
was using when I posted this) - I think it was the getDay, getMonth and
getYear methods that are deprecated. What if I had written a program
using these when it did comply? Would I just be scuppered in the years
to come when (well if) Sun took it out?

I guess my point is that surely it is best for Sun to never take
anything out - surely just creating a new class or method to deal with
it, whilst leaving the old functionality in. Saying that I guess that
is what they have done with GregorianCalendar and Calendar.

Thanks for the info though. I think I am just a bit annoyed cos the
Date one is so simple and clean. Guess I'll have to work with that
convuluted GregorianCalendar instead then!

 

[Thomas Weidenfeller]

I see all of your points - but taking the Date example (which is what I
was using when I posted this) - I think it was the getDay, getMonth and
getYear methods that are deprecated. What if I had written a program
using these when it did comply? Would I just be scuppered in the years
to come when (well if) Sun took it out?

How much risk are you willing to take and how much effort do you want to
spend? If you want a high risk, low effort approach leave it in. If you
want a low risk, medium effort approach, take it out now (use Calendar
instead). Since you complained about the compiler, the compiler did its
job and informed you about a risk. Now it is time for you to do your job
and make a decision.

I guess my point is that surely it is best for Sun to never take
anything out

Why? Not having to maintain something is a very good reason to take
stuff out.

/Thomas