Inverted deprecation
-
I'm using a proprietary library that uses the Apache WSS4J. Since it didn't come with it, I had to download a new copy, so I downloaded the latest release. Go to run it the application, I get a NoSuchMethodException. Track it down to this:
Release 1.0
Element WSSecurityUtil.getSecurityHeader(Document, String, SOAPConstants) - deprecated
Element WSSecurityUtil.getSecurityHeader(WSSConfig, Document, String, SOAPConstants)
Release 1.1
Element WSSecurityUtil.getSecurityHeader(Document, String, SOAPConstants) - deprecated
Element WSSecurityUtil.getSecurityHeader(WSSConfig, Document, String, SOAPConstants)
Release 1.5 (there are no 1.2, 1.3, or 1.4)
Element WSSecurityUtil.getSecurityHeader(Document, String, SOAPConstants)
They removed the non-deprecated replacement method and standardized on the deprecated method. Of course, the library I'm using being written by good little coders avoided the method marked deprecated in order to avoid future problems when the deprecated method was remove. Too bad they removed the replacement instead.
-
Wait, SOAPConstants? Since when did Apache concern itself with Snakes on a Plane?
-
This occurred with Apache WSS4J and not the proprietary library? Geez, that's a pretty big WTF. This could affect a lot of people.
The real WTF though is that awful name. It's obvious that it expands to "Web Services Security for Java", but it looks terrible.
-
@Zemyla said:
Wait, SOAPConstants? Since when did Apache concern itself with Snakes on a Plane?
It's a recursive acronym.
SOAP On A Plane.
Slippery stuff.
-
Lol; reminds me of when (quite recently) our continuous builds started breaking after we upgraded from hibernate 3-something-beta to 3... they simply removed a method from the Persistable interface. It was introduced to the interface in 2.something; wasnt depricated, no announcement on the site that it might go away... just removed from the interface....
-
@Xenoveritas said:
They removed the non-deprecated replacement method and standardized on the deprecated method. Of course, the library I'm using being written by good little coders avoided the method marked deprecated in order to avoid future problems when the deprecated method was remove. Too bad they removed the replacement instead.
That's pretty bad. Did you file a bug report?
-
Wow, that's atrocious. Any OO developer knows you keep the
interface stable (unchanging) at all costs. How hard is it to
have the second method ignore the "WSSConfig" parameter and just call
the first method? Voilà, full backward compatibility.
But having dealt with another Apache Java project, Axis, I'm not especially surprised.
-
Yep, that's a pretty high quality WTF. It certainly made me go 'WTF?' :). Removing backwards compatibility at all is pretty dodgy (Java still has methods in it which were deprecated back in 1998), but removing the new replacement for a deprecated method is, well, a Real WTF.
-
The only rationalization I can think of is that passing WSSConfig in is no longer necessary in some way because the class has another way to get to it (such as it's static or global)?
So while it was deprecated in 1.0 and 1.1, in 1.5 something got completely rewritten.
-
@savar said:
@Xenoveritas said:
They removed the non-deprecated replacement method and standardized on the deprecated method. Of course, the library I'm using being written by good little coders avoided the method marked deprecated in order to avoid future problems when the deprecated method was remove. Too bad they removed the replacement instead.
That's pretty bad. Did you file a bug report?
That's the route I'd go. Sounds to me more like an unintentional flub on somebody's part at Apache. Or at least I would hope so...
-
@Xenoveritas said:
Release 1.0
Element WSSecurityUtil.getSecurityHeader(Document, String, SOAPConstants) - deprecated
Element WSSecurityUtil.getSecurityHeader(WSSConfig, Document, String, SOAPConstants)Release 1.5 (there are no 1.2, 1.3, or 1.4)
Element WSSecurityUtil.getSecurityHeader(Document, String, SOAPConstants)Well, you can probably guess what happened. Their development machine got wiped clean and repurposed when they needed a terminal server. The most recent backup they had was the source for version 0.7, which did not yet have the new method expecting the additional WSSConfig parameter.
Still, it's sort of amazing how a Release 1.0 can have deprecated methods in its interfaces...
-
@GeekMessage said:
Well, you can probably guess what happened. Their development machine got wiped clean and repurposed when they needed a terminal server. The most recent backup they had was the source for version 0.7, which did not yet have the new method expecting the additional WSSConfig parameter.
lol brillant! Too bad Paula's and Mark's work was lost because of that, too.
Still, it's sort of amazing how a Release 1.0 can have deprecated methods in its interfaces...
After carefull studying this website, I don't wonder.
-
@Benanov said:
The only rationalization I can think of is that passing WSSConfig in is no longer necessary in some way because the class has another way to get to it (such as it's static or global)?
So while it was deprecated in 1.0 and 1.1, in 1.5 something got completely rewritten.And that's somehow a reason to do that kind of stupidity? "Hey this method is deprecated and that one isn't, but you shouldn't take our word on it because we're going to keep the deprecated one and remove the one that isn't!
Seriously, why couldn't they just... I don't know, undeprecate the old "deprecated" and deprecate the new one if they needed to, if they really wanted what used to be deprecated to be the main access method?
-
@masklinn said:
Seriously, why couldn't they just... I don't know, undeprecate the old "deprecated" and deprecate the new one if they needed to, if they really wanted what used to be deprecated to be the main access method?
In Soviet Russia, Functions deprecate you!
-
@powerlord said:
@Bob Janova said:
(Java still has methods in it which were deprecated back in 1998)
I seem to recall James Gosling saying that deprecated methods will never be removed. Something about not forcing people to have to keep old runtimes around just to run old programs.
Unlike Microsoft's .NET.
Yes, because there's nothing as good as seventeen different versions of functions sitting in the API because someone somewhere might want to run some crazy applet written in the first 5 weeks of Java's initial release. Backwards compatibility is a plus to a certain point, and after that it very rapidly becomes a liability. This is part of why the Windows API is so horrible.
In the days of x00GB HDs, soon to be measured in TBs to store multiple versions of frameworks, and for extreme cases the free availability of virtual machines and emulators, the arguement for long term backwards compatibility is starting to look very weak.
After all, if Java is still around in 2050 (after all, those Cobol guys just KNEW their 2 year digits code would be long dead come Y2K) just imagine the benefits of having all of the 90s stuff around so your grandkids can show their grandkids some code they wrote in school!
2 version cycles or five years compatibility is a sensible maximum for 99% of purposes.
-
@RayS said:
Yes, because there's nothing as good as seventeen different versions of functions sitting in the API because someone somewhere might want to run some crazy applet written in the first 5 weeks of Java's initial release. Backwards compatibility is a plus to a certain point, and after that it very rapidly becomes a liability. This is part of why the Windows API is so horrible.
That's why your APIs should already be sane in version 0.1, remember my words should you ever design an API.
2 version cycles or five years compatibility is a sensible maximum for 99% of purposes.
5 years are definitely not enough. The larger a software system is, the longer it should live (because it was so expensive to build and it took so long...). If you deliberately limit backward compatibility, you limit the size of the applications that can reasonably be made on this plattform.
