This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When compiling the IDE with Mustang b40 I came across org.netbeans.lib.ddl.adaptors.DefaultAdaptor which cannot be compiled because there are new abstract methods which must be implemented: public RowIdLifetime getRowIdLifetime() throws SQLException public ResultSet getSchemas(String catalog, String schemaPattern) throws SQLException public boolean supportsStoredFunctionsUsingCallSyntax() throws SQLException public boolean autoCommitFailureClosesAllResultSets() throws SQLException public ResultSet getClientInfoProperties() throws SQLException public boolean providesQueryObjectGenerator() throws SQLException public boolean isWrapperFor(java.lang.Class<?> interfaces) throws java.sql.SQLException public java.lang.Object unwrap(java.lang.Class<?> interfaces) throws java.sql.SQLException
Would be easy to fix by implementing the new methods if it wasn't for the public RowIdLifetime getRowIdLifetime() throws SQLException method, which returns an enumeration new in JDBC 4.0 (Mustang). This could be perhaps fixed by adding to the compilation classpath on other JDKs than 1.6 a jar containing a fake RowIdLifetime.
Suggest just using java.lang.reflect.Proxy and implement the methods you actually care about. Looks like a lot of them don't do much besides get/set some key in a map anyway.
Jesse, thank you for the comment. Could you please elaborate a bit? I don't understand how could using j.l.r.Proxy help here. My biggest problem now is that I can't add an implementation of the getRowIdLifetime() method to DefaultAdaptor, because it returns a RowIdLifetime (an enumeration which was introduced in 1.6). This wouldn't build on pre-1.6 JDKs. Of course, another problem is that my implementation of methods introduced in 1.6 (other that getRowIdLifetime()) should delegate to the DatabaseMetaData returned by the JDBC driver (the "dmd" field in DatabaseAdaptor), but it doesn't, since this would again cause the code to stop building on pre-1.6. This is not a big issue, since DatabaseAdaptor is not used now and I plan to remove it in promo G. But I'd be glad if you could comment on this as well, since I don't see how Proxy could help here either. I can't pass the clients of DatabaseAdaptor a proxy instance of DatabaseMetaDataAdaptor instead of a DatabaseAdaptor, since the clients need to reference DatabaseAdaptor itself (it adds some methods to DatabaseMetaDataAdaptor, e.g., getCatalogsQuery()).
Take all the methods specific to DefaultAdaptor and separate them into a new interface, which you can make the generated proxy object implement however you like. The advantage of using Proxy is that you can use a fixed pattern to implement whatever JDBC methods there are which you would want to behave in a routine fashion, without directly referring to newly added types. In the case of RowIdMetadata, you can call the same method on the original dmd, and you could load/store enum-typed settings generically in 'properties' by loading/storing their string representations. From a casual inspection, it looks like most of DefaultAdaptor.java today is copied-and-pasted code that could be condensed to a few generic cases using Proxy.
Any progress on this? Prevents people from running NB builds inside the IDE when using Mustang.
The last time I looked at it was a few weeks before high resistance and it seemed too risky for 5.0. I will look at it again after the Christmas vacation.
*** Issue 70590 has been marked as a duplicate of this issue. ***
Downgrading back to P3, since not for 5.0.
BTW not an issue even when running in-IDE builds *if* you set nbjdk.home=.../jdk1.4 in nbbuild/user.build.properties.
*** Issue 73160 has been marked as a duplicate of this issue. ***
Still no time for this. There is a patch in issue 73160 which makes DefaultAdapter compile on JDK 1.6, but it can't be commited since it doesn't compile on 1.5.
*** Issue 83540 has been marked as a duplicate of this issue. ***
See also the proposed workaround and patch in issue 83540. There will be no time to fix this for 5.5 in another way than the one in issue 83540 or the one proposed in desc2. I slightly prefer the latter because it allows compiling DefaultAdaptor.java against user's JDK.
Either a fake RowIdLifetime or usage of Proxy would work. Don't much like having a precompiled DA.class. Tim - I already informed the JDK team about this incompatibility. They said that they would not fix it - they do not expect anyone to be implementing this interface outside of the JDK. Or something like that. At any rate, they were unwilling to make the change compatible for implementers of the interface.
I just realized DefaultAdaptor does more than just cache the return values of DatabaseMetaData methods. It also allows for the retrieval of the database structure by executing user-defined queries instead of delegating to the driver's DMD. Moreover, the values of some DMD methods (definitely those returning ResultSet's) should not be cached, as that would prevent them from being garbage-collected. Replacing all this with a Proxy would be possiblek, but I'm not sure it would be worth the effort. This issue ought to be fixed for 5.5, so there is no time for doing anything else than the fake RowIdLifetime anyway.
Fixed in release55_dev. http://www.netbeans.org/source/browse/db/external/Attic/fake-jdbc40.jar?r1=1.1&r2=1.1.2.1 http://www.netbeans.org/source/browse/db/libsrc/org/netbeans/lib/ddl/adaptors/DefaultAdaptor.java?r1=1.19.46.1.2.1&r2=1.19.46.1.2.1.14.1 http://www.netbeans.org/source/browse/db/nbproject/project.properties?r1=1.8.2.3.2.7&r2=1.8.2.3.2.7.10.1 fake-jdbc40.jar contains an empty public class named java.sql.RowIdLifetime.
Jesse or Tim, I would like to ask you for a review.
Looks fine to me. Is this really FIXED in dev though? Normally you fix in dev *first*, then ask for review of a merge to 5.5.
I would slightly (P3) prefer to generate the content of the fake-*.jar by the build script itself. E.g. do: <echo file="RowIdLifetime.java">package .....</echo> <javac .../> and then just refer to the compiled fake RowIdLifetime. All of this could be conditional just on Java5. Example of this used to be in Form module which used to generate classes in similar way.
Verifiend in release55_dev branch with jdk1.6.0-b99.
jtulach: you are right, that would be a nicer solution. But unless it is a blocker I would prefer to leave it as it is and file a P2 TASK to improve it. The improvement would only affect the trunk; release55 would still have the fake JAR, I hope that is not a big problem.
Filed issue 85352 to track the proposal in desc20.
Fixed in release55. http://www.netbeans.org/source/browse/db/external/Attic/fake-jdbc40.jar?r1=1.1&r2=1.1.4.1 http://www.netbeans.org/source/browse/db/libsrc/org/netbeans/lib/ddl/adaptors/DefaultAdaptor.java?r1=1.19.46.1.2.1&r2=1.19.46.1.2.2 http://www.netbeans.org/source/browse/db/nbproject/project.properties?r1=1.8.2.3.2.7&r2=1.8.2.3.2.8
verified in release55