Oracle Java release model changes and consequences for the project

[Michael Brohl-3]

Hi devs,

this is just an initial information and dicussion starter to make
everyone aware of this:

the Oracle Java release model is changing from a feature based to a time
based model [1]. One major drawback is that there will be no more public
patch releases for older versions once a new release is published, if I
understand correctly.

We'll have to discuss if this affects the project in terms of support
for the latest public Java releases. If we want to stay up-to-date
according to the public releases, we'll have to establish a process to
early check the new features and changes of a coming release and maybe
release more often.

We might even have to support the latest Java release along with the
current LTS release to cover both users with and without commercial
support? I'm not sure.

What do you think?

Best regards,

Michael

[1] https://www.azul.com/java-stable-secure-free-choose-two-three/

[Jacopo Cappellato-5]

Thank you Michael for starting this thread.
When discussing this, we will also have to consider that OFBiz currently
depends on several other Open Source products that will have to be
compatible with the platform we will choose (however, considering that
backward compatibility is maintained in new Java releases this is not going
to be a major concern).

Jacopo



On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl <[hidden email]>
wrote:

> Hi devs,
>
> this is just an initial information and dicussion starter to make everyone
> aware of this:
>
> the Oracle Java release model is changing from a feature based to a time
> based model [1]. One major drawback is that there will be no more public
> patch releases for older versions once a new release is published, if I
> understand correctly.
>
> We'll have to discuss if this affects the project in terms of support for
> the latest public Java releases. If we want to stay up-to-date according to
> the public releases, we'll have to establish a process to early check the
> new features and changes of a coming release and maybe release more often.
>
> We might even have to support the latest Java release along with the
> current LTS release to cover both users with and without commercial
> support? I'm not sure.
>
> What do you think?
>
> Best regards,
>
> Michael
>
> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>
>
>
>

[Jacques Le Roux]

Hi,

I was wondering about that too when I read this thread on Tweeter

https://twitter.com/holgerbrands/status/957572736129339392

But it seems OK finally

Jacques


Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :

> Thank you Michael for starting this thread.
> When discussing this, we will also have to consider that OFBiz currently
> depends on several other Open Source products that will have to be
> compatible with the platform we will choose (however, considering that
> backward compatibility is maintained in new Java releases this is not going
> to be a major concern).
>
> Jacopo
>
>
>
> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl <[hidden email]>
> wrote:
>
>> Hi devs,
>>
>> this is just an initial information and dicussion starter to make everyone
>> aware of this:
>>
>> the Oracle Java release model is changing from a feature based to a time
>> based model [1]. One major drawback is that there will be no more public
>> patch releases for older versions once a new release is published, if I
>> understand correctly.
>>
>> We'll have to discuss if this affects the project in terms of support for
>> the latest public Java releases. If we want to stay up-to-date according to
>> the public releases, we'll have to establish a process to early check the
>> new features and changes of a coming release and maybe release more often.
>>
>> We might even have to support the latest Java release along with the
>> current LTS release to cover both users with and without commercial
>> support? I'm not sure.
>>
>> What do you think?
>>
>> Best regards,
>>
>> Michael
>>
>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>
>>
>>
>>

[taher]

If I understood the documentation correctly, we have to choose between
two different packages:
- Stable release (long term support, less features)
- Feature release (short term support, more features)

Of the two, I think the stable LTS seems to be more compatible with
our own release cycle. Also we don't usually go crazy with feature
adoption and we prefer to take things slow.

So we can perhaps stick with JDK 8 for as long as we need and maybe
then jump to 11 when we are ready.

On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
<[hidden email]> wrote:

> Hi,
>
> I was wondering about that too when I read this thread on Tweeter
>
> https://twitter.com/holgerbrands/status/957572736129339392
>
> But it seems OK finally
>
> Jacques
>
>
>
> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>
>> Thank you Michael for starting this thread.
>> When discussing this, we will also have to consider that OFBiz currently
>> depends on several other Open Source products that will have to be
>> compatible with the platform we will choose (however, considering that
>> backward compatibility is maintained in new Java releases this is not
>> going
>> to be a major concern).
>>
>> Jacopo
>>
>>
>>
>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl <[hidden email]>
>> wrote:
>>
>>> Hi devs,
>>>
>>> this is just an initial information and dicussion starter to make
>>> everyone
>>> aware of this:
>>>
>>> the Oracle Java release model is changing from a feature based to a time
>>> based model [1]. One major drawback is that there will be no more public
>>> patch releases for older versions once a new release is published, if I
>>> understand correctly.
>>>
>>> We'll have to discuss if this affects the project in terms of support for
>>> the latest public Java releases. If we want to stay up-to-date according
>>> to
>>> the public releases, we'll have to establish a process to early check the
>>> new features and changes of a coming release and maybe release more
>>> often.
>>>
>>> We might even have to support the latest Java release along with the
>>> current LTS release to cover both users with and without commercial
>>> support? I'm not sure.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>>
>>> Michael
>>>
>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>
>>>
>>>
>>>
>

[Jacques Le Roux]

That sounds wise to me, maybe we can try Java 9 though, to not get too much things to do later?

Jacques


Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :

> If I understood the documentation correctly, we have to choose between
> two different packages:
> - Stable release (long term support, less features)
> - Feature release (short term support, more features)
>
> Of the two, I think the stable LTS seems to be more compatible with
> our own release cycle. Also we don't usually go crazy with feature
> adoption and we prefer to take things slow.
>
> So we can perhaps stick with JDK 8 for as long as we need and maybe
> then jump to 11 when we are ready.
>
> On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
> <[hidden email]> wrote:
>> Hi,
>>
>> I was wondering about that too when I read this thread on Tweeter
>>
>> https://twitter.com/holgerbrands/status/957572736129339392
>>
>> But it seems OK finally
>>
>> Jacques
>>
>>
>>
>> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>> Thank you Michael for starting this thread.
>>> When discussing this, we will also have to consider that OFBiz currently
>>> depends on several other Open Source products that will have to be
>>> compatible with the platform we will choose (however, considering that
>>> backward compatibility is maintained in new Java releases this is not
>>> going
>>> to be a major concern).
>>>
>>> Jacopo
>>>
>>>
>>>
>>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl <[hidden email]>
>>> wrote:
>>>
>>>> Hi devs,
>>>>
>>>> this is just an initial information and dicussion starter to make
>>>> everyone
>>>> aware of this:
>>>>
>>>> the Oracle Java release model is changing from a feature based to a time
>>>> based model [1]. One major drawback is that there will be no more public
>>>> patch releases for older versions once a new release is published, if I
>>>> understand correctly.
>>>>
>>>> We'll have to discuss if this affects the project in terms of support for
>>>> the latest public Java releases. If we want to stay up-to-date according
>>>> to
>>>> the public releases, we'll have to establish a process to early check the
>>>> new features and changes of a coming release and maybe release more
>>>> often.
>>>>
>>>> We might even have to support the latest Java release along with the
>>>> current LTS release to cover both users with and without commercial
>>>> support? I'm not sure.
>>>>
>>>> What do you think?
>>>>
>>>> Best regards,
>>>>
>>>> Michael
>>>>
>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>
>>>>
>>>>
>>>>

