Valhalla super class/interfaces and bridges

[Remi Forax]

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