Re: Alternatives languages on the JVM: which one or is there no alternative?
Robert Klemme wrote:
On 26.11.2013 22:28, Volker Borchert wrote:
No language that is to run on the JVM can overcome its fundamental
shortcoming of missing multiple implementation inheritance.
I have come to believe that omitting things that other languages do was
actually a wise decision of the language designers. Avoiding MI might
be one of them. Granted, you cannot use implementation inheritance.
But sometimes not making these things easy is actually an advantage. At
least I think that when comparing C++ and Java. The equation might
calculate differently when comparing Java to other languages (Eiffel?).
Maybe so, but then why did the make multihreading - which is even
easier to get really wrong - so easy to use... OO without MI is like
a Ford Mustang with a two cylinder two stroke engine. Yes, it might
eventually take you from A to B, but is it fun?
What's wrong with this?
class Foo<T> {
private Object ref;
protected T getItem() {
return ref instanceof WekReference<?> ?
((WeakReference<T>) ref).get() :
(T) ref;
}
public T doSomeWork() {
final T x = getItem();
// work ...
return x;
}
}
BTDT
Then you need a pair of setters or one setter and one method which
switches reference mode. This avoids having two fields and it avoids
"lots of duplicated code".
You still have an extra two-word object header, and you cannot use
WeakReference<T> directly if you want the Foo to act on the
reference being cleared by garbage collection. These 24 extra bytes
hurt if you are doing low-level stuff and expect some tens or
hundreds of thousands of Foo.
Why do you think Java got generally known to be slow and bloated?
getItem() above actually checks for assignment compatibility TWICE -
once for the instanceof and once for the actual cast. JIT should
mitigate this, but I'd still like to have dynamic_cast
I do not know your notification requirements but I am sure you are aware
of ReferenceQueue.
Yes, of course, but ReferenceQueue.poll() returns the Reference<T>,
not the Foo, so for the Foo to act, you need something like
class Foo<T> {
// nonstatic inner class uzes 4 bytes for the
// implicit this$0 and 4 more bytes padding
class TPtr<T> extends WeakReference<T> {
Foo foo() {
return Foo.this;
}
}
void gced() {
}
}
to do something like
...
while ((ref = queue.poll()) != null) {
((TPtr<T>) ref).foo().gced();
}
...
How do you do that? The only way I can think of is
having an additional thread blocking in ReferenceQueue.remove().
BTDT
wouldn't it make more sense to let T know of its container / owner?
Why? What for?
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_borchert@despammed.com>