Vector, Hashtable: Why aren't they deprecated?
I've filed an RFE, because this is the only mention on bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6201870
and for whatever reason, it's been marked 'closed, not a bug' instead of 'RFE'.
So why aren't they deprecated?
I know a lot of swing stuff still refers to them, but that's just sun laziness, fixing that is trivial. A simple jackpot rule could do it with 100% accuracy, in fact.
(I'll post the RFE once it gets up on bugs.sun.com)
[497 byte] By [
reinierza] at [2007-11-26 21:37:02]
# 1
And deprecating these is a priority why? If you ask me, I have a million other things I'd like Sun to do first.
# 2
I agree with Sun's stated reasons.
ejpa at 2007-7-10 3:18:57 >
# 3
Let's see: 1.0.2 compatibility: That's no longer relevant at this point in time, I think:
You really have to choose; either go for 1.0.2 compatibility, which e.g. means you must not use "List", OR go with 1.0.2 compatibility, and avoid using tons and tons of classes people have come to rely on.
Thus we are left with a duplicate and no good reason to use them. If you don't eliminate duplicates from time to time the 'brain load' on learning a language just keeps growing for absolutely no good reason. This leads to perl obscurity, and that's bad.
# 4
> go for 1.0.2 compatibility, ..., OR go with 1.0.2 compatibility
Pardon? Was that supposed to make sense?
Let's see, you forgot about 1.1 compatibility.
Let's see, you also forgot about 1.2, 1.3, 1.4, 1.5, and 1.6 compatibility for all that existing code that still uses Vectors even though there are now alternatives.
Let's see, you also forgot that Vector isn't deprecated, so there are people out there writing brand new code for it now.
Let's see, you also forgot about binary compatibility forever having been a stated product goal eleven years ago.
Obviously you have never built a software product and had to cope with multiple versions being in the field at the same time, or ten-year-old versions being still in use at significant customers. Otherwise you wouldn't be so cavalier about backward compatibility.
ejpa at 2007-7-10 3:18:57 >
# 5
We're talking 'deprecated', not 'toss from the libraries'!I have absolutely no clue why you feel the need to insult me, so all I can see is:reread the title of this forum post, mate. You're way off.
# 6
> If you don't eliminate duplicates from time to time> the 'brain load' on learning a language> just keeps growing for absolutely no good reason.Those are your words and the conclusion I drew from them is reasonable.
ejpa at 2007-7-10 3:18:57 >
# 7
> reread the title of this forum post, mate.Ironically you posted a link to a page that answers your question.
# 8
What link? What answer?
'not a bug'? Well, yes. That's why it's an RFE.
'java 1.0/1.1' compatibility? No - that's not an answer: Making them deprecated does absolutely nothing interesting re: deprecation; Date is deprecated too - yet you can't use calendar if you're targetting java 1.0. If you must program for that kind of backwards compatibility, you either ignore the deprecation warnings, or, if you take your testing seriously, use an 1.0 version of the runtime libraries. Either way, you cannot do proper advised programming tactics, such as:
List list = new Vector(); //flexible; can be wrapped in Collections.unmodifiableList, or can switch to a LinkedList implementation!
because List is Collections API and doesn't go as far back as Vector.
Thus: While programming against 1.0 is a perfectly sound reason to not toss Vector entirely (something I've never suggested, regardless of ejp's insistence a forum post named 'Why aren't they deprecated' is really asking for them to be tossed entirely) - it has absolutely no part in being a good reason NOT to make them deprecated.
synchronized behaviour: The times where this is needed is exceedingly rare (where synchronized behaviour is at all relevant, just 'internally' synchronizing the list is rarely good enough; you'll have to manage the synchronization on your own. For example, ConcurrentModificationExceptions are the common problem with one list accessible by more than one thread, and synchronized behaviour does nothing to help you there. In the rare circumstances this is neccessary, there's Collections.synchronizedList().
"These classes are so popular that they can never be removed. Deprecation is futile.
Gentle denigration, on the other hand..." - I don't get this. Deprecation /IS/ gentle denigration. This line seems to suggest that deprecation == removal. Deprecation is specifically NOT removal. In fact, deprecation doesn't mean they ever will be removed. Just like Date is still around, and just like Thread.stop is still around, deprecation can simply mean: Unless you absolutely must, please use modern alternative. In the vast majority of @Deprecation showing up in the core libraries, this is exactly what it means.
I don't really see why I need to defend the Collections API in the collections forum. There's a reason why ArrayList was created!!
I'll try this again: Explain to me why Vector and Hashtable are not deprecated, whereas Date is. What's different?
What are the actual serious reasons for not deprecating something which HAS BEEN SUPERSEDED?
# 9
> What link? What answer?
Oh, sorry. I didn't realize that you're arguing on behalf of somebody else. I meant the original post. It had the link and the answer.
But obviously you have read it because you quote from it extensively. The original poster asked why aren't those classes deprecated. The link pointed to something that explained why. Now it appears you don't agree with that, but you don't seem to get it. That bug report is a representative of Sun explaining why they aren't deprecated. That's the answer to the question originally posted. You can rant as much as you like but that is the answer.
And I just checked the Java 6 API documentation. Date isn't deprecated.
But probably you were referring to the many constructors and methods of Date that are deprecated. What's the difference between them and Vector? Well, they were shoddy design. Vector isn't shoddy design, it's just old-fashioned.
# 10
Actually, sun incorrectly thought it was a bug report. it's not, it's an RFE. It needs to be filed as such so that it can gather votes.Vector is shoddy design as well; it was replaced with ArrayList for a reason.
# 11
It wasn't 'replaced' at all actually although it still appear to me that that is what you want to occur. It won't. Relax.
ejpa at 2007-7-10 3:18:57 >
# 12
How often do I have to re-iterate the title of this forum post before you grasp this?This is an attempt to set up an RFE for marking both java.util.Vector and java.util.Hashtable @Deprecated.Nothing more, nothing less.
# 13
Then I suggest you stop using words like 'eliminate' and 'replace'.I still agree with Sun's reasons.
ejpa at 2007-7-10 3:18:57 >
# 14
I wouldn't support deprecating Vector even though I never use it myself. I do use Swing classes that use Vector, and I wouldn't care to have all those deprecation notices littering my code for something I couldn't do anything about.
# 15
DrClap: Obviously, all places where SWING refers to Vector right now, will be replaced with "List".I thought that would be beyond obvious, but apparently it needs to be stated explicitly.OF COURSE all remaining mentions of Vector will be replaced.
# 16
It is now 'beyond obvious' that you aren't talking about what's in the subject line at all, contrary to 'nothing more, nothing less'. As I suspected all along from your use of words like 'eliminate' and 'replace'.
What you are actually proposing is a very large project for Sun to update all their Swing and other sources and replace Vector by List throughout the JDK API.
Which Sun certainly will not do. (i) They've already rejected the RFE; (ii) it would introduce API changes which are binary-incompatible and therefore out of scope; (iii) it would be source-incompatible with 1.0.2 and 1.1.
Sun cannot do this. So you may as well just forget the whole thing right now.
BTW the only genuine issue here seems to be that Sun's system puts 'closed, not a bug' for RFEs as well as bugs.
ejpa at 2007-7-21 18:21:50 >
# 17
What in heck's name are you talking about?
All sun needs to do is, for all places that take a Vector right now, search/replace that to List; Vectors ARE lists so all existing implementations don't break. Any vectors used by swing INTERNALLY can stay as they are; deprecation warnings aren't viral; a class that uses a deprecated codebase but doesn't expose any deprecated classes as parameters or return types will never cause deprecation warnings when used.
Hence this is the smallest of small projects for sun: Tag a @Deprecated on Vector and Hashtable, recompile all libraries, and rename to List anytime you get a deprecation warning on a parameter or return type. A jackpot rule can do this for you and you should be able to write one inside of 10 minutes.
As far as binary incompatibility: Swing didn't even exist in 1.0.2!!! What ARE you talking about? Sun changes this stuff all the time; JDBC4 has INTERFACES that have more methods, which is the One Rule you must never break.
You're using backwards compatibility as a lousy excuse.
# 18
Binary compatibility example for beginners:
Suppose there is a method DefaultTableModel.addRow(Vector) and I write code that calls that method and pass it a Vector. Then suppose that the writers of that code remove that method and replace it by DefaultTableModel.addRow(List). After that my compiled code won't run any more, all of a sudden it's throwing NoSuchMethodException. The writers broke binary compatibility.
Sure, I can fix that by recompiling my code under the new version of the API, but then it won't run under the old version. Professional API designers don't do things like that to their customers.
You have been throwing around phrases like "beyond obvious" when it's becoming obvious you don't understand the issues properly.
# 19
No; DrClap, I have merely made the error of assuming you and other sceptics have some basic problem solving skills.
Binary compatibility is solved by adding a redirect method:
public void whateverUsedToTakeAVector(Vector x) {
this.whateverUsedToTakeAVector((List)x);
}
this extra method would keep binary compatibility intact.
# 20
Okay. That wasn't the idea you posted in #17. Were you just being slapdash or did you not realize there was a problem then? In either case I am unimpressed at your skills too. Remember, I'm criticizing your idea. It's not my responsibility to pile workarounds on it to make it
# 21
There are interfaces in the JDK that define methods using Vector. Adding a new method to an interface breaks binary compatibility. Ditto abstract methods in abstract classes. It requires all implementations of the interface/abstract class to add an implementation of the new method.
Also there are base classes in the JDK that define protected data members of type Vector. Changing them would also introduce a binary incompatibility.
Really, this is beyond obvious. I'm curious as to how much research you've done into this issue.
And, for your edification and instruction, let me assure you that backward compatilbility is not a 'lousy excuse', it is an essential product attribute, as you would know if you had ever shipped any software products, and which Sun promised us in 1996 and so far have managed to deliver.
ejpa at 2007-7-21 18:21:50 >
# 22
> There are interfaces in the JDK that define methods
> using Vector. Adding a new method to an interface
> breaks binary compatibility. Ditto abstract methods
> in abstract classes. It requires all implementations
> of the interface/abstract class to add an
> implementation of the new method.
>
> Also there are base classes in the JDK that define
> protected data members of type Vector. Changing them
> would also introduce a binary incompatibility.
>
> Really, this is beyond obvious. I'm curious as to how
> much research you've done into this issue.
>
> And, for your edification and instruction, let me
> assure you that backward compatilbility is not a
> 'lousy excuse', it is an essential product attribute,
> as you would know if you had ever shipped any
> software products, and which Sun promised us in 1996
> and so far have managed to deliver.
seems to me the guy doesn't understand the problem, but is continually adjusting his argument with "you could simply do <xxxxx>"-type addendums, because he's managed to change his own code with little repercussion in the past. rather short-sighted really
