fix: add Java 25 as minimum JVM version when using compact source files

[wfouche]

Closes #2142

[maxandersen]

this is not symmetric fix - what if user chose a different java version?

the logic here is that if you run init with Java 25+ wehter available or chosen we generate for that - if anything it should generate //JAVA but its not something we can do reliably.

[quintesse]

But isn't it true that it should be at least Java 25? Otherwise it just won't work, right?

[wfouche]

Without //JAVA 25+ the generated code does not run on a system with a default JVM of version 24 or less.

If a JVM of version for example 26 is installed, then it will be used to run the script because it matches the JAVA specification of 25+.

Maybe not a perfect solution, but it is better than not having //JAVA 25+.

[maxandersen]

It also works on java22 with preview flags.

I'm just saying we also don't add java 17 when deps require java 17... Should we ?

I'm not super against it but just saying until now we haven't explicitly added //JAVA unless explicitly user asking for it.

[wfouche]

I'm happy to abide by what you decide.

[quintesse]

It also works on java22 with preview flags.

The compactSourceFiles is only true for Java 25+

I'm just saying we also don't add java 17 when deps require java 17... Should we ?

Do we have templates that use deps that require Java 17? Then I would say yes we should. But only if we have templates where we have explicitly added those deps. I'm not suggesting we should do any detection or anything. Only straightforward things like have templates or examples where we know the minimum version required.

until now we haven't explicitly added //JAVA

Until now we haven't used any special Java features in our templates, haven't we? In some of our examples we do, but AFAIK those have //JAVA lines.

[maxandersen]

No, but we also never added additional flags for your environment. we only do it when some explicit ask.

Like I would expect if I do jbang init --java 25 test.java that it put //JAVA 25 but not if i'm running with java 25 by default and do jbang init test.java ....and if we do should it not use //JAVA 26+ if I put jbang init --java 26+ hello.java ?

[maxandersen]

lgtm - though i'm not a fan adding lines which aren't needed by default ;)

[quintesse]

and if we do should it not use //JAVA 26+ if I put jbang init --java 26+ hello.java ?

Yes, probably. Still, I'm not saying we should just go add this to templates, but I can imagine that the templates we provide do this, yes.

[wfouche]

The turtle.java example program specifies the Java version as

//JAVA 25+

in PR jbangdev/jbang-examples#14. Is that not enough reason to accept the current PR as specified?

[maxandersen]

the examples are different in the sense they are pretty static in point in time and can put it when its needed.

I would have it much better with this PR if it added the requested java version if/when available so it would not be tied on java 25.

which reminds me another reason why i'm hesitant to add this - the whole point of the naked mains is that it requires less code - and we then adding the /// root jbang line + //JAVA 25+ feels like unnecessary noise for newbies to me.

[wfouche]

OK, then I think it is best to close this pull request and call it a day. Was a good discussion.

[quintesse]

//JAVA 25+ feels like unnecessary noise for newbies to me.

A newbie running a source file like this without the //JAVA 25+ line will be even more surprised and will have no idea why it doesn't work.

I would say it's very useful now, when 25 is so very new that not many people will be running it. And then in a couple of years we could remove the //JAVA line when we assume most people will be running modern Java versions.

we then adding the /// root jbang line + //JAVA 25

I'd rather remove the /// line than the //JAVA one :-)

[maxandersen]

newbie wont get that line unless he actually runs that init with java 25.

as said, i'm fine adding it but we should be adding the actual requested java version not hardcode it to 25.

[quintesse]

newbie wont get that line unless he actually runs that init with java 25.

That's assuming the user is creating the file themselves. If it's created by someone else and then added to a GH repo it's anyone's guess what JDK users will use to try to run it.

Which, to me, means that to make life easy on people you should always use a //JAVA line when using features that are newer then Java 8. It encourages a way of working with JBang that "it always just works".

as said, i'm fine adding it but we should be adding the actual requested java version not hardcode it to 25.

but it depends on the feature! if somebody used a Java 25 to run jbang init (no --java!) by default they get this new code. My contention is that the code we generate should always run, for any user using any JDK, without them knowing anything about Java features and versions.

It's the developer that wrote the template that knows that this specific feature needs 25+ and therefore they should add that version explicitly, always.

[maxandersen]

I'm not disagreeing but I'll argue that if you put 'jbang init --java 26 herewego.java' it's a big if we then put //JAVA 25+ and not //JAVA 26

[quintesse]

True, but I'm not sure --java 26 is generally implementable anyway? Either we go poking the //JAVA line in the generated code somewhere ourselves, which is doable of course but seems a bit hacky (but if we do that we could certainly also detect that a //JAVA line already exists and simple edit it). Or the developer of the template would have to add a section like:

{#if javaVersion}
//JAVA {javaVersion}
{/if}

But that means that if the template developer did not add this section then the --java option doesn't do anything, which also isn't ideal. (Between the two the former is probably preferable even though I'm not a fan of poking extra lines in source files. Personally I guess I just wouldn't support --java at all)