Avoid building a URI again and again in JarResource

[gsmet]

@franz1981 could you have a look at this change? It's related to #39447 .

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 0354c98.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[franz1981]

now checking @gsmet!

[franz1981]

adding @geoand too which is the one who wrote this one

I'm mostly checking there's some evident performance reason why it shouldn't be the same (which doesn't seem the case , at a first look)

[gsmet]

Shouldn't be the same as what?

[franz1981]

I mean, it should be the same as it was before (from a semantic perspective), but i'm double-checking if there is any performance unexpected reason to not be the same (or better)

[franz1981]

So, in theory JarResource::init happens just once at

quarkus/independent-projects/bootstrap/runner/src/main/java/io/quarkus/bootstrap/runner/SerializedApplication.java

Line 165 in c25f1db

classLoadingResource.init();

, meaning that there's not reason to cache URI jarUri as instance field and can just chain jarPath.toUti().toURL() on it, to save retaining more heap and necessary and let URI to be Gc'd.
I'm now checking if the allocated bytes are the same for the 2 methods.

[gsmet]

Have you looked at the call I removed? Because that was the whole purpose of this patch. Removing a call that we do a lot of times for the config stuff.

[franz1981]

uh @gsmet !

you mean https://github.com/quarkusio/quarkus/pull/39508/files#diff-49c6546297493b873346e7eb56a6f56a84964d13075679c56497b739674a97a0L113 ?
good point, I've missed it!

[franz1981]

TLDR for the getting-started quickstart I cannot see any measurable difference, because it seems getResourceURL is called just 9 times (i've attached the profiling data both for allocation(s) and number of times the method is called and where)
profling_data.zip

The reason why the concat indy was visible, is that just a single call can trigger bytecode generation there, and that's why it was worthy to be fixed

Said that I'm all in to simplify the existing code path anyway, unless @geoand got some reason why it was like that; which I'm not very familiar with

[gsmet]

OK, well, if it doesn't bring anything to the plate, we can close this.