[taher]

Sure but If we choose to go with 9, then we _must_ keep jumping every
6 months or so. You either stick with an LTS or you don't, and as per
my understanding 9 and 10 are not LTS. Read the article for more
information.

On Tue, Jan 30, 2018 at 8:01 PM, Jacques Le Roux
<[hidden email]> wrote:

> That sounds wise to me, maybe we can try Java 9 though, to not get too much
> things to do later?
>
> Jacques
>
>
>
> Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :
>>
>> If I understood the documentation correctly, we have to choose between
>> two different packages:
>> - Stable release (long term support, less features)
>> - Feature release (short term support, more features)
>>
>> Of the two, I think the stable LTS seems to be more compatible with
>> our own release cycle. Also we don't usually go crazy with feature
>> adoption and we prefer to take things slow.
>>
>> So we can perhaps stick with JDK 8 for as long as we need and maybe
>> then jump to 11 when we are ready.
>>
>> On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
>> <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I was wondering about that too when I read this thread on Tweeter
>>>
>>> https://twitter.com/holgerbrands/status/957572736129339392
>>>
>>> But it seems OK finally
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>>>
>>>> Thank you Michael for starting this thread.
>>>> When discussing this, we will also have to consider that OFBiz currently
>>>> depends on several other Open Source products that will have to be
>>>> compatible with the platform we will choose (however, considering that
>>>> backward compatibility is maintained in new Java releases this is not
>>>> going
>>>> to be a major concern).
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl
>>>> <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi devs,
>>>>>
>>>>> this is just an initial information and dicussion starter to make
>>>>> everyone
>>>>> aware of this:
>>>>>
>>>>> the Oracle Java release model is changing from a feature based to a
>>>>> time
>>>>> based model [1]. One major drawback is that there will be no more
>>>>> public
>>>>> patch releases for older versions once a new release is published, if I
>>>>> understand correctly.
>>>>>
>>>>> We'll have to discuss if this affects the project in terms of support
>>>>> for
>>>>> the latest public Java releases. If we want to stay up-to-date
>>>>> according
>>>>> to
>>>>> the public releases, we'll have to establish a process to early check
>>>>> the
>>>>> new features and changes of a coming release and maybe release more
>>>>> often.
>>>>>
>>>>> We might even have to support the latest Java release along with the
>>>>> current LTS release to cover both users with and without commercial
>>>>> support? I'm not sure.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Michael
>>>>>
>>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>>
>>>>>
>>>>>
>>>>>
>

[Michael Brohl-3]

The problem with LTS is that it is not free. If we stick to LTS, we
won't support the users which use the public versions. To get security
updates, these users have to change their version every half year.

It's difficult to say if you will have compatibility problems beetween
those public versions but it is possible.

Regards,

Michael


Am 30.01.18 um 18:12 schrieb Taher Alkhateeb:

> Sure but If we choose to go with 9, then we _must_ keep jumping every
> 6 months or so. You either stick with an LTS or you don't, and as per
> my understanding 9 and 10 are not LTS. Read the article for more
> information.
>
> On Tue, Jan 30, 2018 at 8:01 PM, Jacques Le Roux
> <[hidden email]> wrote:
>> That sounds wise to me, maybe we can try Java 9 though, to not get too much
>> things to do later?
>>
>> Jacques
>>
>>
>>
>> Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :
>>> If I understood the documentation correctly, we have to choose between
>>> two different packages:
>>> - Stable release (long term support, less features)
>>> - Feature release (short term support, more features)
>>>
>>> Of the two, I think the stable LTS seems to be more compatible with
>>> our own release cycle. Also we don't usually go crazy with feature
>>> adoption and we prefer to take things slow.
>>>
>>> So we can perhaps stick with JDK 8 for as long as we need and maybe
>>> then jump to 11 when we are ready.
>>>
>>> On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
>>> <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> I was wondering about that too when I read this thread on Tweeter
>>>>
>>>> https://twitter.com/holgerbrands/status/957572736129339392
>>>>
>>>> But it seems OK finally
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>>>> Thank you Michael for starting this thread.
>>>>> When discussing this, we will also have to consider that OFBiz currently
>>>>> depends on several other Open Source products that will have to be
>>>>> compatible with the platform we will choose (however, considering that
>>>>> backward compatibility is maintained in new Java releases this is not
>>>>> going
>>>>> to be a major concern).
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>> this is just an initial information and dicussion starter to make
>>>>>> everyone
>>>>>> aware of this:
>>>>>>
>>>>>> the Oracle Java release model is changing from a feature based to a
>>>>>> time
>>>>>> based model [1]. One major drawback is that there will be no more
>>>>>> public
>>>>>> patch releases for older versions once a new release is published, if I
>>>>>> understand correctly.
>>>>>>
>>>>>> We'll have to discuss if this affects the project in terms of support
>>>>>> for
>>>>>> the latest public Java releases. If we want to stay up-to-date
>>>>>> according
>>>>>> to
>>>>>> the public releases, we'll have to establish a process to early check
>>>>>> the
>>>>>> new features and changes of a coming release and maybe release more
>>>>>> often.
>>>>>>
>>>>>> We might even have to support the latest Java release along with the
>>>>>> current LTS release to cover both users with and without commercial
>>>>>> support? I'm not sure.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>>>
>>>>>>
>>>>>>
>>>>>>

[taher]

I see. Hmm, then I'm not sure, but perhaps we have no choice but to go
with the short term releases then.

On Tue, Jan 30, 2018 at 8:32 PM, Michael Brohl <[hidden email]> wrote:

