search

flathub / flathub

Issue tracker and new submissions
https://docs.flathub.org/docs/for-app-authors/submission
GNU Lesser General Public License v2.1
1.15k stars 2.17k forks source link

Volunteering to be a collaborator on newer Java SDKs #5726

Closed guihkx closed 4 weeks ago

guihkx commented 1 month ago

I was recently given the collaborator role on Java SDKs versions 8 and 11, and I believe they are in a better shape now.

There are 3 other Java SDKs that I believe could use some care as well:

https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk17 https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk21 https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk

Though they aren't outright abandoned, given the amount of unreviewed PRs on some of these repositories, I think it's fair to say maintainers have been a bit busy...

So, if Flathub admins agree with my reasoning, feel free to add me as a collaborator on those repositories as well. Otherwise, feel free to close this.

bbhtt commented 1 month ago

@jakobjakobson13 any objections for openjdk and openjdk21?

jakobjakobson13 commented 4 weeks ago

I don't use java or work with it. Therefore, I won't be able to spot any bugs in the package apart from the packaging side. So I'm not sure if I am the right fit.

bbhtt commented 4 weeks ago

Looks like I pinged you by mistake

@tsmock and @Zishan-Rahman any objections to adding @guihkx?

Zishan-Rahman commented 4 weeks ago

Looks like I pinged you by mistake

@tsmock and @Zishan-Rahman any objections to adding @guihkx?

@bbhtt (sorry for the pings) No objections from me! It'd be nice to have another maintainer available when I'm not. And yes, I have indeed got busy recently 😅

tsmock commented 4 weeks ago

No objection from me either. You should be aware that I've been meaning to split the package up a bit (specifically into OpenJDK, ant, maven, and gradle packages; at some point in time, I also want to make a JRE runtime for applications that are distributed as jar files).

TBH, updating ant, maven, and gradle aren't high priority for the package. gradle is especially problematic since they like to break things every major revision (which is much more frequent than maven or ant breakage).

bbhtt commented 4 weeks ago

Added

guihkx commented 4 weeks ago

Thank you all!

@tsmock: I'll keep the things you saaid in mind!

I also want to make a JRE runtime for applications that are distributed as jar files).

That's interesting. I might be misremembering, but I think that was discussed in the past (whether to add a Java runtime or extension), but I don't remember why that wasn't done.

But I'm curious about your reasons.

tsmock commented 4 weeks ago

I wasn't around when it was decided not to add a Java runtime/extension, but here is my reasoning:

  1. Most applications are fine with a range of Java versions (the Java application I maintain supports Java 11+)
  2. For applications that are distributed as a jar, it may or may not make sense to try and run jlink/jpackage on it -- again, for the application I maintain, it supports plugins which may need arbitrary parts of the JRE, so a "minimal" JRE for it is a significant percentage of a full JRE.
  3. A new vulnerability is discovered in the JRE. What is easier? Updating the JRE or updating all the applications? Note that the install.sh script basically copies the JRE for each app individually. Things are a bit different if the packager made a minimal JRE using jlink or jpackage.