abstract static methods (again)

I have searched this group for "abstract static methods" and found a
couple of threads, but I think none of them was discussing the kind of
semantics I am going to describe. As you might have guessed, I believe it
would be useful :). I further believe it is fully complatible with the
current language, but there might be caveats I have overlooked. I'm
wonder if you would find it as useful as I do and if you see any problems
with it. I know it is a long post and some parts may be difficult to
understand. Therefore I will be thankful if you can read it all and think
about it.

By "abstract static method" I refer to either a static method in an
interface or an abstract static method of an abstract class.

Put shortly, a declaration of an abstract static method in interface J
(resp. in abstract class A) would mean that any class implementing J
(resp. extending A) must either provide its _own_ implementation of that
static method, or itself be abstract.

Note 1: There would still be no inheritance of static methods.
Note 2: Semantics of calling static methods on instances would remain
unchanged, i.e. static methods are still not virtual.
Note 3: The following would be a compile-time error:

interface J {
    public static void f();
}
class X implements J {
    public static void f(){...}
}
class Y extends X {
}
// ERROR: class Y does not provide
// its _own_ implementation of f()

Note 4: Abstract constructors could be allowed, too.

interface Serializable {
    public abstract Serializable();
}

This would require each implementation of Serializable to provide a
public no-arg constructor.
(Maybe the following would be a better syntax:
interface Serializable<S extends Serializable> {
    public abstract S();
}
)

Now I present two examples where it would be useful.

(1) Eliminate or reduce the use of reflection in serialization frameworks.
One example was given in Note 4 --- the presence of no-arg constructor in
a serializable class would be checked at compile-time rather than at run-
time.

For a more sophisticated usage some new API and additional support from
compiler is required. (The following may not be the best way to extend
the API, but I hope it will serve well for illustration.)

Imagine a new magic class Implementation<T>. This class will have no
methods on its own, but on its instances we will be able to call the same
methods as on the class T. (For this, the compiler magic would be
necessary.)

Example:

interface J {
    J(int x);
    static void f();
    void g();
}

class A implements J {
    A(int x){...}
    static void f(){...}
    void g(){...}
}

Implementation<J> I = A.class.asImplementationOf(J.class);
I.new(5); // OK, calling the constructor A(int x)
I.f(); // OK, calling static method A.f()
I.g(); // ERROR, calling an instance method without an instance of J

Notice extending the Class API by adding new method
    <T> Implementation<T> asImplementationOf(Class<T> clazz);
The restriction would apply that the type T is known at compile time.

Now back to usage in serialization frameworks. The above API would
automate the verification that all required constructors and static
methods are present in a class:

interface MySerializable<S extends MySerializable<S>> {
    public static S readObject(ObjectInputStream in);
}

Class<?> cls = Class.forName("com.example.MySerializableClass");
Implementation<MySerializable> M =
        cls.asImplementationOf(MySerializable.class);
MySerializable obj = M.readObject(in);

Note that the verification that MySerializableClass really implements
MySerializable interface would be automatically done in the
Class.asImplementationOf() method, thus saving much of the reflection
code.

(2) The second use case is with generics, but would require reified
generics (which I hope will appear in some future version of Java).

Suppose you have an abstract class Vector which represents a vector in a
vector space (don't confuse with java.util.Vector) and a few
implementations, like Vector2D and Vector3D.

abstract class Vector<V extends Vector<V>> {
    public abstract V add(V v); // returns the sum of v and this
    ...
}

class Vector2D extends Vector<Vector2D> {
    public static Vector2D zero(); // returns (0,0)
    ...
}

class Vector3D extends Vector<Vector3D> {
    public static Vector3D zero(); // returns (0,0,0)
    ...
}

Now let's have a generic class that will use vectors and do operations on
them, but doesn't really care about their actual dimension. So it will
work with abstract type Vector. But for some operations it may be
necessary to obtain the zero vector, without explicitely knowing the
actual type of vector. We may want to write something like this:

class MyClass<V extends Vector<V>> {
    public void someMethod(){
        V v = V.zero();
        ...
    }
}

This is of course not possible, but could be made possible if Vector
specified abstract static method zero():

abstract class Vector<V extends Vector<V>> {
    public static abstract V zero();
    public abstract V add(V v);
    ...
}

We would further change the declaration of MyClass to

class MyClass<V implements Vector<V>> {
    ...
}

The keywork extends was exchanged for implements (another syntax
extension). The compiler would know that a type parameter V that fully
implements all abstract static methods of Vector is required (so, for
example, Vector itself would not be a valid type parameter of MyClass).