User account creation filtered due to spam.
Suppose you have bytecode that tries to instantiate an abstract class.
The compiler accepts this (as it ought to), but then at runtime the
instantiation succeeds. Instead it should throw InstantiationException
(This problem applies to interfaces as well.)
The simplest way to fix this would be to add a check to _Jv_AllocObject
and friends. However, this may be too expensive (we want to keep allocation
Another approach would be a table of "new pointers", which points to the
allocator for any class instantiated from the current compilation unit.
This could be filled in at link time.
There might be a way to implement this without additional _Jv_AllocObject cost
and without adding new ABI tables.
If abstract classes and interfaces were given a zero or negative value in their
size field, I think the GC will call GC_oom_fn if an attempt were made to
allocate them. We could then throw InstantiationException instead of
OutOfMemoryError in this case.
Andrew pointed out on irc that we could also implement this by
installing a pointer to a "constructor" which would simply throw
the appropriate exception.
Now I think the idea in comment #3 is incorrect.
I looked at implementing it today, and I realized that
it will also cause a super() constructor call to
throw an exception.
The idea in comment #1 may still work. I'd prefer something
more direct however.
Just came here by chance :-)
You can check "if (this.class == ...)" in the constructor. It will slow down constructors for subclasses though.
I'm not sure that suggestion will work.
My recollection is that the order of checks is specified,
and that allocating memory before the abstract-ness check
would be incorrect.
I didn't confirm this with the spec though.
Closing as won't fix as the Java front-end has been removed from the trunk.