Subject | Re: [Firebird-Java] Java 7 |
---|---|
Author | Mark Rotteveel |
Post date | 2017-01-11T10:33:09Z |
On 11-1-2017 10:43, hugo.larson@... [Firebird-Java] wrote:
Java 8 can be used as a drop-in replacement of Java 7 in most cases
(although testing that first is still wise). Also consider that Java 7
has been End Of Public Updates since April 2015. This means that fixes
for security bugs in Java 7 are only available to people paying Oracle
for Premier, Extended, or Sustaining support.
My prediction is that project jigsaw (aka modules) will give a lot of
headaches when migrating to Java 9; and it might also make the JDK
release schedule slip even further.
At the moment it looks like I can support Java 8 and 9 from a single
codebase (although I might need to make some changes to really support
modules), because the new JDBC 4.3 interfaces/types introduced in Java 9
are not relevant for Jaybird and for the methods using those types we
can rely on the default implementation in the interfaces to throw an
SQLFeatureNotSupportedException.
I can't do that with Java 7 and 8 because of the java.time (JSR-310)
support and the introduction of some new types and methods in JDBC 4.2
that must be implemented.
That said, I haven't made a firm decision about dropping support for
Java 7 with Jaybird 3.1 yet. Dropping it could make my life easier, and
looking at the it time it took/takes for Jaybird 3, it might take quite
some time to get to Jaybird 3.1 anyway, especially considering I want to
implement support for FB3 wire encryption which is totally undocumented
except for the C++ code of Firebird itself.
However I will only really start evaluating dropping Java 7 or not after
Jaybird 3 is out of the door (hopefully before the end of this quarter),
and even then Jaybird 3 itself will be supported for the foreseeable
future with support for Java 7.
Please understand that my work on Jaybird is purely volunteer work: I
don't get paid to do this, and I pour a lot of my free time in Jaybird
and Firebird.
As the only active developer on Jaybird (bar the occasional
contributions/pull requests) I will have to make decisions that keep my
contribution to Jaybird sustainable. This sometimes means that I have to
drop certain features (eg dropping the (buggy) connection pool in 3.0)
or support for older Firebird or Java versions (dropping Java 5 in
2.2.8, Java 6 and Firebird 1.x with 3.0, and Firebird 2.0 and 2.1 and
maybe Java 7 with 3.1).
Mark
--
Mark Rotteveel
> I read that java 7 support might be dropped soon. Is there a practicalYou might want to consider upgrading to Java 8 anyway. In my experience,
> reason for this?
> We have hundreds of Firebird installations with JayBird on Java 7 and my
> plan is to upgrade them to Java 9 when it's stable but that is at least
> a year away.
Java 8 can be used as a drop-in replacement of Java 7 in most cases
(although testing that first is still wise). Also consider that Java 7
has been End Of Public Updates since April 2015. This means that fixes
for security bugs in Java 7 are only available to people paying Oracle
for Premier, Extended, or Sustaining support.
My prediction is that project jigsaw (aka modules) will give a lot of
headaches when migrating to Java 9; and it might also make the JDK
release schedule slip even further.
At the moment it looks like I can support Java 8 and 9 from a single
codebase (although I might need to make some changes to really support
modules), because the new JDBC 4.3 interfaces/types introduced in Java 9
are not relevant for Jaybird and for the methods using those types we
can rely on the default implementation in the interfaces to throw an
SQLFeatureNotSupportedException.
I can't do that with Java 7 and 8 because of the java.time (JSR-310)
support and the introduction of some new types and methods in JDBC 4.2
that must be implemented.
That said, I haven't made a firm decision about dropping support for
Java 7 with Jaybird 3.1 yet. Dropping it could make my life easier, and
looking at the it time it took/takes for Jaybird 3, it might take quite
some time to get to Jaybird 3.1 anyway, especially considering I want to
implement support for FB3 wire encryption which is totally undocumented
except for the C++ code of Firebird itself.
However I will only really start evaluating dropping Java 7 or not after
Jaybird 3 is out of the door (hopefully before the end of this quarter),
and even then Jaybird 3 itself will be supported for the foreseeable
future with support for Java 7.
Please understand that my work on Jaybird is purely volunteer work: I
don't get paid to do this, and I pour a lot of my free time in Jaybird
and Firebird.
As the only active developer on Jaybird (bar the occasional
contributions/pull requests) I will have to make decisions that keep my
contribution to Jaybird sustainable. This sometimes means that I have to
drop certain features (eg dropping the (buggy) connection pool in 3.0)
or support for older Firebird or Java versions (dropping Java 5 in
2.2.8, Java 6 and Firebird 1.x with 3.0, and Firebird 2.0 and 2.1 and
maybe Java 7 with 3.1).
Mark
--
Mark Rotteveel