Making Java 17 available in our Quarkus generated projects

[Andy Damevin]

Hello folks,

While making Java 17 available in our generated projects (#20849), we stumbled upon the fact that Java 17 is not yet available in the Red Hat packages catalog (it should be added on November 9).

Currently, our containers are using raw ubi-minimal as base image and then use the Red Hat packages catalog to install the jdk and the dockerfile is manually configured. 

- should we wait for java 17 and keep the current system?

- should we download the jdk manually and unzip it?

- should we use the ubi java image (I guess we will also have to wait for java 17 to become available with this option). From Clement feedback it seems it is very heavy.

- maybe another option?

Cheers,

--

Andy Damevin

[Sanne Grinovero]

I normally don't recommend waiting, but 9th of November is IMO close enough.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P56c8f9ZBZesnn-PmJOjVc%2BFRS5R-KATrhcsc1FDuLNfw%40mail.gmail.com.

[Andy Damevin]

Is there a reason why don't we abstract all the logic inside the project dockerfiles to our own quarkus base image?

--

Andy Damevin

[Max Rydahl Andersen]

On 27 Oct 2021, at 11:51, Andy Damevin wrote:

> Is there a reason why don't we abstract all the logic inside the project
> dockerfiles to our own quarkus base image?

What advantage would that gain ? now the user won't be able to adjust to his case; specifically
with native.

/max

>
> On Wed, Oct 27, 2021 at 11:46 AM Sanne Grinovero <sa...@hibernate.org>
> wrote:
>
>>
>> I normally don't recommend waiting, but 9th of November is IMO close
>> enough.
>>
>> On Wed, 27 Oct 2021 at 07:49, Andy Damevin <adam...@redhat.com> wrote:
>>
>>> Hello folks,
>>>
>>> While making Java 17 available in our generated projects (#20849

>>> <https://github.com/quarkusio/quarkus/pull/20849> ), we stumbled upon the

>>> fact that Java 17 is not yet available in the Red Hat packages catalog (it
>>> should be added on November 9).
>>>
>>> Currently, our containers are using raw ubi-minimal as base image and
>>> then use the Red Hat packages catalog to install the jdk and the dockerfile
>>> is manually configured.
>>>
>>> - should we wait for java 17 and keep the current system?
>>> - should we download the jdk manually and unzip it?
>>> - should we use the ubi java image (I guess we will also have to wait for
>>> java 17 to become available with this option). From Clement feedback it
>>> seems it is very heavy.
>>> - maybe another option?
>>>
>>> Cheers,
>>> --
>>> Andy Damevin
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to quarkus-dev...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P56c8f9ZBZesnn-PmJOjVc%2BFRS5R-KATrhcsc1FDuLNfw%40mail.gmail.com

>>> <https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P56c8f9ZBZesnn-PmJOjVc%2BFRS5R-KATrhcsc1FDuLNfw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>>
>
> --
> Andy Damevin
>
> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P6q9A9omnFkHVvbW9R%2BaKLDHBztqgR-qfEnKXdCnAY-qA%40mail.gmail.com.

[Andy Damevin]

Here are some advantages of having our own base images that I see:

- one base image for native, one base image for jvms

- ease of use (you just need to specify the java version and the put the jars/bins and maybe some inputs to customize a few things)

- reduce processing (less operations in the dockerfile which is currently pretty dense and obscure)

- less code to maintain in each new generated Quarkus projects

- easier to update on changes

- we keep control over the content and in case of bug a simple update of the tag would fix the problem for all the consumer

Maybe I am missing something but it seems pretty appealing from where I stand..

--

Andy Damevin

[Max Rydahl Andersen]

Instead of requiring a quarkus built image (of which we would need a different one based on what platform you target) I think biggest benefit would be we didn’t have static generated Docker files but just generate them based on what build is happening.

Users can still create or generate static file but we would remove all the disadvantages you point to Afaics and make updates even simpler as no custom image build needed. 

/max

[Andy Damevin]

that sounds good to me too :)

--

Andy Damevin

[Max Rydahl Andersen]

Doesn’t solve the initial challenge. - where to get java17 image for our current setup. 

/max

[Andy Damevin]

On Wed, Oct 27, 2021 at 6:07 PM Max Rydahl Andersen <mand...@redhat.com> wrote:

Doesn’t solve the initial challenge. - where to get java17 image for our current setup. 

Yeah let's wait for java 17. I created this issue for your suggestion:

https://github.com/quarkusio/quarkus/issues/21081

--

Andy Damevin

[Sergey Bezrukov]

I think it will be great to get rid of any additional downloads during the docker build phase. My personal favorite java images is bellsoft's jdk images (https://hub.docker.com/u/bellsoft)

Also, using https://github.com/fabric8io-images/run-java-sh/blob/master/fish-pepper/run-java-sh/fp-files/run-java.sh for application start seems a good idea,
We use this variant (base java image from bellsoft+run-java.sh) widely in our Quarkus deployments and 100% happy with it.

--
Sergey Bezrukov
Cell: +7(903)790-93-34
Skype: sergey.bezrukov

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P56c8f9ZBZesnn-PmJOjVc%2BFRS5R-KATrhcsc1FDuLNfw%40mail.gmail.com.

[Max Rydahl Andersen]

On 1 Nov 2021, at 7:44, Sergey Bezrukov wrote:

I think it will be great to get rid of any additional downloads during the
docker build phase. My personal favorite java images is bellsoft's jdk
images (https://hub.docker.com/u/bellsoft)

whats special about those to make them favourites ?

Also, using
https://github.com/fabric8io-images/run-java-sh/blob/master/fish-pepper/run-java-sh/fp-files/run-java.sh
for application start seems a good idea,

I believe there are some newer replacement of these which haven't been updated for a while but not actually sure where they are atm.

We use this variant (base java image from bellsoft+run-java.sh) widely in
our Quarkus deployments and 100% happy with it.

cool.

--
Sergey Bezrukov
Cell: +7(903)790-93-34
Skype: sergey.bezrukov

On Wed, Oct 27, 2021 at 9:49 AM Andy Damevin adam...@redhat.com wrote:

Hello folks,

While making Java 17 available in our generated projects (#20849

https://github.com/quarkusio/quarkus/pull/20849 ), we stumbled upon the

fact that Java 17 is not yet available in the Red Hat packages catalog (it
should be added on November 9).

Currently, our containers are using raw ubi-minimal as base image and
then use the Red Hat packages catalog to install the jdk and the dockerfile
is manually configured.

• should we wait for java 17 and keep the current system?

• should we download the jdk manually and unzip it?

• should we use the ubi java image (I guess we will also have to wait for

java 17 to become available with this option). From Clement feedback it
seems it is very heavy.

• maybe another option?

Cheers,

Andy Damevin

--
You received this message because you are subscribed to the Google Groups
"Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P56c8f9ZBZesnn-PmJOjVc%2BFRS5R-KATrhcsc1FDuLNfw%40mail.gmail.com

https://groups.google.com/d/msgid/quarkus-dev/CAE_u_P56c8f9ZBZesnn-PmJOjVc%2BFRS5R-KATrhcsc1FDuLNfw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD1V%3DtR%2BPX1WvzWomLaWKj0T0eVG-WqHa3QHmWZWgpkAPOtc1g%40mail.gmail.com.

/max
https://xam.dk/about

[Thomas Qvarnstrom]

To be honest this worries me a bit. We should support Java 17 that is fine, but there is a different between supporting it and defaulting to it. Have we made a decision to default to Java 17 in our tooling?

Cheers

Thomas

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/12308B1B-131F-4CD9-8919-CE0CE14F658D%40redhat.com.

[Max Rydahl Andersen]

/max

On 4 Nov 2021, 13:25 +0100, Thomas Qvarnstrom <tqva...@redhat.com>, wrote:

To be honest this worries me a bit. We should support Java 17 that is fine, but there is a different between supporting it and defaulting to it. Have we made a decision to default to Java 17 in our tooling? 

No.

What’s your worry? Just being discussed we should have a way to make java 17 based images. 

[Thomas Qvarnstrom]

My worries is that if we start to default our tooling to Java 17 and generate project setups with example code that will not compile on Java 11. Initially I'm at least fine with us generating Java 11 projects that users can change to Java 17. But I guess my strong point here is. Just because we add Java 17 we cannot remove support for Java 11 and our tooling should either be able to handle both or if not possible, then it should default to 11.

Just my2cents

Thomas

----

Thomas Qvarnström
Sr. Pr. Product Manager
Red Hat, Inc.

[Max Rydahl Andersen]

Sure; I understand that. this thread was all about making java 17 available. Not about making it the default.

/max

[Emmanuel Bernard]

On Mon, Nov 8, 2021 at 1:29 PM Thomas Qvarnstrom <tqva...@redhat.com> wrote:

My worries is that if we start to default our tooling to Java 17 and generate project setups with example code that will not compile on Java 11.

https://youtu.be/L0MK7qz13bU?t=64  

😂

[Sanne Grinovero]

On Mon, 8 Nov 2021, 12:29 Thomas Qvarnstrom, <tqva...@redhat.com> wrote:

My worries is that if we start to default our tooling to Java 17 and generate project setups with example code that will not compile on Java 11. Initially I'm at least fine with us generating Java 11 projects that users can change to Java 17. But I guess my strong point here is. Just because we add Java 17 we cannot remove support for Java 11 and our tooling should either be able to handle both or if not possible, then it should default to 11.

Isn't it actually a good thing to have demos and quickstarts to use the latest LTS? It needs to keep feeling new.

I understand the desire to keep backwards compatibility, but that aspect can be taken care of by CI.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAFPdrWidZE4yx234ZZ%3DrtiZXfbf8LdAmn418b_9sLtjsz9rJNA%40mail.gmail.com.