CODEWITHSUNDEEP
javaserializationannotationsmetadatajava-5
ElenaT
ElenaT

Reputation: 2630

Why wasn't java.io.Serializable deprecated in Java 5?

In pre Java 5, there were no annotations. As a result you could not add metadata to a class.

To mark a class as serializable, you had to implement the Serializable interface (which is just that, a marker) and use further transient keywords to mark a field as non serializable if needed, something like:

public class MyClass implements Serializable {
   ...
   private transient Bla field;
   ...
}

Now you could theoretically make use of annotations (this is a perfect use for them) and have:

@Serializable
public class MyClass {
   ...
   @Transient
   private Bla field;
   ...
}

But the interface and the keyword were not deprecated and no annotation was added in Java 5 to replace them.

What are the considerations for this decision to keep the interface and the keyword?

Off course there is the issue of compatibility with pre Java 5 code, but at some point that will end (e.g. related to the new features of generics, the JLS specifies that It is possible that future versions of the Java programming language will disallow the use of raw types). So why not prepare the way for serialized annotations also?

Any thoughts? (although I would prefer concrete references :D which I was unable to find)

Upvotes: 23

Views: 6282

Answers (4)

Boann
Boann

Reputation: 50021

Deprecation is for things that are actively harmful. What you're suggesting is forcing authors of eight years of existing Java code (at the time) to rewrite it, for no advantage, just to shut up the deprecation compiler warnings, to get back to the fully correct code they had with Java 1.4. That would not be useful.

Upvotes: -1

Stephen C
Stephen C

Reputation: 718788

Off course there is the issue of compatibility with pre Java 5 code ...

Yes. This is the root of the problem.

  • If they @deprecated the Serializable interface in (say) Java 5, then lots of old pre-Java 5 code would give warnings (or errors depending on compiler switches).

  • There's nothing actually wrong with using Serializable and "forcing" people to replace it is annoying. (People have better things to do ...)

  • When people have "fixed" this in their code, it will no longer compile using a pre-Java 5 compiler, or run on a pre-Java 5 JVM.

  • It is a bad idea to do things that make the compiler systematically "cry wolf".

... but at some point that will end.

In reality, the chance of this actually happening is (IMO) small. As far as I'm aware, Sun / Oracle have never removed a deprecated feature. Not even dangerous ones like Thread.stop() and friends.

As a footnote, the Go developers are taking a different approach to this problem. When they want to change a language or library feature, they just do it. They provide a converter that will automatically rewrite your code as required.

Upvotes: 10

Jesper
Jesper

Reputation: 206796

Serializable and transient are indeed two things that could have been replaced by annotations.

They haven't been deprecated probably because there are a lot of programs that use Serializable and it would have been annoying for millions if developers if the compiler would suddenly start spewing out thousands of deprecation warnings.

There are lots of other things in the standard Java API that could have been deprecated long ago - for example, the legacy collection classes Vector and Hashtable (and I'm sure you can easily find many more things). And there are other things that could have been implemented using annotations (for example the keyword volatile, strictfp and synchronized).

Upvotes: 2

Ethan Cabiac
Ethan Cabiac

Reputation: 4993

The interface is there so methods can be defined to accept objects of type Serializable:

public void registerObject(Serializable obj);

Upvotes: 21

Related Questions