[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.
Maurizio
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?)
>
More information about the amber-spec-observers
mailing list