> The problem with LTS is that it is not free. If we stick to LTS, we won't
> support the users which use the public versions. To get security updates,
> these users have to change their version every half year.
>
> It's difficult to say if you will have compatibility problems beetween those
> public versions but it is possible.
>
> Regards,
>
> Michael
>
>
> Am 30.01.18 um 18:12 schrieb Taher Alkhateeb:
>
>> Sure but If we choose to go with 9, then we _must_ keep jumping every
>> 6 months or so. You either stick with an LTS or you don't, and as per
>> my understanding 9 and 10 are not LTS. Read the article for more
>> information.
>>
>> On Tue, Jan 30, 2018 at 8:01 PM, Jacques Le Roux
>> <[hidden email]> wrote:
>>>
>>> That sounds wise to me, maybe we can try Java 9 though, to not get too
>>> much
>>> things to do later?
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :
>>>>
>>>> If I understood the documentation correctly, we have to choose between
>>>> two different packages:
>>>> - Stable release (long term support, less features)
>>>> - Feature release (short term support, more features)
>>>>
>>>> Of the two, I think the stable LTS seems to be more compatible with
>>>> our own release cycle. Also we don't usually go crazy with feature
>>>> adoption and we prefer to take things slow.
>>>>
>>>> So we can perhaps stick with JDK 8 for as long as we need and maybe
>>>> then jump to 11 when we are ready.
>>>>
>>>> On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I was wondering about that too when I read this thread on Tweeter
>>>>>
>>>>> https://twitter.com/holgerbrands/status/957572736129339392
>>>>>
>>>>> But it seems OK finally
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>>>>>
>>>>>> Thank you Michael for starting this thread.
>>>>>> When discussing this, we will also have to consider that OFBiz
>>>>>> currently
>>>>>> depends on several other Open Source products that will have to be
>>>>>> compatible with the platform we will choose (however, considering that
>>>>>> backward compatibility is maintained in new Java releases this is not
>>>>>> going
>>>>>> to be a major concern).
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl
>>>>>> <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> this is just an initial information and dicussion starter to make
>>>>>>> everyone
>>>>>>> aware of this:
>>>>>>>
>>>>>>> the Oracle Java release model is changing from a feature based to a
>>>>>>> time
>>>>>>> based model [1]. One major drawback is that there will be no more
>>>>>>> public
>>>>>>> patch releases for older versions once a new release is published, if
>>>>>>> I
>>>>>>> understand correctly.
>>>>>>>
>>>>>>> We'll have to discuss if this affects the project in terms of support
>>>>>>> for
>>>>>>> the latest public Java releases. If we want to stay up-to-date
>>>>>>> according
>>>>>>> to
>>>>>>> the public releases, we'll have to establish a process to early check
>>>>>>> the
>>>>>>> new features and changes of a coming release and maybe release more
>>>>>>> often.
>>>>>>>
>>>>>>> We might even have to support the latest Java release along with the
>>>>>>> current LTS release to cover both users with and without commercial
>>>>>>> support? I'm not sure.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
>

[Jacques Le Roux]

This indeed lets not much choices

Jacques


Le 30/01/2018 à 18:35, Taher Alkhateeb a écrit :

> I see. Hmm, then I'm not sure, but perhaps we have no choice but to go
> with the short term releases then.
>
> On Tue, Jan 30, 2018 at 8:32 PM, Michael Brohl <[hidden email]> wrote:
>> The problem with LTS is that it is not free. If we stick to LTS, we won't
>> support the users which use the public versions. To get security updates,
>> these users have to change their version every half year.
>>
>> It's difficult to say if you will have compatibility problems beetween those
>> public versions but it is possible.
>>
>> Regards,
>>
>> Michael
>>
>>
>> Am 30.01.18 um 18:12 schrieb Taher Alkhateeb:
>>
>>> Sure but If we choose to go with 9, then we _must_ keep jumping every
>>> 6 months or so. You either stick with an LTS or you don't, and as per
>>> my understanding 9 and 10 are not LTS. Read the article for more
>>> information.
>>>
>>> On Tue, Jan 30, 2018 at 8:01 PM, Jacques Le Roux
>>> <[hidden email]> wrote:
>>>> That sounds wise to me, maybe we can try Java 9 though, to not get too
>>>> much
>>>> things to do later?
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :
>>>>> If I understood the documentation correctly, we have to choose between
>>>>> two different packages:
>>>>> - Stable release (long term support, less features)
>>>>> - Feature release (short term support, more features)
>>>>>
>>>>> Of the two, I think the stable LTS seems to be more compatible with
>>>>> our own release cycle. Also we don't usually go crazy with feature
>>>>> adoption and we prefer to take things slow.
>>>>>
>>>>> So we can perhaps stick with JDK 8 for as long as we need and maybe
>>>>> then jump to 11 when we are ready.
>>>>>
>>>>> On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
>>>>> <[hidden email]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I was wondering about that too when I read this thread on Tweeter
>>>>>>
>>>>>> https://twitter.com/holgerbrands/status/957572736129339392
>>>>>>
>>>>>> But it seems OK finally
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>>>>>> Thank you Michael for starting this thread.
>>>>>>> When discussing this, we will also have to consider that OFBiz
>>>>>>> currently
>>>>>>> depends on several other Open Source products that will have to be
>>>>>>> compatible with the platform we will choose (however, considering that
>>>>>>> backward compatibility is maintained in new Java releases this is not
>>>>>>> going
>>>>>>> to be a major concern).
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl
>>>>>>> <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi devs,
>>>>>>>>
>>>>>>>> this is just an initial information and dicussion starter to make
>>>>>>>> everyone
>>>>>>>> aware of this:
>>>>>>>>
>>>>>>>> the Oracle Java release model is changing from a feature based to a
>>>>>>>> time
>>>>>>>> based model [1]. One major drawback is that there will be no more
>>>>>>>> public
>>>>>>>> patch releases for older versions once a new release is published, if
>>>>>>>> I
>>>>>>>> understand correctly.
>>>>>>>>
>>>>>>>> We'll have to discuss if this affects the project in terms of support
>>>>>>>> for
>>>>>>>> the latest public Java releases. If we want to stay up-to-date
>>>>>>>> according
>>>>>>>> to
>>>>>>>> the public releases, we'll have to establish a process to early check
>>>>>>>> the
>>>>>>>> new features and changes of a coming release and maybe release more
>>>>>>>> often.
>>>>>>>>
>>>>>>>> We might even have to support the latest Java release along with the
>>>>>>>> current LTS release to cover both users with and without commercial
>>>>>>>> support? I'm not sure.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>

[Deepak Dixit-3]

In this case what about our release polices?
Are we going to update release as well in every 6 month?

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Wed, Jan 31, 2018 at 12:52 AM, Jacques Le Roux <
[hidden email]> wrote:

