Re: Oracle query seems to return every row twice in ResultSet
According to Lew <lew@lewscanon.com>:
<http://issues.apache.org/jira/browse/LANG-76>
Thomas Pornin wrote:
Well, there _are_ explanations. If I get it correctly, the bug is
related to using their EnumUtils class, using as parameter a Class
instance for a class which has not been initialized yet. They feel
that it is the responsability of the caller to ensure that the
provided Class instance has been initialized.
I assess that it is the responsibility of a library writer not to rely on a
bug to make their library work. Blaming the user for failing to work around a
bug in the library is just evil.
There is application code which relies on a JVM bug (namely a violation
of the JLS by JDK 1.4 and previous) for proper operation with EnumUtils,
but it is hardly the fault of EnumUtils or the source code in
common-langs. They _could_ embed a workaround (forcing initialization
Of course it is their fault. They intentionally relied on behavior that
violated the Java spec to make their library work. What did they *think*
would happen when the bug was fixed, hm?
from within EnumUtils) just to tolerate nominally invalid code, but they
do not, mostly because the workaround is expensive (it involves
reflection, and must be performed at each call) and the EnumUtils method
are supposed to be highly efficient.
So that excuses relying on a bug to make the library work?
I am incredulous that you would support such a ridiculous practice.
One could point out that the lack of an efficient class initialization
method (that is, a method which is inexpensive when the class turns
out to have already been initialized) is a deficiency of Java and
should be corrected. Actually, one did point out:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4993813
It is a RFE since early 2004. The irksome part is that the JVM must have
such a method somewhere (I know mine has), it is only a matter of making
it public.
That has nothing to do with commons-lang intentionally using a bug to support
its Enum functionality.
Besides, since JDK 1.4 and previous have the abovementioned violation
(simply using X.class causes initialization of class X), and JDK 5 and
newer have a built-in, better integrated enum facilities, then the point
becomes mooter and mooter.
So does that mean it's all right to code to a bug just because it happens to
be there? What about non-Sun implementations of Java? Can we count on all
implementations not to follow the specification?
And just because Java 5 has 'enum' doesn't mean that a good library of
type-safe enumerations wouldn't be useful. For example, there's a lot of code
that has to serialize and deserialize to pre-Java 5 applications still, and
that code can't really use Java enums yet. Furthermore, some of the
complaints people have about Java enums are best handled by using another,
non-built-in enumeration type such as the commons-lang Enum, were it not for
the bug.
I am shocked and amazed that anyone would think that intentionally using a bug
to make one's code work is a good practice or in any way defensible.
--
Lew