Core Type Compilation Issues

[Peter Levart]

On 08/15/2018 07:16 PM, Peter Levart wrote:
>
>
> On 08/15/2018 05:49 PM, dalibor topic wrote:
>>
>>
>> On 06.08.2018 20:21, mr rupplin wrote:
>>> Three problems that I run into when running the 'make jdk' after 
>>> minor work on the System.java class for JNI and custom JDK:
>>>
>>> java/lang/memory/GroupListener.java:111:
>>>
>>> Can we get explanations for each of these? 
>>
>> No.
>>
>> There is no java.lang.memory in OpenJDK. So it looks as if you are 
>> not using OpenJDK, you're using something else.
>
> Or Mr. Rupplin is adding class GroupListener to OpenJDK, thus creating 
> new package java.lang.memory.
>
> In that case I would suggest adding the class to some existent jdk 
> internal package of java.base module below the jdk.internal. package 
> hierarchy (java.lang. hierarchy is reserved). But as David Holmes 
> already suggested, if this class depends on java.rmi classes, it may 
> not be located in java.base module if it wants to access these classes 
> directly from compiled code. OTOH it must be located in java.base 
> module if it wants to be used from java.lang.System class (which I 
> suspect Mr. Rupplin is doing from his message mentioning work on 
> System.java class). It is possible to access java.rmi classes from 
> java.base module using reflection though. Or better yet, using 
> ServiceLoader mechanism.
>
> So I would suggest Mr. Rupplin to:
> - define a jdk internal service interface for the minimal 
> functionality needed from java.rmi module in the java.base module.
> - implement this interface by a concealed class in the java.rmi module 
> and provide the service by adding "provides" directive to 
> module-info.java of the java.rmi module
> - declare that java.base module "uses" the service (in the 
> module-info.java of the java.base module)
> - code the logic in java.lang.System or helper class by loading the 
> service using ServiceLoader API - the logic should be prepared to not 
> find any such service since java.rmi module may not be present at runtime
> - service interface and any additional utility classes such as 
> GroupListener in java.base module should be put into existent (or new) 
> jdk internal package(s) below the jdk.internal. package hierarchy.
> - the package containintg the service interface should be exported to 
> java.rmi module only that provides the implementation of the service
>
> Hope this helps,
>
> Regards, Peter
>

The big question for Mr. Rupplin is why does he want to put the logic 
that uses java.rmi module into java.lang.System class (or API). Wouldn't 
such logic (or API) belong to java.rmi module and shouldn't Mr. Rupplin 
extend its API instead? Some explanation about the intentions would help 
suggest the right approach.

Peter