In my research article on kinds (and my dissertation), I have proved sufficient conditions for abstract interfaces to be sound. They are hard to explain, so I was looking for a simpler condition that implied the real one. I made a mistake in thinking that the locality restriction was a good candidate. But as Martin said, it is restrictive, and as Arjan shows it is not even safe! When I get the time, I will get back on this, implement a safe condition, and hopefully it will not be restrictive in practice.

-- DanielBonniot - 30 Apr 2003

Currently it's not allowed to extend a AI from another package. But that's annoying restriction and worse it doesn't solve the problem because you can bypass it.

package b;
abstract interface foo2 extends a.foo {} // BYPASS
class javax.swing.JComponent implements foo2;

void main(String[] args)
{
  JComponent jc = f(new JTable()); // BOUM!
}

Can restricting some kinds of polymorpic return types of AI methods be a solution to this problem ???

-- ArjanB - 24 Apr 2003

%META:TOPICINFO{author="ArjanB" date="1051224074" format="1.0" version="1.1"}% %META:TOPICPARENT{name="NiceSwing"}% The problem of non-local AI is a very complex one, so you cannot expect it to be modified soon. We have to tackle with it. Here is a justification that I cannot allow non-local AI implementation:

package a;
abstract interface foo { alike f(); }
class java.awt.Component implements foo;

f(x) = x;
f(x#javax.swing.JComponent) = new java.awt.Button();

package b;
class javax.swing.JComponent implements a.foo; // ILLEGAL

void main(String[] args)
{
  JComponent jc = f(new JTable()); // BOUM!
}

Imported from email dicussion with DanielBonniot

-- MartinGamsjaeger? - 30 Oct 2002