java.lang.module.ModuleReference

[forax at univ-mlv.fr]

Hi Alan, hi Andrew,
i think i know why, it's a security feature,
if ModuleReference is an abstract class, you can guarantee that all implementations will have a location (and a descriptor) non mutable and because ModuleReference is not in an open module, you can guarantee that nodoby will be able to change the final fields that store the location (and the descriptor).

Rémi

----- Mail original -----
> De: "Andrew Dinn" <adinn at redhat.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Alan Bateman" <alan.bateman at oracle.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Samedi 7 Janvier 2017 20:00:21
> Objet: Re: java.lang.module.ModuleReference

> Hi All, Hi Alan, Hi Remi,
> 
> I'm clearly only one short step behind Remi. I also just ran into this
> change with Byteman-4.0.0-BETA1 (which works with jdk9-b148 but breaks
> on jdk9-b151). I'm assuming that an implementor of ModuleFinder is
> expected to subclass ModuleReference, profit from the protected
> constructor to set the descriptor and location then implement their own
> open() method to make the Reader behaviour available. I don't see how an
> interface could do that.
> 
> I'll be pushing a Byteman-4.0.0-BETA2 release to maven central as soon
> as I can get a working version packaged up.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 
> On 07/01/17 15:10, Remi Forax wrote:
>> Hi all, hi Alan,
>> i'm slowly updating all my codes to the jdk9b151 and i've discovered that
>> ModuleReference is now an abstract class.
>> 
>> I see no issue with making it abstract, but why an abstract class and not an
>> interface,
>> i thought we have all decided to stop to use public abstract classes after Java
>> 8 :)
>> 
>> regards,
>> Rémi