> This indeed lets not much choices
>
> Jacques
>
>
>
> Le 30/01/2018 à 18:35, Taher Alkhateeb a écrit :
>
>> I see. Hmm, then I'm not sure, but perhaps we have no choice but to go
>> with the short term releases then.
>>
>> On Tue, Jan 30, 2018 at 8:32 PM, Michael Brohl <[hidden email]>
>> wrote:
>>
>>> The problem with LTS is that it is not free. If we stick to LTS, we won't
>>> support the users which use the public versions. To get security updates,
>>> these users have to change their version every half year.
>>>
>>> It's difficult to say if you will have compatibility problems beetween
>>> those
>>> public versions but it is possible.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 30.01.18 um 18:12 schrieb Taher Alkhateeb:
>>>
>>> Sure but If we choose to go with 9, then we _must_ keep jumping every
>>>> 6 months or so. You either stick with an LTS or you don't, and as per
>>>> my understanding 9 and 10 are not LTS. Read the article for more
>>>> information.
>>>>
>>>> On Tue, Jan 30, 2018 at 8:01 PM, Jacques Le Roux
>>>> <[hidden email]> wrote:
>>>>
>>>>> That sounds wise to me, maybe we can try Java 9 though, to not get too
>>>>> much
>>>>> things to do later?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :
>>>>>
>>>>>> If I understood the documentation correctly, we have to choose between
>>>>>> two different packages:
>>>>>> - Stable release (long term support, less features)
>>>>>> - Feature release (short term support, more features)
>>>>>>
>>>>>> Of the two, I think the stable LTS seems to be more compatible with
>>>>>> our own release cycle. Also we don't usually go crazy with feature
>>>>>> adoption and we prefer to take things slow.
>>>>>>
>>>>>> So we can perhaps stick with JDK 8 for as long as we need and maybe
>>>>>> then jump to 11 when we are ready.
>>>>>>
>>>>>> On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was wondering about that too when I read this thread on Tweeter
>>>>>>>
>>>>>>> https://twitter.com/holgerbrands/status/957572736129339392
>>>>>>>
>>>>>>> But it seems OK finally
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>>>>>>
>>>>>>>> Thank you Michael for starting this thread.
>>>>>>>> When discussing this, we will also have to consider that OFBiz
>>>>>>>> currently
>>>>>>>> depends on several other Open Source products that will have to be
>>>>>>>> compatible with the platform we will choose (however, considering
>>>>>>>> that
>>>>>>>> backward compatibility is maintained in new Java releases this is
>>>>>>>> not
>>>>>>>> going
>>>>>>>> to be a major concern).
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl
>>>>>>>> <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi devs,
>>>>>>>>>
>>>>>>>>> this is just an initial information and dicussion starter to make
>>>>>>>>> everyone
>>>>>>>>> aware of this:
>>>>>>>>>
>>>>>>>>> the Oracle Java release model is changing from a feature based to a
>>>>>>>>> time
>>>>>>>>> based model [1]. One major drawback is that there will be no more
>>>>>>>>> public
>>>>>>>>> patch releases for older versions once a new release is published,
>>>>>>>>> if
>>>>>>>>> I
>>>>>>>>> understand correctly.
>>>>>>>>>
>>>>>>>>> We'll have to discuss if this affects the project in terms of
>>>>>>>>> support
>>>>>>>>> for
>>>>>>>>> the latest public Java releases. If we want to stay up-to-date
>>>>>>>>> according
>>>>>>>>> to
>>>>>>>>> the public releases, we'll have to establish a process to early
>>>>>>>>> check
>>>>>>>>> the
>>>>>>>>> new features and changes of a coming release and maybe release more
>>>>>>>>> often.
>>>>>>>>>
>>>>>>>>> We might even have to support the latest Java release along with
>>>>>>>>> the
>>>>>>>>> current LTS release to cover both users with and without commercial
>>>>>>>>> support? I'm not sure.
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>
>

[Michael Brohl-3]

Hi Deepak,

depending on the model we choose, this could be a consequence, yes. This
was one of the reasons why I raised this topic.

I see the advantage that we'll have to be more focused on stability and
make good decisions what will go into a release. The downside is that
we'll have the release overhead at least twice a year and we might have
to maintain trunk plus 2 release branches (current release and next
release with Java pre-release).

Regards,

Michael


Am 31.01.18 um 06:07 schrieb Deepak Dixit:

> In this case what about our release polices?
> Are we going to update release as well in every 6 month?
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Wed, Jan 31, 2018 at 12:52 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> This indeed lets not much choices
>>
>> Jacques
>>
>>
>>
>> Le 30/01/2018 à 18:35, Taher Alkhateeb a écrit :
>>
>>> I see. Hmm, then I'm not sure, but perhaps we have no choice but to go
>>> with the short term releases then.
>>>
>>> On Tue, Jan 30, 2018 at 8:32 PM, Michael Brohl <[hidden email]>
>>> wrote:
>>>
>>>> The problem with LTS is that it is not free. If we stick to LTS, we won't
>>>> support the users which use the public versions. To get security updates,
>>>> these users have to change their version every half year.
>>>>
>>>> It's difficult to say if you will have compatibility problems beetween
>>>> those
>>>> public versions but it is possible.
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>
>>>> Am 30.01.18 um 18:12 schrieb Taher Alkhateeb:
>>>>
>>>> Sure but If we choose to go with 9, then we _must_ keep jumping every
>>>>> 6 months or so. You either stick with an LTS or you don't, and as per
>>>>> my understanding 9 and 10 are not LTS. Read the article for more
>>>>> information.
>>>>>
>>>>> On Tue, Jan 30, 2018 at 8:01 PM, Jacques Le Roux
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> That sounds wise to me, maybe we can try Java 9 though, to not get too
>>>>>> much
>>>>>> things to do later?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :
>>>>>>
>>>>>>> If I understood the documentation correctly, we have to choose between
>>>>>>> two different packages:
>>>>>>> - Stable release (long term support, less features)
>>>>>>> - Feature release (short term support, more features)
>>>>>>>
>>>>>>> Of the two, I think the stable LTS seems to be more compatible with
>>>>>>> our own release cycle. Also we don't usually go crazy with feature
>>>>>>> adoption and we prefer to take things slow.
>>>>>>>
>>>>>>> So we can perhaps stick with JDK 8 for as long as we need and maybe
>>>>>>> then jump to 11 when we are ready.
>>>>>>>
>>>>>>> On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux
>>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I was wondering about that too when I read this thread on Tweeter
>>>>>>>>
>>>>>>>> https://twitter.com/holgerbrands/status/957572736129339392
>>>>>>>>
>>>>>>>> But it seems OK finally
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>>> Thank you Michael for starting this thread.
>>>>>>>>> When discussing this, we will also have to consider that OFBiz
>>>>>>>>> currently
>>>>>>>>> depends on several other Open Source products that will have to be
>>>>>>>>> compatible with the platform we will choose (however, considering
>>>>>>>>> that
>>>>>>>>> backward compatibility is maintained in new Java releases this is
>>>>>>>>> not
>>>>>>>>> going
>>>>>>>>> to be a major concern).
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl
>>>>>>>>> <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi devs,
>>>>>>>>>> this is just an initial information and dicussion starter to make
>>>>>>>>>> everyone
>>>>>>>>>> aware of this:
>>>>>>>>>>
>>>>>>>>>> the Oracle Java release model is changing from a feature based to a
>>>>>>>>>> time
>>>>>>>>>> based model [1]. One major drawback is that there will be no more
>>>>>>>>>> public
>>>>>>>>>> patch releases for older versions once a new release is published,
>>>>>>>>>> if
>>>>>>>>>> I
>>>>>>>>>> understand correctly.
>>>>>>>>>>
>>>>>>>>>> We'll have to discuss if this affects the project in terms of
>>>>>>>>>> support
>>>>>>>>>> for
>>>>>>>>>> the latest public Java releases. If we want to stay up-to-date
>>>>>>>>>> according
>>>>>>>>>> to
>>>>>>>>>> the public releases, we'll have to establish a process to early
>>>>>>>>>> check
>>>>>>>>>> the
>>>>>>>>>> new features and changes of a coming release and maybe release more
>>>>>>>>>> often.
>>>>>>>>>>
>>>>>>>>>> We might even have to support the latest Java release along with
>>>>>>>>>> the
>>>>>>>>>> current LTS release to cover both users with and without commercial
>>>>>>>>>> support? I'm not sure.
>>>>>>>>>>
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Michael
>>>>>>>>>>
>>>>>>>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

