db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5840) Clean up compiler warnings introduced by using Java 5 language features
Date Sun, 22 Jul 2012 18:23:35 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-5840:
--------------------------------------

    Attachment: derby-5840-08-aa-jdbc3-embedded.diff

Attaching another patch (derby-5840-08-aa-jdbc3-embedded.diff) to compile the JDBC 3-specific
classes in the embedded driver with source and target level 1.5.

Source and target level was changed to 1.5 for the JDBC 3 targets in the java/engine sub-tree.

Since we don't produce a separate JDBC 2 driver anymore, the patch folds the JDBC 2 build
targets into the JDBC 3 build targets, so that the JDBC 2 classes are also compiled with level
1.5.

In addition to the usual updates to use generics where we get unchecked conversion warnings,
the patch fixes a deprecation warning that popped up in EmbeddedDriver.boot(). The warning
was about the use of DriverManager.getLogStream(), which is deprecated in favour of DriverManager.getLogWriter().
The patch makes it use getLogWriter(), and changes the signatures of the methods that receive
the log writer to expect a PrintWriter instead of a PrintStream. Some places where System.err
is passed to those methods, we now have to wrap System.err in a PrintWriter instance because
of this.

Changing the target level revealed that our build doesn't properly isolate the JSR-169 implementation
classes from the JDBC 3.0 implementation classes, something that manifested itself as failure
to boot the engine on J2ME platforms because it tried to load classes that were compiled with
a higher target level than the JVM understood. These things had to be fixed to get the engine
to load again on J2ME:

1) EmbedConnection30 and EmbedSavepoint30 are used by the JSR-169 implementation, but the
classes are compiled by the compile_jdbc3 target, because that target picks up every file
whose name matches *30.java. This was addressed by renaming EmbedSavepoint30 to EmbedSavepoint,
move all of EmbedConnection30's methods to the super-class (EmbedConnection), and remove the
EmbedConnection30 class. Since the class names no longer indicated that this was JDBC 3-specific
code (which it wasn't), it was correctly compiled for JSR-169.

2) The XactFactory class failed to load on J2ME because it had a field (xa_resource) whose
type was XAResourceManager. We don't support XA in our JSR-169 driver, so XAResourceManager
is compiled with target level 1.5, and this prevented the XactFactory class from loading.
The fix was to change the type of the field to Object. Using Object instead of XAResourceManager
is an existing strategy in XactFactory, as can be seen for example in this method declaration:

    public /* XAResourceManager */ Object getXAResourceManager()

(Note XAResourceManager is commented out.) I assume this was done for a similar reason, perhaps
back when JDBC 3 was compiled with target level 1.4, and we still supported Foundation Profile
1.0, which only supported level 1.3.

3) ResourceAdapter (another XA class) is loaded as an optional component, as seen in BasicDatabase.bootResourceAdapter():

		try
		{
			resourceAdapter = 
				Monitor.bootServiceModule(create, this,
										 org.apache.derby.iapi.reference.Module.ResourceAdapter,
										 allParams);
		}
		catch (StandardException mse)
		{
			// OK, resourceAdapter is an optional module
		}

However, even though it was prepared for failure to load the class, this code didn't see a
StandardException on J2ME after ResourceAdapter's target level changed to 1.5. Instead, it
saw a raw UnsupportedClassVersionError. The fix was to change ProtocolKey.create() to wrap
LinkageError (a super-class of UnsupportedClassVersionError) in a StandardException. That
method was already prepared for class loading to fail, but not because of wrong class version.
When the error came out as a StandardException, BasicDatabase.bootResourceAdapter() knew how
to handle it.

I ran suites.All on Oracle Java ME Embedded Client 1.1 to verify that the JSR-169 driver still
works. I also ran derbyall and suites.All on Java 5 and Java 7. All the tests passed.
                
> Clean up compiler warnings introduced by using Java 5 language features
> -----------------------------------------------------------------------
>
>                 Key: DERBY-5840
>                 URL: https://issues.apache.org/jira/browse/DERBY-5840
>             Project: Derby
>          Issue Type: Improvement
>          Components: Miscellaneous
>    Affects Versions: 10.10.0.0
>            Reporter: Rick Hillegas
>         Attachments: derby-5840-01-aa-compatibilityTests.diff, derby-5840-02-aa-compatibilityTests-again.diff.txt,
derby-5840-03-aa-drda.diff, derby-5840-03-ab-drda.diff, derby-5840-04-aa-client-level.diff,
derby-5840-05-aa-client-deprecation.diff, derby-5840-06-aa-jdbc3-stubs.diff, derby-5840-07-aa-drda-for-each.diff,
derby-5840-08-aa-jdbc3-embedded.diff
>
>
> Using Java 5 language features forces us to compile code at level 5 or higher. At this
level, the compiler raises warnings not seen at lower levels. This issue is a place to discuss
and attach cleanup to eliminate these warnings.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message