https://bugs.documentfoundation.org/show_bug.cgi?id=89992
--- Comment #13 from Stephan Bergmann <sberg...@redhat.com> ---
(In reply to Alex Thurgood from comment #3)
> Open 3rd form in list of forms :
[...]
> java.lang.IncompatibleClassChangeError
[...]
With my --enable-dbgutil master build on Mac OS X 10.10.2 with JDK 1.8.0_25 I
can reproduce the "IncompatibleClassChangeError" etc. reporting on stderr (but
no crash).
The reason is connectivity/source/drivers/jdbc/JStatement.cxx
> sal_Int32 java_sql_Statement_Base::getResultSetType() throw(SQLException,
> RuntimeException)
> {
> static jmethodID mID(NULL);
> return impl_getProperty("getResultSetType",mID,m_nResultSetType);
> }
using a static jmethodID. If this function first gets called on a
java_sql_PreparedStatement derivation instance (where getMyClass() obtains the
java.sql.PreparedStatement interface deriving from java.sql.Statement) and then
on a java_sql_Statement derivation instance (where getMyClass() obtains the
java.sql.Statement interface), at least the given JDK version rejects the
java.sql.Statement.getResultSetType JNI call via the static stored
java.sql.PreparedStatement.getResultSetType jmethodID with a
java.lang.IncompatibleClassChangeError.
Removing the "static" from "static jmethodID mID(NULL);" would make that go
away. However, that would likely cause a performance regression, and lots of
other places in JStatement.cxx (and probably elsewhere) use the same broken
idiom, too. What is rather needed is to redesign the
connectivity/source/inc/java/lang/Object.hxx etc. code to properly cache
matching class/method pairs.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
