BTW. SVN uses bdb to store your files, so the names are OS independent (i.e. SVN server on Windows can still handle FOO and Foo).

The solution I found for this was to have the Windows users check out the whole module from scratch again.

Later on, when other people checked out that file, their local SVN client got stumbled on it - apparently, it didn’t DELETE the old file when I renamed it, so it tried to check out Both types of files (”concreteClass” AND “ConcreteClass”) and since they were using Windows computers it just didn’t work. Obviously it didn’t give a reasonable error to find why it was getting stuck but luckily we managed to deduce it was due to these two filenames with conflicting names under Windows (Our SVN repository is kept on a Unix machine so it had no problem keeping the files like that itself.)

Phew. Longer response than I thought it would be.

The reason intersection types are not implemented for direct use is in the way the JVM works, and Java 5 is chosen to be implemented. Currently, there is no special runtime type to represent intersection type, it’s always compiled as the erasure of its first bound.

Implementing it in a different way most probably requires some changes in the JVM and/or generation of synthetic classes. From a number of reasons it was a change the Java architects wanted to avoid. But, who knows? Maybe future versions will support that?…

P.S. Thank you for formatting my previous comment, but there are still some incompleteness in my code caused by a replay form.

In my original example a reference holder was declared as:

public class ListRef<T extends List<String> & RandomAccess> {
    public final T value;

    public ListRef(T value) {
        this.value = value;
    }
}

Example method implementation as:

public ListRef<?> foo() {
    return new ListRef<ArrayList<String>>(new ArrayList<String>());
}

And sample use snippet as:

ListRef<?> listRef = foo();
List<String> list = listRef.value;
RandomAccess ra = listRef.value;
...

public class RandomAccessListDelegate<E, T extends <List<E> & RandomAccess> implements RandomAccess, List<E> {
  private final T delegate;
  private RandomAccessListDelegate(T delegate) {
    this.delegate = delegate;
  }
  public static <E, T extends <List<E> & RandomAccess> RandomAccessListDelegate<E, T> create(T delegate) {
    return new RandomAccessListDelegate(delegate);
  }
  public T getDelegate() { return delegate; }
  // Delegate all methods to delegate
  // [code snipped]
}

Still, I shouldn’t have to jump this hoop.