java9 : concise try with resource

[glelouet]

Java 9 added more concise try-with-resource, allowing to use an existing variable to be closed as a resource.

AutoCloseable ac;
try(ac){}

This PR adds the following

JTryResource reuse

Add the private final boolean reuse to JTryResource. When set to true on constructor, the internal JVar is generated instead of variated upon the jresource's generation.

A constructor from an existing jvar is added, that sets that field to true. previous constructors now set it to false.

Syntaxic sugar methods

Add 3 withResource(…) sugar methods in JTryBlock. Those methods directly call the different constructors for JTryResource and add the new constructed jresource internally.

The 2 methods that create a new JVar return that new JVar, the one that reuses an existing jvar returns this to allow chaining.

Minimal tests

A single minimal test is present, ready to be extended for specific issues.

[phax]

Switching to Java 25 as the baseline is currently not an option. Java 17 needs to stay the baseline - sorry.

Edit: this also refers to the Switch-statement PR which moves to Java 21

[glelouet]

Switching to Java 25 as the baseline is currently not an option. Java 17 needs to stay the baseline - sorry.

Edit: this also refers to the Switch-statement PR which moves to Java 21

Well that would have been nice to say before I started working on the switchexpression, which are, regarding their pattern matching part, a java21-requiring feature.

I can't test code generating java21 feature without java21.

That being said, this PR is only one commit and java9, should be appliable to the master by cherry picking it.
So the "java17 only" requirement is only relevant to the switchexpressions (j21), unnamed(j22), compact source&main(j25)

Also, in the current state, we just can't build j25, for the reason I mentioned in the switchexpression PR (method deprecated and replacement does not exist in j17).

[phax]

What we could do, is to create a special "submodule" that is using Java 25 only and we can make it differentiable via Maven profiles - Will have a look at it in the switch expression PR

[glelouet]

What we could do, is to create a special "submodule" that is using Java 25 only and we can make it differentiable via Maven profiles - Will have a look at it in the switch expression PR

Yeah, that was one of the solution I explained in the switchexpression.

I don't think this is relevant to this PR though.

This PR, just like the licenses one, is deadbrain simple so IMO you should let switchexpression for later and focus on the easier, older, more energy-efficient ones .

[phax]

Well the switchexpression is the old one :-) The BOM one is postponed - and to my understanding the other ones build on top of that one

[glelouet]

No, I base on my changes to avoid merge conflict.

https://github.com/phax/jcodemodel/pull/139/commits based on master.

[glelouet]

@phax I force-pushed this one to have only the relevant commit. Changing first post.