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

Question

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)

Usually this is being done to make existing code backward compatible. So you can easily upgrade but migrate step by step to the new annotations. — Benjamin Muschko, Jun 17 '11 at 20:44
@Atreys: The one that contains the *It is possible that future versions of the Java programming language will disallow the use of raw types* remark — ElenaT, Jun 17 '11 at 20:46
@Atreys: No problem. I've edited the link to limit the section to the one with the quoted text. Thanks! — ElenaT, Jun 17 '11 at 20:59
we are in an annotation bubble, people want to annotate everything and their dogs. — irreputable, Jun 18 '11 at 01:14

score 21 · Accepted Answer · answered Jun 17 '11 at 20:44

21

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

public void registerObject(Serializable obj);

answered Jun 17 '11 at 20:44

Ethan Cabiac

4,943
20
36

Yes! I Perfectly agree with you. But wouldn't this be possible with something like: **public void registerObject(@Serializable Object obj)**? – ElenaT Jun 17 '11 at 20:49
Would you really want to do that ElenaT? – John Vint Jun 17 '11 at 20:50
@John well... why not? What would Ethan's original line make better than Elena's? – Jesper Jun 17 '11 at 20:56
1

@John V.: Why not? It is metadata. The Serializable interface is just a marker anyways, it's not like it exposes some method through the interface. – ElenaT Jun 17 '11 at 20:58
8

Unless I'm wrong Java currently does not let you require a certain annotation for an argument: you require a type, and you apply an annotation, but you can't say **only accept arguments with this annotation**. So I don't believe you can do `public void registerObject(@Serializable Object obj)` (which says `obj` should be annotated as Serializable, as opposed to `obj` IS serializable) and have it work the same way as `public void registerObject(Serializable obj)`. – Femi Jun 17 '11 at 21:16
@Femi: It won't work the same way. But it could be handled as "warning" just as "Nullable" or "Deprecated". Serialization process in the current version is not really covered by the compiler as well. One can for example create a Serializable class with non-Serializable methods. The idea with annotations instead of the interface is not that bad. – 30thh Jul 27 '12 at 15:05

Stephen C · Answer 2 · 2011-06-18T00:50:53.770

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.

`Thread.stop(Throwable)` was effectively removed (always throws `UnsupportedOperationException`) in Java 8. `Serializable` is still unlikely to go anywhere, of course. — Jeffrey Bosboom, Feb 17 '17 at 02:42

score 2 · Answer 3 · answered Jun 17 '11 at 20:54

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).

score -1 · Answer 4 · answered Sep 28 '16 at 13:58

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.

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

4 Answers4