You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Gary Gregory <ga...@gmail.com> on 2018/02/24 15:53:23 UTC

Core 5 and Java 8

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

Re: Core 5 and Java 8

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2018-02-25 at 19:49 +0100, Michael Osipov wrote:
> 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.
> 

I am of the same opinion. We either take time to redesign the APIs with
Java8 capabilities in mind and delay GA as a result or Java 8 upgrade
gives us little. On the other hand, Java 8 has a major advantage of
allowing modification of interfaces without breaking binary
compatibility. This feature alone would be a huge benefit, but I
believe we can still introduce it in the 5.1 cycle.

Gary, the timing is a bit unfortunate. Still, if you feel strongly
about it we could run a poll on the user list and make a decision based
on its outcome.

Oleg 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Re: Core 5 and Java 8

Posted by Michael Osipov <mi...@apache.org>.
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 <ol...@apache.org> 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: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Re: Core 5 and Java 8

Posted by Gary Gregory <ga...@gmail.com>.
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.

Gary

On Sun, Feb 25, 2018, 04:40 Oleg Kalnichevski <ol...@apache.org> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

Re: Core 5 and Java 8

Posted by Oleg Kalnichevski <ol...@apache.org>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org