JDK 15 hidden classes & stack trace visibility

Uwe Schindler uschindler at apache.org
Mon Sep 7 18:39:13 UTC 2020


Thanks Mandy.

In my opinion for the hidden classes an additional enum constant in ClassOption would be fine: ClassOption.SHOW_IN_STACKTRACE (or similar).

That would be simplest to implement and allows also for the caller to enable it like strong references or nestmate features. So it's consistent with the other API parts.

The annotations are good for fine granular   hiding (like complex classes recursively calling methods). Or for frameworks like Spring.

Should I add a comment to this issue?

We are now doing some testing in Lucene's expressions module (it's about scoring formulas in query execution). Here's the draft PR: https://github.com/apache/lucene-solr/pull/1837/files

We use the new features in Lucene when the static initializer detects defineHiddenClass using a publicLookup.

Currently a test fails, because of missing debug information in stack traces. The executed scoring formula is part of the filename attribute in class file. As this is missing, test fails. ��

Uwe

Am September 7, 2020 4:44:18 PM UTC schrieb Mandy Chung <mandy.chung at oracle.com>:
>Hi Uwe,
>
>It's a future enhancement to allow a class/method to request filtering 
>from stack trace:
>     https://bugs.openjdk.java.net/browse/JDK-8212620
>
>This RFE should also take hidden classes into account.
>
>Mandy
>
>On 9/5/20 4:55 AM, Uwe Schindler wrote:
>> 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?
>>
>> Uwe
>>
>> -----
>> 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