JDK 15 hidden classes & stack trace visibility

Remi Forax forax at univ-mlv.fr
Sat Sep 5 23:18:35 UTC 2020


Hi Uwe,

----- Mail original -----
> De: "Uwe Schindler" <uschindler at apache.org>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Samedi 5 Septembre 2020 13:55:03
> Objet: JDK 15 hidden classes & stack trace visibility

> Hi,
> 
> I am doing a mockup for dynamically compiled scripts in Apache Lucene (later
> also painless scripting in elastcsearch), where I tried to use
> Lookup#defineHiddenClass (with default parameters, so weak and no nestmates
> - but: for painless scripts of Elasticsearch, nestmates will be great). It
> all looks great, as sometimes for every query a new class is generated.
> 
> The current approach (Java 8, Java 11) uses a Classloader per script, which
> is mostly OK, but hidden classes would be better, especially under high load
> with many new classes. The problem I see is: The hidden class and their
> methods are also hidden from stack traces, so people neither get the script
> source code reference, nor they get the method, which was called at all.
> 
> My question is: is it possible to mark such a hidden class in byte code or
> by a flag to defineHiddenClass() so it is "unhidden"? - I know you can do
> this by a command line option, but that's for developers and debugging only.
> In some cases, this is really wanted (like for scripting languages), but
> code still wants to use the better class unloading. If this is not possible,
> how about extending the Lookup.ClassOption enum (last parameter of
> defineHiddenClass), to also pass a flag to show them in stack traces?

If you don't want a hidden class, why not using Lookup.defineClass() for 11 and calling ClassLoader.defineClass() by reflection in 8 ?
With defineClass you get a resolvable real name and methods are visible in the stacktrace.

Obviously, it means that you are grouping several classes in the same classloader which may be not what you want.

> 
> Uwe

Rémi

> 
> -----
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> https://lucene.apache.org/


More information about the core-libs-dev mailing list