[James Yong-2]

Hi all,

Not sure if this is workable.
Can we do open-source development against OpenJDK using a version that is close to an Oracle JDK with LTS? Customers can choose the corresponding Oracle JDK with LTS in production if they want to.  

Regards,
James Yong

On 2018/01/29 16:21:50, Michael Brohl <[hidden email]> wrote:

> Hi devs,
>
> this is just an initial information and dicussion starter to make
> everyone aware of this:
>
> the Oracle Java release model is changing from a feature based to a time
> based model [1]. One major drawback is that there will be no more public
> patch releases for older versions once a new release is published, if I
> understand correctly.
>
> We'll have to discuss if this affects the project in terms of support
> for the latest public Java releases. If we want to stay up-to-date
> according to the public releases, we'll have to establish a process to
> early check the new features and changes of a coming release and maybe
> release more often.
>
> We might even have to support the latest Java release along with the
> current LTS release to cover both users with and without commercial
> support? I'm not sure.
>
> What do you think?
>
> Best regards,
>
> Michael
>
> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>
>
>
>

[taher]

I suspect that there is no difference between openjdk and oracle jdk as far
as the release cycle because oracle steers both.

However, like Jacopo I am not too concerned. The quick release cycle they
want to adopt means that there will be perhaps less drastic changes between
the versions.

I am open to changing our release cycle, but then we have to think
carefully about releases and more importantly we _must_ automate updates.
Something we can get ideas from is the upgrade package that a software
system like suitecrm provides to allow users to upgrade with a click.

However, I prefer sticking with our release cycle until we have a complete
idea of how to proceed.

On Jan 31, 2018 5:41 PM, "James Yong" <[hidden email]> wrote:

Hi all,

Not sure if this is workable.
Can we do open-source development against OpenJDK using a version that is
close to an Oracle JDK with LTS? Customers can choose the corresponding
Oracle JDK with LTS in production if they want to.

Regards,
James Yong

On 2018/01/29 16:21:50, Michael Brohl <[hidden email]> wrote:

> Hi devs,
>
> this is just an initial information and dicussion starter to make
> everyone aware of this:
>
> the Oracle Java release model is changing from a feature based to a time
> based model [1]. One major drawback is that there will be no more public
> patch releases for older versions once a new release is published, if I
> understand correctly.
>
> We'll have to discuss if this affects the project in terms of support
> for the latest public Java releases. If we want to stay up-to-date
> according to the public releases, we'll have to establish a process to
> early check the new features and changes of a coming release and maybe
> release more often.
>
> We might even have to support the latest Java release along with the
> current LTS release to cover both users with and without commercial
> support? I'm not sure.
>
> What do you think?
>
> Best regards,
>
> Michael
>
> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>
>
>
>

[Michael Brohl-3]

FYI: http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html

Regards,
Michael

> Am 31.01.2018 um 17:44 schrieb Taher Alkhateeb <[hidden email]>:
>
> I suspect that there is no difference between openjdk and oracle jdk as far
> as the release cycle because oracle steers both.
>
> However, like Jacopo I am not too concerned. The quick release cycle they
> want to adopt means that there will be perhaps less drastic changes between
> the versions.
>
> I am open to changing our release cycle, but then we have to think
> carefully about releases and more importantly we _must_ automate updates.
> Something we can get ideas from is the upgrade package that a software
> system like suitecrm provides to allow users to upgrade with a click.
>
> However, I prefer sticking with our release cycle until we have a complete
> idea of how to proceed.
>
> On Jan 31, 2018 5:41 PM, "James Yong" <[hidden email]> wrote:
>
> Hi all,
>
> Not sure if this is workable.
> Can we do open-source development against OpenJDK using a version that is
> close to an Oracle JDK with LTS? Customers can choose the corresponding
> Oracle JDK with LTS in production if they want to.
>
> Regards,
> James Yong
>
>> On 2018/01/29 16:21:50, Michael Brohl <[hidden email]> wrote:
>> Hi devs,
>>
>> this is just an initial information and dicussion starter to make
>> everyone aware of this:
>>
>> the Oracle Java release model is changing from a feature based to a time
>> based model [1]. One major drawback is that there will be no more public
>> patch releases for older versions once a new release is published, if I
>> understand correctly.
>>
>> We'll have to discuss if this affects the project in terms of support
>> for the latest public Java releases. If we want to stay up-to-date
>> according to the public releases, we'll have to establish a process to
>> early check the new features and changes of a coming release and maybe
>> release more often.
>>
>> We might even have to support the latest Java release along with the
>> current LTS release to cover both users with and without commercial
>> support? I'm not sure.
>>
>> What do you think?
>>
>> Best regards,
>>
>> Michael
>>
>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>
>>
>>
>>

