Am 2018-02-25 um 17:38 schrieb Gary Gregory:
My selfish POV is Java 8 and a longer beta cycle. I am not able to migrate
to HC 5 ATM for my proxy product due to the usual busy. So I'd like HC 5 to
be as modern as possible by the time I get to it.
This is actually a personal problem, not one of the project.
I tend to be conservative in what I do, because people do write stuff
which runs 5 to 10 years to due high investments. I do know a huge piece
of software my company produces still using Commons HTTP Client 3.x and
Eclipse 3.6, sigh.
Looking at this [1], I don't expect enterprise people to change really
soon. Given that Oracle will support even after 2020 in non-public
releases (paid) and Java 11 (LTS) won't be available be available before
2018-09, I don't see a compat chance before end of this year.
Unless you are willing to rewrite everything to use neat Java 8
features, I so no real benefit but the class version bump.
Michael
[1] http://www.oracle.com/technetwork/java/eol-135779.html
On Sun, Feb 25, 2018, 04:40 Oleg Kalnichevski <[email protected]> wrote:
On Sat, 2018-02-24 at 08:53 -0700, Gary Gregory wrote:
Hi All:
We started to talk about Java 8 a while back and I am now wondering
what we
should do.
I see the neat stuff we did with creating abstractions with the new
TimeValue and Timeout classes.
With Java 8, I imagine that the TimeValue class would be replaced by
Java
8's Duration.
I still like having a Timeout class, but then it would become a
wrapped for
a Duration. So maybe we'd also have an AbstractDurationWrapper with a
Timeout subclass.
If we switch to Java 8 after Core 5.0, then we will have something
that
looks awkward.
Thoughts?
Gary
As much as I would love to use Java 8 features in HC we should have
migrated to Java 8 before going BETA. If we really want to take full
advantage of Java 8 large chunks of HC APIs would need to be revised
and modified, not just TimeValue.
I cannot say what is more important, convenience of Java 8 or going GA
sooner. I am willing to go with the majority on this matter.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
