Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: v_borchert@despammed.com (Volker Borchert)
Newsgroups: comp.lang.java.programmer
Subject: Re: Alternatives languages on the JVM: which one or is there no alternative?
Date: 27 Nov 2013 05:13:53 GMT
Organization: Private site at Eddersheim, Germany
Lines: 94
Distribution: world
Message-ID: <l73v2h$f22$1@Gaia.teknon.de>
References: <b61c37c4-1b86-4b63-8ed1-fa5834eb638e@googlegroups.com> <l733pd$7kk$1@Gaia.teknon.de> <bfklnaFis1vU1@mid.individual.net>
X-Trace: individual.net /ZSfehNc8Ug07mlkUFnKsQIvBiDpG+n5JvLY/IHSe9SFdvUDfV
Cancel-Lock: sha1:xnhyoj1lvbcxkEgoOz3Ew0OVcYg=
Xref: csiph.com comp.lang.java.programmer:26635

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>