[sealed] Changes to type system

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Feb 25 17:30:19 UTC 2020

I agree that we can leak types in other circumstances - I'm not sure 
that the potential for source compatibility breakages is the same though.


On 25/02/2020 14:22, Brian Goetz wrote:
> Don't we have a similar problem with non-accessible supertypes and 
> inference?  If I have:
>     private abstract class A { }
>     public class B extends A { }
>     public class C extends A { }
> Won't I infer LUB(B,C) = A, rather than Object?
> On 2/25/2020 6:08 AM, Maurizio Cimadamore wrote:
>> But if that's the case, I have to admit that I find it a bit awkward 
>> that I can use javac to probe sealed interfaces to see which might 
>> share a common implementation class, even if that implementation 
>> class is out of my reach and hidden behind module boundaries. In 
>> other words, while with the rules we have now, the user can always 
>> "see" why a cast has succeeded or fail, with these new rules, 
>> sometimes a cast can (statically) be rejected or not depending on 
>> details which might be unavailable to the site where the cast 
>> operation occurs. I wonder - should javac "stop" looking, and avoid 
>> descending into subtypes which are not visible from the use site 
>> (e.g. consider A and B as completely disjoint in the example above, 
>> if the cast occurs outside M?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200225/51af7197/attachment.htm>

More information about the amber-spec-experts mailing list