Subject | Deprecations in InterClient code |
---|---|
Author | Torsten Welches |
Post date | 2000-08-06T17:36:10Z |
Hello,
compiling the InterClient 1.6 or 2.0 sources causes a lot of
deprecations to show up, most of which are old Date/Time methods.
Apparently this use of deprecated methods is not an oversight of the
developers, rather than a result of an adaptable function
(SINGLE_INSTANCE_TIME) of the driver. You might want to read in the
class comment of interbase.interclient.Apaptor.java about it. The
idea is to share a single Date instance for multiple getDate/getTime
calls. InterClient uses the old, deprecated get/setDate, get/setMonth
(and so forth) methods - hence the deprecations. Today the only
supported means to change the value of a Date instance after the fact
is with setTime(long).
I doubt that this feature causes a dramatic improvement of memory
usage or performance, the modern JIT/Hotspot compiler actually are
doing too good a job nowadays <g>.
Well, maybe Inprise has some testcases for this feature so we could
check it out.
Furthermore you don't have this option for most of the other data
types (String, BigDecimal) since these are immutable. So why only for
Dates?
Besides the Date methods there are three deprecated String method
calls which could be substituted with the new ones. (oversights?)
What did I miss?
Torsten
compiling the InterClient 1.6 or 2.0 sources causes a lot of
deprecations to show up, most of which are old Date/Time methods.
Apparently this use of deprecated methods is not an oversight of the
developers, rather than a result of an adaptable function
(SINGLE_INSTANCE_TIME) of the driver. You might want to read in the
class comment of interbase.interclient.Apaptor.java about it. The
idea is to share a single Date instance for multiple getDate/getTime
calls. InterClient uses the old, deprecated get/setDate, get/setMonth
(and so forth) methods - hence the deprecations. Today the only
supported means to change the value of a Date instance after the fact
is with setTime(long).
I doubt that this feature causes a dramatic improvement of memory
usage or performance, the modern JIT/Hotspot compiler actually are
doing too good a job nowadays <g>.
Well, maybe Inprise has some testcases for this feature so we could
check it out.
Furthermore you don't have this option for most of the other data
types (String, BigDecimal) since these are immutable. So why only for
Dates?
Besides the Date methods there are three deprecated String method
calls which could be substituted with the new ones. (oversights?)
What did I miss?
Torsten