JEP 463: Implicitly Declared Classes (Second Preview) - Draft Spec Clarification

[Leonid Arbuzov]

Hi Ron,

 > I think the most complete solution is for the JCK in such a case is 
to require the implementation to provide some script that compiles the 
source file and returns the class name of the top-level class that could 
then be used for launching

Great idea. The approach might work. Let us think more in that direction.

> ...OR a script that compiles and then immediately runs the file.

The JCK runs compiled classfile with a reference JVM not with a tested 
JVM. Not a problem: the JCK handles those steps.

Thanks, -leonid

On 11/28/2023 11:05 AM, Ron Pressler wrote:
>
>> On 28 Nov 2023, at 18:59, Leonid Arbuzov<leonid.arbouzov at oracle.com>  wrote:
>>
>>> Alternatively, the JCK could rely on the following from the new spec (although I don’t know to what extent that’s allowed):
>> Yes, the JCK can use that typically generated class names. This might work for the most Java SE implementations. Original question was what should the JCK do for those non-typical implementations? The JCK can ask an user to provide a custom converter (source name to class name).
>> But this would not work for implementations that generate class names indeterministically. Hopefully there will be none or a few of such ones and the JCK can run a weaker tests for them. But a concern was that JCK users would be allowed to choose to run those weaker tests...
>> Can the spec somehow close this option? Or the JCK can close it on its own?
> I think the most complete solution is for the JCK in such a case is to require the implementation to provide some script that compiles the source file and returns the class name of the top-level class that could then be used for launching OR a script that compiles and then immediately runs the file.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231128/fe0e009f/attachment.htm>