[Jacques Le Roux]

Thanks Michael,

Quite illuminating, I'd tend to wait for Java 11 (only 6 months from now) So it seems we will need to replace Java EE by Eclipse Jakarta, not sure
when yet, I guess before moving to Java 11

TL;DR: EE: http://openjdk.java.net/projects/jdk/11/

More at

https://dzone.com/articles/an-early-look-at-features-targeted-for-java-11

https://blog.takipi.com/java-11-will-include-more-than-just-features/

My 2cts

Jacques


Le 21/03/2018 à 22:45, Michael Brohl a écrit :

> FYI: http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html
>
> Regards,
> Michael
>
>> Am 31.01.2018 um 17:44 schrieb Taher Alkhateeb <[hidden email]>:
>>
>> I suspect that there is no difference between openjdk and oracle jdk as far
>> as the release cycle because oracle steers both.
>>
>> However, like Jacopo I am not too concerned. The quick release cycle they
>> want to adopt means that there will be perhaps less drastic changes between
>> the versions.
>>
>> I am open to changing our release cycle, but then we have to think
>> carefully about releases and more importantly we _must_ automate updates.
>> Something we can get ideas from is the upgrade package that a software
>> system like suitecrm provides to allow users to upgrade with a click.
>>
>> However, I prefer sticking with our release cycle until we have a complete
>> idea of how to proceed.
>>
>> On Jan 31, 2018 5:41 PM, "James Yong" <[hidden email]> wrote:
>>
>> Hi all,
>>
>> Not sure if this is workable.
>> Can we do open-source development against OpenJDK using a version that is
>> close to an Oracle JDK with LTS? Customers can choose the corresponding
>> Oracle JDK with LTS in production if they want to.
>>
>> Regards,
>> James Yong
>>
>>> On 2018/01/29 16:21:50, Michael Brohl <[hidden email]> wrote:
>>> Hi devs,
>>>
>>> this is just an initial information and dicussion starter to make
>>> everyone aware of this:
>>>
>>> the Oracle Java release model is changing from a feature based to a time
>>> based model [1]. One major drawback is that there will be no more public
>>> patch releases for older versions once a new release is published, if I
>>> understand correctly.
>>>
>>> We'll have to discuss if this affects the project in terms of support
>>> for the latest public Java releases. If we want to stay up-to-date
>>> according to the public releases, we'll have to establish a process to
>>> early check the new features and changes of a coming release and maybe
>>> release more often.
>>>
>>> We might even have to support the latest Java release along with the
>>> current LTS release to cover both users with and without commercial
>>> support? I'm not sure.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>>
>>> Michael
>>>
>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>
>>>
>>>
>>>

[Jacques Le Roux]

BTW Java 10 is available today http://jdk.java.net/10/


Le 22/03/2018 à 06:26, Jacques Le Roux a écrit :

