Re: Unnessecary use of new Integer(n) in AbstractJdbc2ResultSet

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