Integrate Fernflower decompiler into Quarkus build of fast-jar #15162
Conversation
| @@ -667,6 +700,56 @@ public void accept(Path path) { | |||
| return new JarBuildItem(initJar, null, libDir, packageConfig.type, null); | |||
| } | |||
|
|
|||
| private void downloadFernflowerJar(PackageConfig packageConfig, Path fernflowerJar) { | |||
| String downloadURL = String.format("https://jitpack.io/com/github/fesh0r/fernflower/%s/fernflower-%s.jar", | |||
There was a problem hiding this comment.
Is there a reason we download it rather than making it a build dependency?
There was a problem hiding this comment.
My reasoning is that this is super unlikely to be used by regular users, so there should be no reason to make it an explicit dependency.
There was a problem hiding this comment.
I see it's not on Maven Central but maybe we could ask nicely?
There was a problem hiding this comment.
Was going to mention that as well.
For the time being it's only available on Jitpack because some fellow forked the Jetbrains repo and configured Jitpack.
I'll open an issue on the Jetbrains tracker to see if we can get it into Maven Central
There was a problem hiding this comment.
It's a bit more complicated than that. We had quite a lot of corporate users complaining it's hard to download things outside of Maven Central. So downloading from Maven Central is usually the way to go. Not sure downloading it always would be a big issue given how many artifacts people get to download to do a build. But I have no idea how big it is.
There was a problem hiding this comment.
Also with Maven, you get signature checking, automatic updates with Dependabot and so on.
It's not on Maven atm so we can't really do anything about it but maybe we could ask?
There was a problem hiding this comment.
Yup, I did just that in https://youtrack.jetbrains.com/issue/IDEA-262376
There was a problem hiding this comment.
But I have no idea how big it is.
For the hash I have used, the jar is around 600kB
There was a problem hiding this comment.
I was going to suggest making this default to true if the current user is stephane, but that jar thing looks like an attack vector :-/
core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/JarResultBuildStep.java
Outdated
Show resolved
Hide resolved
core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/JarResultBuildStep.java
Show resolved
Hide resolved
geoand
force-pushed
the
#612
branch
4 times, most recently
from
67dbb66 to
ea66351
Compare
This makes it easy for Quarkus developers and extension authors to see the bytecode that Quarkus produces Fixes: quarkusio#612
|
The gradle failure is the same seen in other PRs, it has nothing to do with this PR |
Good question! I don't really know where that is...
It's the decompiler IntelliJ uses and in all my experience with it and Quarkus, I have never opened a class file produced by Quarkus in it and not see a meaningful result. |
|
Can I get a review of this please? Thanks :) |
|
So OK, not really the same thing as your PR. But we should really do something with it more generally because that's damn useful for devs. |
Ah, right! We should definitely expand on it! |
|
So, if I am developing an extension and I fuck up my bytecode, with invalid ASM or even gizmo (invokevirtual instead of invokeinterface happened to me yesterday, though I don't expect that particular issue to crash a decompiler). What is the behaviour of this plugin? Does it crash or fall back to printing bytecodes or what? |
|
It never crashes. In the worst case a It is also smart enough to limit this to a specific method if the bytecode is part of a method - the rest of the class should be decompiled properly (or at least that is what I have seen in practice) |
This makes it easy for Quarkus developers and extension authors
to see the bytecode that Quarkus produces (both generated and transformed)
Fixes: #612