Hello all,
I'm trying to implement the parametric VM spec and i think there is an issue
with the compatibility of classes that contains a bridges.
But first, the issue, because of separate compilation, it's possible to have
one class implementing the same interface parametrized with different
parameters.
By example, those classes are compiled together
class A implements I, J {}
interface I {}
interface J {}
Then 'I' or 'J' are modified and re-compiled later
interface I extends Comparable<String> {}
interface J extends Comparable<Integer> {}
and 'A' can be re-compiled to see either 'I' or 'J' modified.
If 'I' is modified and 'A' is re-compiled, 'A' contains a bridge
compareTo(Object) -> compareTo(String) and if 'J' is modified and 'A' is
re-compiled, 'A' contains a bridge compareTo(Object) -> compareTo(Integer).
In fact, a bridge is a witness of a specialization of the interface at the time
of compilation.
There are two issues:
- a class can have the same interface with several different specializations,
obviously, if the code was compiled with everything together, it will not
compile, but due to separate compilation,
this is an issue.
- a class can contain a bridge even if the interface it depends on is not
specialized anymore.
The questions is what we should do in those cases, given that i think that we
should not try to have a different semantics than the existing one. By example,
throwing an error at runtime if there are two specializations of the same
interface seems a bad idea.
One interesting idea is that if the compiler generates a bridge, it should also
record the specialization that generates that bridge in a side table, so the
decision to generate a bridge at compile time is available for the parametric
VM at runtime.
regards,
Rémi