> Thanks Michael,
>
> Quite illuminating, I'd tend to wait for Java 11 (only 6 months from now) So it seems we will need to replace Java EE by Eclipse Jakarta, not sure
> when yet, I guess before moving to Java 11
>
> TL;DR: EE: http://openjdk.java.net/projects/jdk/11/
>
> More at
>
> https://dzone.com/articles/an-early-look-at-features-targeted-for-java-11
>
> https://blog.takipi.com/java-11-will-include-more-than-just-features/
>
> My 2cts
>
> Jacques
>
>
> Le 21/03/2018 à 22:45, Michael Brohl a écrit :
>> FYI: http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html
>>
>> Regards,
>> Michael
>>
>>> Am 31.01.2018 um 17:44 schrieb Taher Alkhateeb <[hidden email]>:
>>>
>>> I suspect that there is no difference between openjdk and oracle jdk as far
>>> as the release cycle because oracle steers both.
>>>
>>> However, like Jacopo I am not too concerned. The quick release cycle they
>>> want to adopt means that there will be perhaps less drastic changes between
>>> the versions.
>>>
>>> I am open to changing our release cycle, but then we have to think
>>> carefully about releases and more importantly we _must_ automate updates.
>>> Something we can get ideas from is the upgrade package that a software
>>> system like suitecrm provides to allow users to upgrade with a click.
>>>
>>> However, I prefer sticking with our release cycle until we have a complete
>>> idea of how to proceed.
>>>
>>> On Jan 31, 2018 5:41 PM, "James Yong" <[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>> Not sure if this is workable.
>>> Can we do open-source development against OpenJDK using a version that is
>>> close to an Oracle JDK with LTS? Customers can choose the corresponding
>>> Oracle JDK with LTS in production if they want to.
>>>
>>> Regards,
>>> James Yong
>>>
>>>> On 2018/01/29 16:21:50, Michael Brohl <[hidden email]> wrote:
>>>> Hi devs,
>>>>
>>>> this is just an initial information and dicussion starter to make
>>>> everyone aware of this:
>>>>
>>>> the Oracle Java release model is changing from a feature based to a time
>>>> based model [1]. One major drawback is that there will be no more public
>>>> patch releases for older versions once a new release is published, if I
>>>> understand correctly.
>>>>
>>>> We'll have to discuss if this affects the project in terms of support
>>>> for the latest public Java releases. If we want to stay up-to-date
>>>> according to the public releases, we'll have to establish a process to
>>>> early check the new features and changes of a coming release and maybe
>>>> release more often.
>>>>
>>>> We might even have to support the latest Java release along with the
>>>> current LTS release to cover both users with and without commercial
>>>> support? I'm not sure.
>>>>
>>>> What do you think?
>>>>
>>>> Best regards,
>>>>
>>>> Michael
>>>>
>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>
>>>>
>>>>
>>>>
>
>

[Michael Brohl-3]

Hi devs,

a quick heads up for this topic.

After following the release strategy and thinking more about it, I think
that most users will go with a subscription model and subscribe for an
LTS version. The costs are moderate [1] and I assume that few users will
go through a repeating 6 month "early access - update - test - go live"
circle for free Java versions.

Java 11 EA is available [2] so we could start to test with it.

The latest Intellij Idea already has support for Java 11, I suppose that
it will come for Eclipse Photon shortly also.

I wonder if we should base the OFBiz 17.12 release on Java 8 or Java 11.
We have no fixed release date yet so we might have time to do it.

Another way would be to make a new branch which will support Java 11.

What do people think?

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


[1]
http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html

[2] http://jdk.java.net/11/




Michael Brohl
Geschäftsführer

Fon      [phone]
Fax      [phone]
Mobil    [phone]
Xing     xing.com/profile/Michael_Brohl
LinkedIn linkedin.com/in/michaelbrohl

Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
Fon: [phone], Fax: [phone], www.ecomify.de

Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl

Am 29.01.18 um 17:21 schrieb Michael Brohl:

> Hi devs,
>
> this is just an initial information and dicussion starter to make
> everyone aware of this:
>
> the Oracle Java release model is changing from a feature based to a
> time based model [1]. One major drawback is that there will be no more
> public patch releases for older versions once a new release is
> published, if I understand correctly.
>
> We'll have to discuss if this affects the project in terms of support
> for the latest public Java releases. If we want to stay up-to-date
> according to the public releases, we'll have to establish a process to
> early check the new features and changes of a coming release and maybe
> release more often.
>
> We might even have to support the latest Java release along with the
> current LTS release to cover both users with and without commercial
> support? I'm not sure.
>
> What do you think?
>
> Best regards,
>
> Michael
>
> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>
>
>

[taher]

I am beginning to wonder if we should consider moving to OpenJDK. I think I
really dislike this release model with all the extra costs and headache
involved.

Are we stuck with Oracle JDK? Does anyone know of limitations or problems
with OpenJDK? I vaguely remember font problems with the BIRT plugin but I
cannot recall any serious issues.

On Sat, Jul 28, 2018, 10:56 AM Michael Brohl <[hidden email]>
wrote:

> Hi devs,
>
> a quick heads up for this topic.
>
> After following the release strategy and thinking more about it, I think
> that most users will go with a subscription model and subscribe for an
> LTS version. The costs are moderate [1] and I assume that few users will
> go through a repeating 6 month "early access - update - test - go live"
> circle for free Java versions.
>
> Java 11 EA is available [2] so we could start to test with it.
>
> The latest Intellij Idea already has support for Java 11, I suppose that
> it will come for Eclipse Photon shortly also.
>
> I wonder if we should base the OFBiz 17.12 release on Java 8 or Java 11.
> We have no fixed release date yet so we might have time to do it.
>
> Another way would be to make a new branch which will support Java 11.
>
> What do people think?
>
> Best regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> [1]
>
> http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html
>
> [2] http://jdk.java.net/11/
>
>
>
>
> Michael Brohl
> Geschäftsführer
>
> Fon      [phone]
> Fax      [phone]
> Mobil    [phone]
> Xing     xing.com/profile/Michael_Brohl
> LinkedIn linkedin.com/in/michaelbrohl
>
> Company and Management Headquarters:
> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
> Fon: [phone], Fax: [phone], www.ecomify.de
>
> Court Registration: Amtsgericht Bielefeld HRB 41683
> Chief Executive Officer: Martin Becker, Michael Brohl
>
> Am 29.01.18 um 17:21 schrieb Michael Brohl:
> > Hi devs,
> >
> > this is just an initial information and dicussion starter to make
> > everyone aware of this:
> >
> > the Oracle Java release model is changing from a feature based to a
> > time based model [1]. One major drawback is that there will be no more
> > public patch releases for older versions once a new release is
> > published, if I understand correctly.
> >
> > We'll have to discuss if this affects the project in terms of support
> > for the latest public Java releases. If we want to stay up-to-date
> > according to the public releases, we'll have to establish a process to
> > early check the new features and changes of a coming release and maybe
> > release more often.
> >
> > We might even have to support the latest Java release along with the
> > current LTS release to cover both users with and without commercial
> > support? I'm not sure.
> >
> > What do you think?
> >
> > Best regards,
> >
> > Michael
> >
> > [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
> >
> >
> >
>
>
>

[Michael Brohl-3]

Because OpenJDK is the base for the Oracle JDK and Oracle is working on
Open JDK, I  assume we will have the same problems. It can also be that
the two will be one product soon. Why should Oracle support Open JDK
with long term updates for free?

I did not find a clear roadmap for Open JDK so it's unclear to me how
long the versions will be supported.

I think Linux distributions will follow the LTS release cycle also,
because of the same reasons. Here's a statement for Red Hat:
https://access.redhat.com/articles/1299013 (at the bottom).

Most sources of information describe the Open JDK as a reference
implementation which is less stable than the Oracle JDK.

Personally, I have almost no experience using Open JDK in productive,
professional environments. There were problems years ago which I do not
remember exactly and we use Oracle JDK since then.

I think we should support Oracle JDK because professional users most
likely will use it and it would be a bad sign if OFBiz shows no official
support for it.

I also don't like the release model but the costs are moderate and using
the LTS version, there is no headache feature wise. Java 11 LTS will be
stable until 2023 or 2026 if you choose the extended subscription. Lots
of time to prepare for the next LTS version...

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 28.07.18 um 10:06 schrieb Taher Alkhateeb:

> I am beginning to wonder if we should consider moving to OpenJDK. I think I
> really dislike this release model with all the extra costs and headache
> involved.
>
> Are we stuck with Oracle JDK? Does anyone know of limitations or problems
> with OpenJDK? I vaguely remember font problems with the BIRT plugin but I
> cannot recall any serious issues.
>
> On Sat, Jul 28, 2018, 10:56 AM Michael Brohl <[hidden email]>
> wrote:
>
>> Hi devs,
>>
>> a quick heads up for this topic.
>>
>> After following the release strategy and thinking more about it, I think
>> that most users will go with a subscription model and subscribe for an
>> LTS version. The costs are moderate [1] and I assume that few users will
>> go through a repeating 6 month "early access - update - test - go live"
>> circle for free Java versions.
>>
>> Java 11 EA is available [2] so we could start to test with it.
>>
>> The latest Intellij Idea already has support for Java 11, I suppose that
>> it will come for Eclipse Photon shortly also.
>>
>> I wonder if we should base the OFBiz 17.12 release on Java 8 or Java 11.
>> We have no fixed release date yet so we might have time to do it.
>>
>> Another way would be to make a new branch which will support Java 11.
>>
>> What do people think?
>>
>> Best regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> [1]
>>
>> http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html
>>
>> [2] http://jdk.java.net/11/
>>
>>
>>
>>
>> Michael Brohl
>> Geschäftsführer
>>
>> Fon      [phone]
>> Fax      [phone]
>> Mobil    [phone]
>> Xing     xing.com/profile/Michael_Brohl
>> LinkedIn linkedin.com/in/michaelbrohl
>>
>> Company and Management Headquarters:
>> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
>> Fon: [phone], Fax: [phone], www.ecomify.de
>>
>> Court Registration: Amtsgericht Bielefeld HRB 41683
>> Chief Executive Officer: Martin Becker, Michael Brohl
>>
>> Am 29.01.18 um 17:21 schrieb Michael Brohl:
>>> Hi devs,
>>>
>>> this is just an initial information and dicussion starter to make
>>> everyone aware of this:
>>>
>>> the Oracle Java release model is changing from a feature based to a
>>> time based model [1]. One major drawback is that there will be no more
>>> public patch releases for older versions once a new release is
>>> published, if I understand correctly.
>>>
>>> We'll have to discuss if this affects the project in terms of support
>>> for the latest public Java releases. If we want to stay up-to-date
>>> according to the public releases, we'll have to establish a process to
>>> early check the new features and changes of a coming release and maybe
>>> release more often.
>>>
>>> We might even have to support the latest Java release along with the
>>> current LTS release to cover both users with and without commercial
>>> support? I'm not sure.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>>
>>> Michael
>>>
>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>
>>>
>>>
>>
>>

[taher]

I see. well this means we have to do multiple things:

- First we need to upgrade gradle
- I have no preference with release 17 Java version support

Now the problem with upgrading gradle in a nutshell is that you can no
longer have spaces in server commands. So ./gradlew "ofbiz --start"
will not work because of the space between "ofbiz" and "--start" and
that's why I created a JIRA for this issue [1]. I'm not sure what is
the best solution, one idea that came to me is perhaps to pass the
args to a string. So for example:

./gradlew ofbiz -Pcmd1="--load-data readers=seed" ofbiz
-Pcmd2="--start --portoffset=10000"

Maybe another option is to just run one "ofbiz" task and then pass
multiple commands each in a project paramter -Pcmd1= -Pcmd2= -Pcmd3=
... Another option is to hard wire all commands like we did back in
Ant days.

I'm not sure what is the best solution there, and I don't mean to
hijack this thread, but one thing depends on another thing. Should we
start a new thread for that? Collect ideas from the community?

[1] https://issues.apache.org/jira/browse/OFBIZ-9972

On Sat, Jul 28, 2018 at 11:47 AM, Michael Brohl
<[hidden email]> wrote:

> Because OpenJDK is the base for the Oracle JDK and Oracle is working on Open
> JDK, I  assume we will have the same problems. It can also be that the two
> will be one product soon. Why should Oracle support Open JDK with long term
> updates for free?
>
> I did not find a clear roadmap for Open JDK so it's unclear to me how long
> the versions will be supported.
>
> I think Linux distributions will follow the LTS release cycle also, because
> of the same reasons. Here's a statement for Red Hat:
> https://access.redhat.com/articles/1299013 (at the bottom).
>
> Most sources of information describe the Open JDK as a reference
> implementation which is less stable than the Oracle JDK.
>
> Personally, I have almost no experience using Open JDK in productive,
> professional environments. There were problems years ago which I do not
> remember exactly and we use Oracle JDK since then.
>
> I think we should support Oracle JDK because professional users most likely
> will use it and it would be a bad sign if OFBiz shows no official support
> for it.
>
> I also don't like the release model but the costs are moderate and using the
> LTS version, there is no headache feature wise. Java 11 LTS will be stable
> until 2023 or 2026 if you choose the extended subscription. Lots of time to
> prepare for the next LTS version...
>
> Best regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 28.07.18 um 10:06 schrieb Taher Alkhateeb:
>
>> I am beginning to wonder if we should consider moving to OpenJDK. I think
>> I
>> really dislike this release model with all the extra costs and headache
>> involved.
>>
>> Are we stuck with Oracle JDK? Does anyone know of limitations or problems
>> with OpenJDK? I vaguely remember font problems with the BIRT plugin but I
>> cannot recall any serious issues.
>>
>> On Sat, Jul 28, 2018, 10:56 AM Michael Brohl <[hidden email]>
>> wrote:
>>
>>> Hi devs,
>>>
>>> a quick heads up for this topic.
>>>
>>> After following the release strategy and thinking more about it, I think
>>> that most users will go with a subscription model and subscribe for an
>>> LTS version. The costs are moderate [1] and I assume that few users will
>>> go through a repeating 6 month "early access - update - test - go live"
>>> circle for free Java versions.
>>>
>>> Java 11 EA is available [2] so we could start to test with it.
>>>
>>> The latest Intellij Idea already has support for Java 11, I suppose that
>>> it will come for Eclipse Photon shortly also.
>>>
>>> I wonder if we should base the OFBiz 17.12 release on Java 8 or Java 11.
>>> We have no fixed release date yet so we might have time to do it.
>>>
>>> Another way would be to make a new branch which will support Java 11.
>>>
>>> What do people think?
>>>
>>> Best regards,
>>>
>>> Michael Brohl
>>> ecomify GmbH
>>> www.ecomify.de
>>>
>>>
>>> [1]
>>>
>>>
>>> http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html
>>>
>>> [2] http://jdk.java.net/11/
>>>
>>>
>>>
>>>
>>> Michael Brohl
>>> Geschäftsführer
>>>
>>> Fon      [phone]
>>> Fax      [phone]
>>> Mobil    [phone]
>>> Xing     xing.com/profile/Michael_Brohl
>>> LinkedIn linkedin.com/in/michaelbrohl
>>>
>>> Company and Management Headquarters:
>>> ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
>>> Fon: [phone], Fax: [phone], www.ecomify.de
>>>
>>> Court Registration: Amtsgericht Bielefeld HRB 41683
>>> Chief Executive Officer: Martin Becker, Michael Brohl
>>>
>>> Am 29.01.18 um 17:21 schrieb Michael Brohl:
>>>>
>>>> Hi devs,
>>>>
>>>> this is just an initial information and dicussion starter to make
>>>> everyone aware of this:
>>>>
>>>> the Oracle Java release model is changing from a feature based to a
>>>> time based model [1]. One major drawback is that there will be no more
>>>> public patch releases for older versions once a new release is
>>>> published, if I understand correctly.
>>>>
>>>> We'll have to discuss if this affects the project in terms of support
>>>> for the latest public Java releases. If we want to stay up-to-date
>>>> according to the public releases, we'll have to establish a process to
>>>> early check the new features and changes of a coming release and maybe
>>>> release more often.
>>>>
>>>> We might even have to support the latest Java release along with the
>>>> current LTS release to cover both users with and without commercial
>>>> support? I'm not sure.
>>>>
>>>> What do you think?
>>>>
>>>> Best regards,
>>>>
>>>> Michael
>>>>
>>>> [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
>>>>
>>>>
>>>>
>>>
>>>
>
>