2

There are many criticisms against the stale java.util.Stack class such as this one, saying that it should be avoided because it's less safe and less fast. I can understand keeping it in rt.jar for compatibility reasons (even we're going to keep it forever), but why isn't it marked as deprecated?

People are getting deceived by the class' name and use it everywhere. It's better if they can see a warning at compile time that the class they use is stale.

ice1000
  • 6,406
  • 4
  • 39
  • 85
  • Actually marking it for deprecation is only for when they want to actually _remove_ it later. That happens very rarely, see e.g. java.util.Vector – Thorbjørn Ravn Andersen May 17 '20 at 19:12
  • 2
    It’s a good question, but guesswork, so maybe not well suited for Stack Overflow. Modern versions of the compiler elide most unnecessary locks, so Jon Skeet’s objections linked to are unimportant in 2020. – Ole V.V. May 17 '20 at 19:13
  • Probably question you can ask at core-libs-dev@openjdk.java.net – Vipin May 17 '20 at 19:14
  • 1
    I think you’re wrong, @ThorbjørnRavnAndersen. Methods were deprecated in Java 1.1 (more than 23 years ago), but I am not aware of any part of the public API having been removed *ever*. Recently they started additionally marking some deprecated items “for removal”. So conversely, marking `Stack` deprecated *without* the “for removal” mark wouldn’t hurt as far as I can see. Am I missing something? – Ole V.V. May 17 '20 at 19:15
  • 2
    Don't forget `Hashtable`. If we're going to deprecate / remove pre-collections api(s), let's remove all of them! – Elliott Frisch May 17 '20 at 19:16
  • @OleV.V. I was referring to Vector as one that could have been removed in this way a long time ago, but hasn't. It was my understanding that _some_ classes have been removed after Java 8, but apparently not (but a few methods have been to allow modularization). I may have confused it with the removal of the javax.*-modules from the SE distribuiton. – Thorbjørn Ravn Andersen May 17 '20 at 19:25
  • 1
    I have never understand why Stack class is a Sequential List and not a Linked List. – sgtcortez Sep 23 '20 at 18:28

1 Answers1

3

The Javadoc class documentation for java.util.Stack as per Java SE 14 does come with this guidance:

A more complete and consistent set of LIFO stack operations is provided by the Deque interface and its implementations, which should be used in preference to this class. For example:

  Deque<Integer> stack = new ArrayDeque<Integer>();
MelvinWM
  • 749
  • 4
  • 13
  • Does this give a compile-time warning? – ice1000 May 17 '20 at 19:20
  • @ice1000 Good point, it does not. I imagine that having it deprecated for legacy code that uses it, despite still (as far as I know) working correctly, would be bothersome for the owners of that code base. But for new code, a compile-time warning would indeed be useful. That said, the Javadoc documentation does point developers in the right direction. – MelvinWM May 17 '20 at 19:27
  • This documentation started coming from Java 6 I believe. – Kishore Bandi May 17 '20 at 19:33
  • @ice1000 As to further explain, `Stack` should definitely not be used for new code, but should still work as is in legacy code bases. In contrast, a method like [Object::finalize](https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/Object.html#finalize()) should as far as I know never be used, including in legacy code bases, and it is a priority to remove it, also in legacy code bases. I have not brushed up on the specific guidance reg. the usage of the `@Deprecated` annotation, but I could imagine that this has something to do with it. – MelvinWM May 17 '20 at 20:11
  • 1
    @ice1000 That said, a more aggressive deprecation policy could possibly make sense, for instance one that would include deprecation of `java.util.Stack`. But it is not without its drawbacks. One of the advantages and drawbacks of Java is that it maintains a lot of backwards compatibility in various ways; this tends to result in moving more slowly and cruft accumulating for the language among other aspects, but it also means that developers spend considerably less time updating and refactoring code bases that worked previously but broke due to a new version of the given language coming out. – MelvinWM May 17 '20 at 20:20
  • @ice1000 An example of a language version increase that caused a lot of pain and difficulty in various ways was Python 2 to 3. You can see many stories about that on the net. Some language developers try to achieve both high rate of change of the language while also decreasing the pain and cost of updating code bases. One approach to handling this is migration tools; Python 2 to 3 did not have good migration tools initially as far as I know. For Scala 2 to 3, they hope to decrease the migration cost, see for instance https://github.com/scalacenter/scala-3-migration-guide . – MelvinWM May 17 '20 at 20:28