Rename the Vineflower properties ?

[agoncal]

Description

In previous versions of Quarkus, to get the decompiled code, we had to set the Fernflower property:

quarkus.package.fernflower.enabled=true

Since Quarkus 3.6, Fernflower has been dropped, and instead it uses Vineflower with the following properties:

quarkus.package.vineflower.enabled
quarkus.package.vineflower.version
quarkus.package.vineflower.jar-directory

This being an implementation detail, the property is not very easy to find. What about renaming it with decompile or something like that ?

Implementation ideas

No response

[gsmet]

I'm a bit undecided on it. I can see why you would want that but then we would have a hard time making sense of quarkus.package.vineflower.version?

Maybe we should have some generic options to enable the decompiler (I would go with quarkus.package.decompiler.*) that most people would use as they don't care about the tool and some advanced options specific to the decompiler (e.g. quarkus.package.vineflower.version).

Now not sure it's worth the bikeshedding, I will let @geoand decide.

[quarkus-bot]

/cc @Sanne (core), @aloubyansky (core), @geoand (core), @radcortez (core), @stuartwdouglas (core)

[agoncal]

It was @maxandersen who asked me to create an issue.

As you pointed out, it's not a big of an issue. But for some advanced case, finding the property fernflower and now vineflower is tricky. You really need to remember it. And in the future you change the implementation to sunflower or yetanotherflower you would have to change the property name.

And what about ?

quarkus.package.decompiler.enabled
quarkus.package.decompiler.vineflower.version
quarkus.package.decompiler.vineflower.jar-directory
quarkus.package.decompiler.fernflower.version
quarkus.package.decompiler.fernflower.jar-directory
quarkus.package.decompiler.sunflower.version
quarkus.package.decompiler.sunflower.jar-directory

[geoand]

I can see why you would want that but then we would have a hard time making sense of quarkus.package.vineflower.version

That's exactly why I had a specific version.

However, it turns out it never needs to be changed, so the decompiler name is almost always useless - not to mention harder to type.

In retrospect, I should have used the simple name proposed here and not doing it only added confusion.

So +1 for the change

[mkouba]

+1 for quarkus.package.decompiler.enabled, quarkus.package.decompiler.jar-directory and removing the version completely.

I wonder if it would make sense to support different decompilers though. Probably not.

[gsmet]

I wonder if it would make sense to support different decompilers though. Probably not.

I wouldn't spend time on that except if there is a very good reason for it.

[maxandersen]

Can we avoid break users again by removing properties :) just have décompiler.enabled and let the others be the default value?

[geoand]

Yeah, I intend to have a transition period

[geoand]

I am going to do what @mkouba suggests and simplify and just remove the version configuration property altogether as there is very very little use in setting it. I'll only keep enabled and jar-directory.

For now, I'll allow both quarkus.package.decompile.* and quarkus.package.vineflower.*

[geoand]

#37445 takes care of it