You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenJDK should be the default instead a vendor's specific distribution, but there should be an option to opt into a specific vendor(azul, amazon, etc...)
Reacted by Peter Palaga, Manuel, Martin Grigorov, Andrea Del Bene, Christian Stein, Sean Gilligan, Ólafur Páll Geirsson, AdminOfThis, OdysseusLives, Akhil Marupilla and 10 more
One more vote for OpenJDK being an option!
Apache Wicket project tried GitHub actions but the build failed due to strange behavior of Java 11. I've contacted Oracle to ask whether a bug fix from Java 13 has been downported to Java 11 and they explained to me that 11.0.2 is the last release by Oracle. Anything newer is from any of the other vendors and they (Oracle) have no idea what is included in it.
More details about the problem and the discussion can be found at https://markmail.org/message/g5cbnw47kt7yrj7t
Reacted by Andrea Del Bene, Mohamed Moursi and Dmitriy Belyaev
Whoops, sorry I missed this, for some reason my alerts for this repo got turned off 😳
I actually originally wanted to do this using OpenJDK, but ran into an issue that I couldn't find a good solution to. Basically the OpenJDK download urls aren't consistent and there's not a well defined distro. So for example, here are the Linux download urls for a some of the versions, pulled from here:
Everything below that would be downloaded from oracle, and I think we run into licensing issues there that make normal curl downloads challenging. I'm open to solutions there, but have concerns about anything that requires us to hardcode a bunch of urls and/or update every time a new version is released.
Note that if you need openJDK you can do this by doing something like:
adoptopenjdk.net is nowaday's place to go for OpenJDK builds. They even offer an API that gives you access to all metadata and binaries you need https://api.adoptopenjdk.net/
Reacted by Sean Gilligan, Jan Erik Petersen, Clement Escoffier, Dmitriy Belyaev, David J. M. Karlsen, Kyle Martin and Steven R. Loomis
@onebeartoe Huh, that's a surprising error - could you open a separate issue to track that? Would rather keep this conversation focused to offering openJDK since that's a separate topic 😄. I'm not 100% sure, but checkout might change the working directory - so maybe try running ls after checkout? Regardless, lets follow up in another issue, I definitely want to get to the root of that.
Concerning the larger thread: I haven't had a chance to look into adoptopenjdk.net or https://github.com/sormuras/bach/blob/master/install-jdk.sh in depth yet, but am very open to using one of those/think we probably want something along those lines. At a glance, it looks like adoptoopenjdk.net offers cross plat linux/mac/windows support but install-jdk.sh only offers linux/mac, so I'm more inclined to use a solution that directly targets adoptopenjdk.net. If I'm missing something there please let me know.
Reacted by Peter Palaga and Jean-Marie Gaillourdet
Again I didn't meant to hijack this thread, and I didn't open a separate issue since I noticed what was going on with the order of the call to setup-java with jdkFile. Thanks
Adding other JDK distribution options and letting people pick whichever they want may be a good idea. But I'd like to highlight that Zulu Community is a build of OpenJDK. Zulu is no more "vendor-specific" than e.g. AdoptOpenJDK is "IBM specific" (IBM sells support for AdoptOpenJDK builds).
Zulu is the longest-standing, free, 100% OSS build of OpenJDK available for Linux, Windows, and MacOS. It has a full, well-maintained, and uninterrupted history of having good, free builds of every single version of OpenJDK thru 6, 7, 8, 9, 10, 11, 12, and now 13, over the past ~6 years. This wide coverage and commitment to consistent delivery is why you can currently test Java CI on Github Actions for fixed versions like e.g. Java 7u181 (7.0.181), Java 8u131 (8.0.131), Java 9.0.4, and Java 12.0.2 Just by specifying their versions, and will be able to continue to do so uninterrupted side by side with various form of "latest" (11 or 11.0.x vs. 11.0.3).
The OpenJDK project is a source code project (and the OpenJDK name is trademarked by Oracle). All OpenJDK binaries come from some form of downstream curated builds of OpenJDK version distributions. Zulu is simply the longest standing one, and by far the one with the most builds and versions available and reliably maintained. But there are others (e.g. Corretto, Liberica, SAP machine, etc. which are TCK tested, and some others that are not). It's a happy, multi-distro world. Just like Linux. And the numbers of free OpenJDK distros seems to be growing and flourishing, which is a good thing.
That's why adding choices for specifying an OpenJDK distro (via e.g. "distro: zulu", "distro: corretto" or "distro: liberica", "distro: adopt", "distro: sap") is probably a good idea. We'd be happy to collaborate on that.
Reacted by Alberto, Anton Prawiro, Lars Eckart, Jan Erik Petersen, Björn Darri Sigurðsson, Mantas Kalanta, Madhuri Gummalla, Geertjan Wielenga, Jean-Marie Gaillourdet, Bruno Borges and 5 more
@davidkarlsen , your proposal makes sense to me and looks like it won't be a breaking change since we default new property to true by default.
We are okay to include these changes to v2. I have left a couple of comments in #82 . Could you please rebase your branch based on v2-preview branch and re-target pull-request (I guess you will have a ton of conflicts)?
If you don't have a time - we will adapt your PR for v2 in a few days.
We are going to release v2 stable by the end of next week but we would be very appreciate for any testing of v2-preview and confirmations that it works as expected with both adopt and zulu distributions
Hello everyone. On Monday 5th April we released setup-java@v2 and also resolved some other issues related to setup-java@v1 in v2. Now task supports to setup AdoptOpenJdk in addition to Zulu's distribution. It can be done through required distribution field. For detailed explanation you can see migration guide from v1 to v2 and advanced usage for setup-java@v2. If you face up with strange or unexpected behaviour feel free to create separate issue.
Activity
mattnelson commentedon Aug 12, 2019
OpenJDK should be the default instead a vendor's specific distribution, but there should be an option to opt into a specific vendor(azul, amazon, etc...)
onebeartoe commentedon Aug 16, 2019
I hope I am not hijacking this thread and I'll create a separate issue if requested.
So, wget is used to pull a JDK with JavaFX.
The workflow then calls ls and shows the .gz file, but during the setup-java action it says the file specified by jdkFile does not exist.
Am I correctly specifing the jdkFile?
This is the repository I am trying to use with Github Actions:
https://github.com/onebeartoe/java-libraries/commit/88b3fdc9b76dc6ba366773f75d6683dfc0142ef5/checks
martin-g commentedon Aug 19, 2019
One more vote for OpenJDK being an option!
Apache Wicket project tried GitHub actions but the build failed due to
strange behavior of Java 11. I've contacted Oracle to ask whether a bug fix from Java 13 has been downported to Java 11 and they explained to me that 11.0.2 is the last release by Oracle. Anything newer is from any of the other vendors and they (Oracle) have no idea what is included in it.More details about the problem and the discussion can be found at https://markmail.org/message/g5cbnw47kt7yrj7t
damccorm commentedon Aug 19, 2019
Whoops, sorry I missed this, for some reason my alerts for this repo got turned off 😳
I actually originally wanted to do this using OpenJDK, but ran into an issue that I couldn't find a good solution to. Basically the OpenJDK download urls aren't consistent and there's not a well defined distro. So for example, here are the Linux download urls for a some of the versions, pulled from here:
Everything below that would be downloaded from oracle, and I think we run into licensing issues there that make normal curl downloads challenging. I'm open to solutions there, but have concerns about anything that requires us to hardcode a bunch of urls and/or update every time a new version is released.
Note that if you need openJDK you can do this by doing something like:
That's a big part of the reason we kept the
jdkFileoption after we started downloading from Azul.martin-g commentedon Aug 19, 2019
Is it an option to
apt install ...it if the OS is Ubuntu ? Or the design is to always download & uncompress ?damccorm commentedon Aug 19, 2019
apt installis fine, but you can just do that from a command line script (aka you could do something likerun: apt-get install default-jdk).One of the main points of this repo is to stay platform agnostic so you don't need a different workflow for each OS.
ppalaga commentedon Aug 19, 2019
adoptopenjdk.net is nowaday's place to go for OpenJDK builds. They even offer an API that gives you access to all metadata and binaries you need https://api.adoptopenjdk.net/
ppalaga commentedon Aug 19, 2019
Here is the list of the platforms supported by adoptopenjdk.net in a human readable form: https://adoptopenjdk.net/supported_platforms.html
filiphr commentedon Aug 21, 2019
One other options of getting the java version could by by using https://github.com/sormuras/bach/blob/master/install-jdk.sh by @sormuras. It is quite powerful and allows downloading different JDKs
onebeartoe commentedon Aug 22, 2019
@damccorm, I tried using the jdkFile like you mentioned above.
But the build still gives a 'no such file' error and fails.
Here is the build:
https://github.com/onebeartoe/java-libraries/commit/6b75c16018a68416aa3c3be1ee171d6058c7ebc7/checks
Is there something missing there to use the jdkFile option for actions/java-setup?
damccorm commentedon Aug 22, 2019
@onebeartoe Huh, that's a surprising error - could you open a separate issue to track that? Would rather keep this conversation focused to offering openJDK since that's a separate topic 😄. I'm not 100% sure, but checkout might change the working directory - so maybe try running
lsafter checkout? Regardless, lets follow up in another issue, I definitely want to get to the root of that.Concerning the larger thread: I haven't had a chance to look into adoptopenjdk.net or https://github.com/sormuras/bach/blob/master/install-jdk.sh in depth yet, but am very open to using one of those/think we probably want something along those lines. At a glance, it looks like adoptoopenjdk.net offers cross plat linux/mac/windows support but install-jdk.sh only offers linux/mac, so I'm more inclined to use a solution that directly targets adoptopenjdk.net. If I'm missing something there please let me know.
onebeartoe commentedon Aug 22, 2019
@damccorm It turns out that checkout was clearing the pwd contents.
This is the bulid where I noticed:
https://github.com/onebeartoe/java-libraries/runs/200793085
So I moved the JDK download to after checkout. And here is the successfull setup-java using jdkFile.
https://github.com/onebeartoe/java-libraries/commit/07d31eb5ae0f9649ea29a552fc1ea9460de07b44/checks
Again I didn't meant to hijack this thread, and I didn't open a separate issue since I noticed what was going on with the order of the call to setup-java with jdkFile. Thanks
damccorm commentedon Aug 27, 2019
@stephenmichaelf probably makes sense for you to take this one. IMO we should do this using https://api.adoptopenjdk.net/
giltene commentedon Sep 27, 2019
Adding other JDK distribution options and letting people pick whichever they want may be a good idea. But I'd like to highlight that Zulu Community is a build of OpenJDK. Zulu is no more "vendor-specific" than e.g. AdoptOpenJDK is "IBM specific" (IBM sells support for AdoptOpenJDK builds).
Zulu is the longest-standing, free, 100% OSS build of OpenJDK available for Linux, Windows, and MacOS. It has a full, well-maintained, and uninterrupted history of having good, free builds of every single version of OpenJDK thru 6, 7, 8, 9, 10, 11, 12, and now 13, over the past ~6 years. This wide coverage and commitment to consistent delivery is why you can currently test Java CI on Github Actions for fixed versions like e.g. Java 7u181 (7.0.181), Java 8u131 (8.0.131), Java 9.0.4, and Java 12.0.2 Just by specifying their versions, and will be able to continue to do so uninterrupted side by side with various form of "latest" (11 or 11.0.x vs. 11.0.3).
The OpenJDK project is a source code project (and the OpenJDK name is trademarked by Oracle). All OpenJDK binaries come from some form of downstream curated builds of OpenJDK version distributions. Zulu is simply the longest standing one, and by far the one with the most builds and versions available and reliably maintained. But there are others (e.g. Corretto, Liberica, SAP machine, etc. which are TCK tested, and some others that are not). It's a happy, multi-distro world. Just like Linux. And the numbers of free OpenJDK distros seems to be growing and flourishing, which is a good thing.
That's why adding choices for specifying an OpenJDK distro (via e.g. "distro: zulu", "distro: corretto" or "distro: liberica", "distro: adopt", "distro: sap") is probably a good idea. We'd be happy to collaborate on that.
58 remaining items
maxim-lobanov commentedon Mar 15, 2021
@davidkarlsen , your proposal makes sense to me and looks like it won't be a breaking change since we default new property to true by default.
We are okay to include these changes to
v2. I have left a couple of comments in #82 . Could you please rebase your branch based onv2-previewbranch and re-target pull-request (I guess you will have a ton of conflicts)?If you don't have a time - we will adapt your PR for v2 in a few days.
davidkarlsen commentedon Mar 15, 2021
@joschi could you rebase #82 again - seems like it can be picked up for real this time...
maxim-lobanov commentedon Mar 16, 2021
@davidkarlsen , @joschi , I have prepared PR from my side because moving changes to V2 can be tricky (hope you don't mind): #136
davidkarlsen commentedon Mar 16, 2021
@maxim-lobanov no prob - it's not my PR - I just need the feature :-) Nice to see it moving forward.
joschi commentedon Mar 16, 2021
@davidkarlsen Go ahead, please. 😃
maxim-lobanov commentedon Mar 17, 2021
#136 was merged.
You can test it right now:
We are going to release v2 stable by the end of next week but we would be very appreciate for any testing of
v2-previewand confirmations that it works as expected with bothadoptandzuludistributionsdavidkarlsen commentedon Mar 18, 2021
@maxim-lobanov tested - it works fine!
MarcelCoding commentedon Apr 5, 2021
Are there any plans to add
adopt-hotspotandadopt-openj9, to be able to also select the implementation and not only the vendor?maxim-lobanov commentedon Apr 5, 2021
Hello everyone!
We have just released setup-java@v2 with support of Adopt.
You can start using it via the following code snippet:
Please find more details in repo readme.
maxim-lobanov commentedon Apr 5, 2021
@MarcelCoding , no plans for now but I think it is something that we can consider. Feel free to create a feature request
MarcelCoding commentedon Apr 5, 2021
I've created one: #155
dmitry-shibanov commentedon Apr 7, 2021
Hello everyone. On Monday 5th April we released
setup-java@v2and also resolved some other issues related tosetup-java@v1inv2. Now task supports to setupAdoptOpenJdkin addition toZulu'sdistribution. It can be done through required distribution field. For detailed explanation you can see migration guide fromv1tov2and advanced usage forsetup-java@v2. If you face up with strange or unexpected behaviour feel free to create separate issue.zygisk-topjohnu commentedon Jul 29, 2022
update