Overcome J2SE 1.3 ~ 1.4 incompatible issues - get help from reflection API and Ant

Summary If you want to implement one in Javaapi, it may be a more painful thing. You often need to implement many cross-dependent interfaces. The demand for new features contributes to upgraded existing JavaAPI, which has caused suppliers who provide these APIs to their related implementations to maintain relevant functions. As these API upgrade changes, the API code does not compatibility makes you maintain your newly old version of the code base. This directly leads to your maintenance costs and difficulty. This article demonstrates the technology to solve this problem, revealing how to compile different Javaapi version of the code only using a code base. A lot of APIs are now added to the Java standard library, such as JDBC. The benefits of doing this are that Java options are not necessarily bound to related deployment applications when deploying. These APIs are implemented by specialized professional development groups, and these APIs become more popular among actual use, the depth and breadth of use are also increasing. But sometimes upgrades to some API will make some classes and methods are not available. The development team would rather release these API packages as an optional component rather than as a Java standard support library. But once the API package in the standard library is joined, it is impossible to be an optional package if you sign a lifelong contract with the user. So as a user, you may suddenly discover your own code base turned into an incompatible 2 quarters, one is the use of the new API code, the other is the use of the old API code. You may think that the situation is not as bad as you think. I will give a simple example here. J2SE1.4 Due to the upgrade of some APIs in JDBC, JDBC cannot be compiled by 1.3 and 1.4 versions. You may encounter my dilemma: I may need to implement this interface, but my code needs to be compiled by 1.3 and 1.4. But I don't want to maintain 2 versions of the code library. So I start looking for a better solution. If you rely on Javac to compile your app, then unfortunately, Java is a famous written, running everywhere (WORA) does not include Woca (written, compile ^ _ ^;). But don't be too depressed, the encoded reflection skills and the compiled ANT skills are you can be cleared. I can only use a set of Java files and Ant tools to make a version simultaneously compiled below the 1.3 and 1.4 versions. Don't worry, let me first explain the description of the problem before I know the solution. Poor people's connecting pool (PS: Poor Man's Connection Pool, very interesting one sentence) Two years ago, my company needs a connection pool, but it is not willing to buy one. There was no free stuff at the time, so we wrote a connection pool. In order to better track the connection in the entire application, we wrote a com.icentris.sql.connectionWrapper class, which implements some of the Java.SQL.Connection interfaces and some of the other packages (achieved additional Java) . SQL interface). These packaging classes are just to track database usage in our application, and call real database resources through way. When J2SE1.4 is coming, we will naturally think of upgrading us to provide customers with a lot of performance of these applications. Of course, we also need to retain version 1.3, because some customers do not need to upgrade to 1.4 at all. Our bad discovery, if we don't modify, our ConnectionWrapper and other JDBC package classes are only compiled by J2SE 1.4. For the conciseness of the article, I demonstrate the technique that I use for all other classes that cannot pass J2SE 1.4 by using the CONNECTIONWrapper class.

If I follow the new API standard, then I have to add a few way to the connectionwrapper, then the next two big problems are in front: 1. Because my packaging class needs to be called, I will have to call it. A method that does not exist in the J2SE1.3 SQL class. 2. Because some new methods involve some new classes, I will have to face classes that do not exist in J2SE 1.3 in the compilation. Reflection provides aid some code to explain the first problem. But I ConnectionWrapper encapsulates java.sql.Connection, all of the examples I depends on the variables in the construction method realConnection: private java.sql.Connection realConnection = null; public ConnectionWrapper (java.sql.Connection connection) {realConnection = Connection;} In order to see how I solve the version is not compatible, let's take a closer look at StholdAbility (this new method in J2SE1.4 declared) Public void setholdability (int holdability) throws sqlexception {realconnection.setholdAbility Unfortunately, this method is obviously compiled in J2SE1.3, which has fallen into a 2 difficult situation. In order to solve this situation, I assume that setholdability will only be called under J2SE 1.4, so I use the reflex mechanism to call the method.

public void setHoldability (int holdability) throws SQLException {Class [] argTypes = new Class [] {Integer.TYPE}; Object [] args = new Object [] {new Integer (holdability)}; callJava14Method ( "setHoldability", realConnection, Argtypes, args;} public static object calljava14method (String methodname, object instance, class [] argtypes, object [] args) throws SQLEXCEPTION { try {Method method = instance.getClass () getMethod (methodName, argTypes);. return method.invoke (instance, args);} catch (NoSuchMethodException e) {e.printStackTrace (); throw new SQLException ( "Error Invoking method ( " MethodName "): " E);

} Catch (IllegalAccessException e) {e.printStackTrace (); throw new SQLException ( "Error Invoking method (" methodName "):" e);} catch (InvocationTargetException e) {e.printStackTrace (); throw new SQLException ("Error Invoking Method (" MethodName "):" E);}} Now I have a setHoldAbility () method, so you can successfully pass J2SE1.4 compilation. The principle is that I don't directly call J2SE1.3 java.sql.connection does not exist, but to turn into call by letting StholdAbility calls Calljava14Method this generic method, and then package all exceptions in a SQLException. This will reach my expectation. Now all new methods in J2SE1.4 are working very well, and can be successfully compiled under the old version of J2SE1.3 and work is normal. Now I will set up the second question. Just how to find a method in the application can use new classes that do not exist in J2SE 1.3. Ant is the answer in J2SE 1.4, Java.sql.Connection relies on a new class java.sql.savepoint. Because this class is in the java.sql package, you can't join it into J2SE 1.3. Java does not allow any third-party extension package to join its core package (java. *, Javax. *). So the challenge is coming, and this new Java.SQL.SAVEPOINT class is rotated under J2SE1.4, but the code can be compiled and can be run under J2SE1.3. Very simple, isn't it? All people who answer "Yes" will get a hazelnut chocolate cake (PS: haha, I am answering, but there is no: p). At least now I found the answer, making the problem very simple.

First of all, I inserted the following conditional IMPORT statement // comment_next_line_to_compile_with_java_1.3 Import Java.sql.savePoint; then I found a way to comment out of IMPORT below J2SE1.1. Very simple, use the following Ant statement on it: Comment_next_line_for_Java_1.3 Comment_next_line_for_Java_1.3 // Ant-replace this tag has several tab options There are many examples I have given in the future. The most important thing in this is to replace in . The meaning inside XML is a wrap. Under J2SE1.4, there is nothing happens, but one Import declaration below J2SE1.3 is commented. // Comment_next_line_to_compile_with_java_1.3 // Import java.sql.savepoint; however, SavePoint in the code is still using Public SavePoint SetsavePoint (String Name) throws Sqlexception {.. However, I only use these methods in J2SE 1.4, and you can compile in J2SE1.3. I found that as long as I have a my own SavePoint class in my package, my code can be compiled and don't need any import package. But I have to be not commented in this Import statement while I have been ignored.

So I created an empty com.icentris.sql.savePoint class, which (except Javadoc) is the shortest payment class: package com.icentris.sql; / ** Dummy class to allow connectionWRAPPER TO IMPLEMENT JAVA.SQL.CONNECTION * and still compile under J2SE 1.3 and J2SE 1.4. When compiled * under J2SE 1.3, this class compiles as a placeholder instead of the * missing java.sql.Savepoint (not in J2SE 1.3). When compiled * under J2SE 1.4, this class Is Ignored and ConnectionWrapper Uses The * java.sql.savepoint what new in j2se 1.4. * / public class savepoint {} in J2SE1 .4 I can correct the Import Java.sql.savePoint class in J2SE1.3, and annotate this IMPORT statement. So this SavePoint is replaced with an empty SavePoint class written in this package. So I can add any ways to the SavePoint class now, the same, the same reflection method just mentioned in these new methods.

// Comment_next_line_to_compile_with_Java_1.3 import java.sql.Savepoint;... Public Savepoint setSavepoint () throws SQLException {Class [] argTypes = new Class [0]; Object [] args = new Object [0]; return (Savepoint) callJava14Method ("SetsavePoint", RealConnection, Argtypes, Args; public Savepoint setSavepoint (String name) throws SQLException {Class [] argTypes = new Class [] {String.class}; Object [] args = new Object [] {name}; return (Savepoint) callJava14Method ( "setSavepoint", realConnection, Argtypes, Args;

} Public void rollback (Savepoint savepoint) throws SQLException {Class [] argTypes = new Class [] {Savepoint.class}; Object [] args = new Object [] {savepoint}; callJava14Method ( "rollback", realConnection, argTypes, args } PUBLIC VOID ReleaseSsavePoint (SavePoint Savepoint) THROWS SQLEXCEPTION {Class [] argtypes = new class [] {savepoint.class}; object [] args = new object [] {savepoint}; Calljava14Method ("ReleaseSavePoint", RealConnection, Argtypes, Args;} Now what I have to do is able to enable Ant to identify J2SE1.3, and then enable this Import statement to be commented.

< Include name = "SQL / ConnectionWrapper.java" /> Comment_next_line_for_java_1.3 Comment_next_line_for_java_1.3 // <

target description = "Let's undo Java 1.3 tweaks" name = "undoJava13Tweaks"> Comment_next_line_for_Java_1.3 // Comment_next_line_for_Java_1.3 Note that the compiler target before and after the call doJava13Tweaks are called undoJava13Tweaks. If in case Javac compile failure, we can restore the previous compiling version. You don't have to maintain 2 applications simultaneously for Java, the new approach to the new API upgrade and new classes / interfaces are not new. In general, the new method of joining and new classes will take into account the up-compatible problem to take care of the old API users. But when the upgrade API is in the Java core package, it will be troublesome. Because Java does not allow any external changes to these core packages or increased. Usually this will cause the need to maintain different version of the code tree for different versions of the API. However, as shown above, you can compile running under different versions of the API as long as you maintain a code tree. This reflected API allows you to call and do not exist, and Ant can adjust the corresponding IMPORT package by identifying different Java compiling versions. Although the above example is just a simple demonstration, in practice, these simple technologies have been utilized, and many of the J2SE 1.4 and J2SE1.3 version issues are used. I believe that through these technologies, you can do not have to worry about maintaining two code bases at the same time in frequent Java version. -------------------------------------------------- ------------------------------ About the author: Sam Mefford is iCentris's chief architect. The SAM MEFFORD is placed first for the compatibility of the system. The team he led is committed to providing an application publishing plan for a wide range of customer companies.

The application servers used by these deployments include Tomcat, WebLogic, Resin, Orion, and WebSphere; Oracle, PostgreSQL, MySQL, and Informix; and multiple Java running period environments in the database. Translator: Spikewang (9CBS ID: HK2000C) East China University Computer Department graduated, now Tongji University specializes in software engineering master's degree. Enterprise-level application development and research work dedicated to J2EE. About Copyright: Original article copyright belongs to the author Sam Mefford translation belongs to the translator and the original author common, welcome to the translator and the author. -------------------------------------------------- ------------------------------ Reference Resources: The API for Java.sql.connection (J2SE 1.3): http: // Java.sun.com/J2se/1.3/docs/api/java/sql/connection.html

The Api for Java.sql.connection (J2SE 1.4):

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/connection.html

The JDBC API:

http://java.sun.com/products/jdbc/

Java Core Reflection Reference Summary:

Http://java.sun.com/j2se/1.3/docs/guide/reflection/spec/java-reflectionToc.doc.html

THE REFLECTION API Guide:

http://java.sun.com/docs/books/tutorial/reflect/

The javadoc (java.lang.reflect):

Http://java.sun.com/J2se/1.3/docs/api/java/lang/reflect/package-summary.html