Re: [jetty-dev] latest NPN and start.jar

[Eirik Bjørsnøs <eirbjo@xxxxxxxxx>]

> How hard would it be to go from the source code patching we do today into a
> runtime byte code weaving approach?

Very very very hard.

Fair enough, let's not go there then :-)

 

Been there, done that.
The answer from the OpenJDK leaders was that this was not possible before JDK 9.
So we're stuck with what we have.

You're referring to this thread?:

http://openjdk.5641.n7.nabble.com/Next-Protocol-Negotiation-TLS-Extension-td123744.html

 

You request here is from what I can tell a TLS extension API. I was thinking more along the lines of suggesting some refactoring to Oracle which would make maintaining the patch easier and make runtime weaving somewhat less impossible. But from what you said I guess maintaining the patch is not all that hard, so probably not worth it then.

I am all for improving, and likely your suggestion of using the Attach
API will be implemented, but the current solution is the lesser of all
evils, AFAICT.

Even without using the Attach API, I'd say using -javaagent is still better than -Xbootclasspath. It allows us to move the choice of NPN version to runtime, when we actually know what we're running on. 

Without an API (or weaving that works) we won't get a future proof solution that works behind the firewalls. 

Using the agent approach, the message could be 

    "make sure you're using the latest available non-boot jar"

instead of the slightly stricter message given today, which is 

    "make sure you know exactly which update of the JVM you're using, then look up in our documentation which version of NPN-boot you need to go with that".

I think the first message is easier to parse and easier to follow.

Eirik.