Обсуждение: Re: Unnessecary use of new Integer(n) in AbstractJdbc2ResultSet
Kris Jurka wrote: > Integer.valueOf appeared in JDK 1.5 and we currently still support > JDK 1.4. There's been talk of ditching 1.4 support, but that hasn't > officially happened yet and isn't something we'd do for older > driver releases. Would it be practical to do it in the JDBC4 build? On a related note, are we using the -target switch to build for the lowest supported release (1.4 for JDBC3 and 1.6 for JDBC4)? If not, would that be practical? (I'm not very good at reading or writing ant....) -Kevin
On 4/24/2011 9:23 PM, Kevin Grittner wrote: > Kris Jurka wrote: > >> Integer.valueOf appeared in JDK 1.5 and we currently still support >> JDK 1.4. There's been talk of ditching 1.4 support, but that hasn't >> officially happened yet and isn't something we'd do for older >> driver releases. > > Would it be practical to do it in the JDBC4 build? In this case, yes, but not in general. findColumn is pretty localized, so duplicating it's code in an inherited class wouldn't be too bad. > On a related note, are we using the -target switch to build for the > lowest supported release (1.4 for JDBC3 and 1.6 for JDBC4)? If not, > would that be practical? No, the -target switch is really pretty useless for our purposes. We must build with the actual JDK we want to use. -target only affects the generated class files, but we need the correct API version to build against. Since we're implementing things like the Connection interface, the -target switch doesn't magically change the interface definition to the version in the original JDK. Kris Jurka
On 04/25/2011 12:50 AM, Kris Jurka wrote: > On 4/24/2011 9:23 PM, Kevin Grittner wrote: >> Kris Jurka wrote: >> >>> Integer.valueOf appeared in JDK 1.5 and we currently still support >>> JDK 1.4. There's been talk of ditching 1.4 support, but that hasn't >>> officially happened yet and isn't something we'd do for older >>> driver releases. >> >> Would it be practical to do it in the JDBC4 build? > > In this case, yes, but not in general. findColumn is pretty localized, so > duplicating it's code in an inherited class wouldn't be too bad. > >> On a related note, are we using the -target switch to build for the >> lowest supported release (1.4 for JDBC3 and 1.6 for JDBC4)? If not, >> would that be practical? > > No, the -target switch is really pretty useless for our purposes. We must > build with the actual JDK we want to use. -target only affects the generated > class files, but we need the correct API version to build against. Since we're > implementing things like the Connection interface, the -target switch doesn't > magically change the interface definition to the version in the original JDK. Yeah, you have to use -bootclasspath to get the right rt.jar if you use -target. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
Lew <noone@lewscanon.com> wrote: > On 04/25/2011 12:50 AM, Kris Jurka wrote: >> On 4/24/2011 9:23 PM, Kevin Grittner wrote: >>> On a related note, are we using the -target switch to build for >>> the lowest supported release (1.4 for JDBC3 and 1.6 for JDBC4)? >>> If not, would that be practical? >> >> No, the -target switch is really pretty useless for our purposes. >> We must build with the actual JDK we want to use. -target only >> affects the generated class files Right, it specifies the earliest JVM version on which the class files can be run based on the bytecode level. This is separate from but related to the library against which it is compiled -- pointing to an earlier library ensures that a class or method from a later version won't be referenced. The jar files available for download use an earlier bytecode version than needed, which limits performance unnecessarily. We can't actually run on those earlier versions because of the classes and methods reference. I just downloaded the "postgresql-9.1dev-900" jars, and I find that the -jdbc3 jar has a bytecode version compatible with a JDK 1.0 and 1.1 JVMs, even though we reference classes and methods which aren't available until later JVMs. The -jdbc4 jar is compiled for a JDK 1.4 JVM, even though it references classes and methods not included until 1.6. Now, this doesn't hurt functionality, since a later 1.X JVM is guaranteed to run earlier 1.X bytecode, but optimizations added in later JVMs can't be compiled in, so the bytecode will run slower. > Yeah, you have to use -bootclasspath to get the right rt.jar if > you use -target. I guess I didn't make my point very clearly. I don't want to compile with an *earlier* target. The *default* is to compile with the earlier bytecode target. It won't actually *run* on the earlier JVMs because we're using the later API, so we're just hurting performance by *not* forcing the '-target 1.4' for -jdbc3 and '-target 1.6' for -jdbc4. If you don't believe me, look at this page for the bytecode level values stored in offsets 4 to 7 of a class file: http://stackoverflow.com/questions/1293308/java-api-to-find-out-the-jdk-version-a-class-file-is-compiled-for and unzip the jar files to see how that's set. -Kevin
Kevin Grittner wrote: > Lew wrote: >> Yeah, you have to use -bootclasspath to get the right rt.jar if >> you use -target. > > I guess I didn't make my point very clearly. I don't want to > compile with an *earlier* target. The *default* is to compile with > the earlier bytecode target. It won't actually *run* on the earlier > JVMs because we're using the later API, so we're just hurting > performance by *not* forcing the '-target 1.4' for -jdbc3 and > '-target 1.6' for -jdbc4. > > If you don't believe me, look at this page for the bytecode level Oh, I believe you! -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > I just downloaded the "postgresql-9.1dev-900" jars, and I find > that the -jdbc3 jar has a bytecode version compatible with a JDK > 1.0 and 1.1 JVMs, even though we reference classes and methods > which aren't available until later JVMs. I just double-checked, and found that I'd messed up my initial check on that. The right target level is used for each. Sorry for the noise. -Kevin