Do everything in Java…

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 5 22:19:00 PST 2014


On Sat, Dec 06, 2014 at 03:49:35PM +1300, Rikki Cattermole via Digitalmars-d wrote:
> On 6/12/2014 3:12 p.m., H. S. Teoh via Digitalmars-d wrote:
> >On Sat, Dec 06, 2014 at 03:01:44PM +1300, Rikki Cattermole via Digitalmars-d wrote:
> >>On 6/12/2014 11:28 a.m., Freddy wrote:
[...]
> >>>My problems with java:
[...]
> >>>This is all i can remember.
> >>
> >>You forgot type removal for generics during compilation.
> >
> >I dunno, while type erasure is certainly annoying when you actually
> >need information about the type, it's also eliminates template bloat.
> >I think the ideal system should be somewhere in between, where type
> >erasure is actively performed by the compiler where the type
> >information is not needed, while template instantiations are retained
> >when it is needed.  This should keep template bloat under control
> >while still offering full template capabilities. D currently leans on
> >the template bloat end of the spectrum; I think there is much room
> >for improvement.
[...]
> 
> Its a bit more then annoying. What happened when it was originally
> implemented was basically hacking of the compiler to support it, type
> erasure wasn't a design decision to my understanding.  Then again the
> last time I checked Java's reference compiler / jvm source code it was
> a real mess to say the least.  If I remember right an xml parser lib
> was at the same level in the repo as the compiler and nothing else at
> that level. This was only a few years ago now.
> 
> I really hope I'm wrong or its changed since then but who knows.

It's enterprise code. 'Nuff said. Even though "enterprise code" sounds
so glamorous, in reality it has a high likelihood of being a rats' nest
of spaghetti code with lasagna code layered on top, an accumulation of
patches upon hacks to bandaids over bugs resulting from earlier pathces,
with messy sauce leaking everywhere. I've seen enough examples of actual
"enterprise code" to know better than the idealistic image they pretend
to convey.

But anyway, that's beside the point. :-P  Type erasure does have its
value -- for example, if you have a template class that represents a
linked-list or tree or something like that, most of the code actually
doesn't care about the type of the data at all. Code that swaps pointers
to link / unlink nodes, or code that rebalances a tree, those pieces of
code are mostly type-independent and can operate generically on lists or
trees containing any type. Under D's template system, unless you
manually factor it out, all of this code will be instantiated over and
over again, once for every data type you might put into the list / tree.
For non-trivial containers, the template bloat can be quite horrendous.
Type erasure allows you to reuse a *single* copy of the code that
handles every type of data contained.

However, having *only* type erasure like Java leads to problems in parts
of the code that *do* need to know about the specifics of the data. Such
as whether it's a by-value or by-reference type (AIUI Java generics
requires you to box all POD types due to type erasure, which introduces
an additional needless layer of indirection), the need for postblits,
dtors, copy ctors, etc. (in Java they would be handled by virtual
methods AIUI), or certain operations that can generically apply to a
particular category of types (e.g., +, -, <, >, should in theory work
for all numeric types, including built-in types). This is where D's
template system shines, because it is able to eliminate boxing/unboxing
and lots of indirections by taking advantage of type information, as
well as not being subject to limitations of type erasure (e.g., Java
can't have catch blocks that catch List<Integer> and List<String>
separately, due to type erasure).

In an ideal world, we'd like to have the best of both worlds -- minimize
template bloat by merging parts of the generic code that don't depend on
the type, but retaining enough type information to be able to use it
when needed.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG


More information about the Digitalmars-d mailing list