Alternatives languages on the JVM: which one or is there no alternative?

[Saxo]

Hello,

I'm one of the guys that somewhen felt frustrated with Java for the lack ofextension methods, traits/mixins, closures, etc. So I started looking intoother languages on the JVM such as Groovy, Scala, Kotlin, Ceylon. After taking some effort to learn Scala I started to feel uneasy with it, because for my personal taste a language should strive not only for power, but for simplicity as well. And Scala IMHO is not really simple. So I looked into Kotlin and Groovy.

Meanwhile I feel my mind is starting to realize more and more that there won't be any alternative language on the JVM for which there will also be jobs. Yes, there are Groovy jobs for Grails developers. There are some very few Scala jobs for Akka (akka.io) or Play developers. But there are no jobs for doing any kind of development as such in Scala or Groovy. Not here in mycountry and apparently not even in the US. Ceylon and Kotlin are way too new anyway.

Coming to think of it my conclusion is that companies that develop some product to make money with on the free market have little gain from using a language their customers probably won't use. If Akka were written in Java andnot in Scala companies looking for a product like Akka would feel much more comfortable. What happens if Scala dies? Bloody hard to find Scala developers anyway. Akka being written in Scala might appeal to customers that areinto Scala. But there are only very very few. So better develop your product to begin with for Java if it is for the JVM.

So my conclusion in the end is that it makes sense to learn Scala for the sake of finding a better Java job. People that do some Scala are for sure ona better level than some average Java coding shop. But looking for a language that can replace Java is hopeless. Problem is I'm starting to feel moreand more confused about all this. I'd like to see what other people think about this or what kind of "strategy" other people would apply concerning alternative JVM languages.

Cheers, Saxo

 

[Silvio]

Hello,

I'm one of the guys that somewhen felt frustrated with Java for the lack of extension methods, traits/mixins, closures, etc. So I started looking into other languages on the JVM such as Groovy, Scala, Kotlin, Ceylon. After taking some effort to learn Scala I started to feel uneasy with it, because for my personal taste a language should strive not only for power, but for simplicity as well. And Scala IMHO is not really simple. So I looked into Kotlin and Groovy.

Meanwhile I feel my mind is starting to realize more and more that there won't be any alternative language on the JVM for which there will also be jobs. Yes, there are Groovy jobs for Grails developers. There are some very few Scala jobs for Akka (akka.io) or Play developers. But there are no jobs for doing any kind of development as such in Scala or Groovy. Not here in my country and apparently not even in the US. Ceylon and Kotlin are way too new anyway.

Coming to think of it my conclusion is that companies that develop some product to make money with on the free market have little gain from using a language their customers probably won't use. If Akka were written in Java and not in Scala companies looking for a product like Akka would feel much more comfortable. What happens if Scala dies? Bloody hard to find Scala developers anyway. Akka being written in Scala might appeal to customers that are into Scala. But there are only very very few. So better develop your product to begin with for Java if it is for the JVM.

So my conclusion in the end is that it makes sense to learn Scala for the sake of finding a better Java job. People that do some Scala are for sure on a better level than some average Java coding shop. But looking for a language that can replace Java is hopeless. Problem is I'm starting to feel more and more confused about all this. I'd like to see what other people think about this or what kind of "strategy" other people would apply concerning alternative JVM languages.

Cheers, Saxo

If you look at this all from the perspective of a programmer to be who
wants to maximize his short term chances of finding a job you may be
right, although one could argue that the demand/supply ratio may be more
favourable to a Scala programmer than to a Java programmer. The salary
most likely will be anyway.

But if you look at this from the perspective of a software company that
builds software for end users (which is by far the majority) then things
look quite different. End users could not care less about which language
was used to develop their software. And if a language can offer far
greater productivity while being able to build upon all the tools
already available for competing languages that target the same
environment (as is the case for Scala) then it can be a very attractive
option.

My own company is such a shop that started using Java about fifteen
years ago. Since then the JVM has improved greatly and the available
tools and libraries have reached an extreme level, both in volume and in
quality. Java has been outgrown by this and the language has too simple
basics to be brought to the same level.

The lack of expressiveness in Java the language has given birth to
horrible frameworks that take annotations to the extreme, creating their
own little (or not so little) languages on top of the core language,
something I foresaw when annotations where introduced making me an
immediate opponent of the feature.

Scala is among a newer set of languages that tackle this problem and I
think that has been a blessing. C# and even more F# are far superior
languages when compared to Java but the .NET ecosystem and the Windows
OS have no appeal to me at all. Scala allows us to stay on open
platforms and the JVM without being forced to use a language that feels
old (Java8 changes close to nothing about this feeling, BTW).

Other shops will make different choices. To each his own, I do not think
Scala is the ideal language for everyone. But given the currently
available options, it is the best one for us.

Cheers,

Silvio

 

[Saxo]

Am Montag, 25. November 2013 12:46:18 UTC+1 schrieb Silvio:

The lack of expressiveness in Java the language has given birth to

horrible frameworks that take annotations to the extreme, creating their

own little (or not so little) languages on top of the core language,

something I foresaw when annotations where introduced making me an

immediate opponent of the feature.

Yes, and byte code manipulation and I don't know what.

old (Java8 changes close to nothing about this feeling, BTW).

Yeah, lambdas in JDK8 are a big improvement, but I think that was it then. JDK8 was delayed as they had problems with binary compatibility with lambdas and defender methods. I think because problems with binary compatibility getting larger and larger from JDK8 on Java will be on maintenance and no big new language features can be expected. Defender methods are already somesort of minimal traits where it looks like they were buckling under problems with getting real traits in. The masses will probably just stick to JDK8, but for others it is clear that they need another language. Maybe the Ceylon and Kotlin guys started their effort as they saw this comming ...

So, yes, getting into Scala to get a better job looks like a good strategy.

Thanks for your reply, Saxo

 

[Robert Klemme]

The lack of expressiveness in Java the language has given birth to
horrible frameworks that take annotations to the extreme, creating their
own little (or not so little) languages on top of the core language,
something I foresaw when annotations where introduced making me an
immediate opponent of the feature.

Annotations are one of the major innovations in the Java language. The
fact that they can be abused (and are abused) for me is not criteria
enough to dislike or even ban the feature. You wouldn't forbid knifes
even though a lot of people die from them, would you?

Btw, Saxo did you consider JRuby? It's actually one of the fastest Ruby
variants, has a nice and appealing syntax, you can use all the Java
classes and, if you like, Rails.

Kind regards

robert

 

[Saxo]

Btw, Saxo did you consider JRuby? It's actually one of the fastest Ruby

variants, has a nice and appealing syntax, you can use all the Java

classes and, if you like, Rails.

Hi Rob,

thanks for the hint. Am considering Groovy. JRuby is also interesting as its "object-orientation" is well done (at least compared to Python ...).

Cheers, Saxo

 

[Silvio]

On 25.11.2013 12:46, Silvio wrote:

Annotations are one of the major innovations in the Java language. The
fact that they can be abused (and are abused) for me is not criteria
enough to dislike or even ban the feature. You wouldn't forbid knifes
even though a lot of people die from them, would you?

They are an innovation no doubt. In my opinion not for the better. I
consider annotations not so much a language feature but more of a
meta-language feature. Most annotations have no intrinsic semantics
inside the language (and the ones that do should have been converted
into proper language syntax).
They just add textual markers to the class files that frameworks,
libraries and tools can use to implement their logic. My complaint about
this is that it decouples these frameworks from the language semantics
and makes them complete black-boxes from the language perspective.
Even inside the current language could most of these tools have been
implemented just as conveniently without annotations (and without the
XML hell they where meant to replace).
To poor library and framework designers annotations are not knifes, they
are hammers and every challenge these people come across looks like some
sort of nail.
In time, mastering the annotations that come with their tools has
increasingly become an integral part of the job of Java programmers. In
my opinion that trend marks the decline of Java into obsolescence.

 

[Robert Klemme]

They are an innovation no doubt. In my opinion not for the better. I
consider annotations not so much a language feature but more of a
meta-language feature.

Yes, that's what they are: they allow to attach state to language artifactswhich is not interpreted by the compiler but rather code (typically frameworks and libraries).

Most annotations have no intrinsic semantics
inside the language (and the ones that do should have been converted
into proper language syntax).

That would certainly have made for a cleaner separation: syntax for language tools, annotations for all other. I'm probably too pragmatic to see the missing separation as an important defect.

They just add textual markers to the class files that frameworks,
libraries and tools can use to implement their logic.

Not only textual! They are type safe and type safety is enforced by compiler and supported by IDEs. This is a big advantage over usual "annotations"in comments!

My complaint about
this is that it decouples these frameworks from the language semantics
and makes them complete black-boxes from the language perspective.

Yes, and that exactly is the strength of annotations! Basically it allows to extend the language with features that would otherwise either require syntax and compiler changes for every one of them or have to be implemented in the language; in the latter case the nature of meta data would be lost because you would have to use ordinary Java classes and static fields to represent the same information. Plus, you would have to do all the plumbing toassociate meta data with classes (e.g. search for a public static member of a class with a specific type etc.).

Even inside the current language could most of these tools have been
implemented just as conveniently without annotations (and without the
XML hell they where meant to replace).

I strongly disagree. Just think of JPA for example. It cannot work with some kind of meta data indicating the mapping from classes to tables etc.

To poor library and framework designers annotations are not knifes, they
are hammers and every challenge these people come across looks like some
sort of nail.

Well, but I prefer to live in a world where we have the freedom to use these for good (and bad) than in a world without them. For me advantages far outweight disadvantages. I am a bit surprised: didn't you advocate .Net andC# which also has a similar mechanism with "C# attributes"?

In time, mastering the annotations that come with their tools has
increasingly become an integral part of the job of Java programmers. In
my opinion that trend marks the decline of Java into obsolescence.

As you are not surprised I do not share that view. On the contrary: just look at how much JEE5 and later improves over earlier J2EE!

Kind regards

robert

 

[Silvio]

Not only textual! They are type safe and type safety is enforced by compiler and supported by IDEs. This is a big advantage over usual "annotations" in comments!

That is just a compile-time thing. In the end they only become dead data
in the class file to be interpreted by anything else than the VM.

Yes, and that exactly is the strength of annotations! Basically it allows to extend the language with features that would otherwise either require syntax and compiler changes for every one of them or have to be implemented in the language; in the latter case the nature of meta data would be lost because you would have to use ordinary Java classes and static fields to represent the same information. Plus, you would have to do all the plumbing to associate meta data with classes (e.g. search for a public static member of a class with a specific type etc.).

That makes no sense. If you would follow that line of thought the
language could have been a lot smaller still since anything out of the
bare essentials could then have been done with annotations.
So we are just lucky they did not think of them earlier?

My point is that given decent data structures there is no need for
meta-data. You should not want to find all public static members of any
class that is of some type X, it is an anti-pattern on its own. Why not
have a MyLibraryField<X> and have it do its own registration? The answer
to that is frameworks that want to do all kinds of magic around Java
programs even without running any of the actual code.

I strongly disagree. Just think of JPA for example. It cannot work with some kind of meta data indicating the mapping from classes to tables etc.

No metadata needed for that at all. A decent base class that you derive
your entity classes from and proper field types that represent database
fields and all would be fine.

The choice for annotations here is not a necessity, merely one of
single-dimensional thinking and hammer happiness.

And I am not the only one who hates JPA...

Well, but I prefer to live in a world where we have the freedom to use these for good (and bad) than in a world without them. For me advantages far outweight disadvantages. I am a bit surprised: didn't you advocate .Net and C# which also has a similar mechanism with "C# attributes"?

C# attributes are part of what they copied from Java, which is the least
compelling part of the language. I did not say C# was perfect, I just
said they did try to grow the language by adding stuff to make it more
powerful.
Java has hardly improved or evolved and most development around it has
been in the area of mutually excluding and mutually incompatible
frameworks, JEEx versus Spring and others, JPA versus Hibernate, JSF
versus a plethora of web frameworks etc. etc. that has fragmented the
marketplace and resulted in a lot of uncertainty about which framework
bandwagon to jump on.

The Java world has become a mess, even more than Microsoft has managed
to make a mess of their own closed little world.

As you are not surprised I do not share that view. On the contrary: just look at how much JEE5 and later improves over earlier J2EE!

Kind regards

robert

JEE is another example of a framework that has failed to achieve
convergence but instead has caused people to develop competing stuff.
Many people have abandoned it completely in favour of Spring, REST etc.
It was a poor attempt to create a Swiss knife hammer resulting in
something that was too bloated and complex to last.

I habitually rewrite Java libraries and sometimes applications to Scala
resulting in about 75% code size reduction overall which gets up to 90%
for wiring code in applications. Java programmers tend to counter this
by saying the code is incomprehensible and suffers from a too high
logic/line ratio. And then they go on to say that random annotations
that do magic stuff that might change ever so slightly with a new
library version or when swapping one library out for another are merely
an "innovation".

To each his own.

Cheers,

Silvio

 

[Volker Borchert]

No language that is to run on the JVM can overcome its fundamental
shortcoming of missing multiple implementation inheritance. While
this might not be a problem with everyday code, is _is_ a problem
if you are in low-level or framework stuff, for example if you have
class hierarchies where you want to offer mixed reference flavors -
your class C either ends up with two fields, one T and one to some
(X extends WeakReference<T>) which contains another extra field for
the back reference to the containing C so that the C can be notified
of the X having been garbage collected and an extra two-word object
header, or with lots of duplicated code.

 

[Robert Klemme]

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?).

While
this might not be a problem with everyday code, is _is_ a problem
if you are in low-level or framework stuff, for example if you have
class hierarchies where you want to offer mixed reference flavors -
your class C either ends up with two fields, one T and one to some
(X extends WeakReference<T>) which contains another extra field for
the back reference to the containing C so that the C can be notified
of the X having been garbage collected and an extra two-word object
header, or with lots of duplicated code.

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;
}

}

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".

I do not know your notification requirements but I am sure you are aware
of ReferenceQueue. Do you need notification the very moment an object
is collected? How do you do that? The only way I can think of is
having an additional thread blocking in ReferenceQueue.remove(). Not
sure though why I then would place a field in the WeakReference -
wouldn't it make more sense to let T know of its container / owner?

Kind regards

robert

 

[Arne Vajhøj]

C# attributes are part of what they copied from Java,

C# has had attributes since 1.0 (2002).

Java got annotations in 1.5 (2004).

C# did not copy that one from Java. More likely that Java copied
from C#.

Java has hardly improved or evolved and most development around it has
been in the area of mutually excluding and mutually incompatible
frameworks, JEEx versus Spring and others,

Java EE and Spring are not mutually excluding and mutually incompatible.

I will guess than half of Java projects use both.

JPA versus Hibernate,

JPA is an API. Hibernate is an implementation that has both a
JPA API and its own API.

Neither mutually excluding nor mutually incompatible.

JEE is another example of a framework that has failed to achieve
convergence but instead has caused people to develop competing stuff.
Many people have abandoned it completely in favour of Spring, REST etc.

I will guess that the majority of Spring work happens in Java EE world.

I don't think I have ever heard of anybody doing REST in Java without
Java EE.

Arne

 

[Volker Borchert]

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?

 

[Silvio]

C# has had attributes since 1.0 (2002).

Java got annotations in 1.5 (2004).

C# did not copy that one from Java. More likely that Java copied
from C#.

Good one, I did not check that and did not look into C# until about six
years ago.

Java EE and Spring are not mutually excluding and mutually incompatible.

No, they are not literally but they overlap for a large part in that
Spring aims to solve many problems that JEE does but does so
differently. Therefore, they are conceived by many as competing.

I will guess than half of Java projects use both.


JPA is an API. Hibernate is an implementation that has both a
JPA API and its own API.

Neither mutually excluding nor mutually incompatible.

Indeed, but the JPA interface was stuck onto Hibernate after the fact. I
have worked on a couple of projects where they had to use both
interfaces at the same time which was not without problems.

I will guess that the majority of Spring work happens in Java EE world.

I don't think I have ever heard of anybody doing REST in Java without
Java EE.

It depends on what you mean by JEE. Some people consider using a servlet
container using JEE. I call it JEE if you are going for a full-blown JEE
server like Glassfish, JBoss, Weblogic etc. and start using all the
additional stuff in there.

In about twenty REST projects I did the last five years only once did it
involve such a beast and even then the REST project was part of removing
the thing altogether.

Almost all of our current projects involve a servlet container (Jetty in
our case) so you might say I love JEE...

Silvio

 

[Joerg Meier]

Indeed, but the JPA interface was stuck onto Hibernate after the fact.

Considering Hibernate is from 2001 and JPA/JSR 220 is from 2006, that is
hardly surprising. Should Java not get features anyone once there is some
3rd party library with a similar feature ?

Liebe Gruesse,
Joerg

 

[Robert Klemme]

Maybe so, but then why did the make multihreading - which is even
easier to get really wrong - so easy to use...

Probably because MT is necessary given physical limits to what a single
CPU can do.

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?

Why do you use Java if you dislike it so much?

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.

It's totally unclear what you mean by "low level stuff".

Why do you think Java got generally known to be slow and bloated?

Probably because a) computers had less memory and CPU power at the time
it entered the stage and b) the JVM was far less efficient than it is today.

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

What does dynamic_cast in C++ do differently? As far as I am informed
it involves a type check as well. I mean, you can have the same in Java
by catching the exception (which is what you need to do in C++ IIRC).

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() {
}
}

Since Foo inherits Object you could as well make Foo<T> inherit
WeakReference<T> avoiding the additional bytes per instance. And it's
basically what Foo seems to be: a reference to a T - so it's actually
not too far fetched.

to do something like

...
while ((ref = queue.poll()) != null) {
((TPtr<T>) ref).foo().gced();
}
...

What does that thread do outside this loop?

BTDT

And why did it not work for you?

Why? What for?

Since Foo references the other object there seems to be a business
relationship between the two. T would then need to be bound by an
interface.

I find it difficult to discuss this without knowing more about your
requirements and situation. But then again, maybe you don't want or
cannot disclose that.

Cheers

robert

 

[Joshua Cranmer ðŸ§]

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.

And you think multiple inheritance has no costs? The moment you allow
multiple inheritance of implementations, you permit the so-called
"diamond problem." The diamond problem has three solutions:
1. There are multiple copies of some fields.
2. Offsets to a particular named field are dependent on object
instances, not on classes/class hierarchies.
3. Casting up or down a tree requires recomputing offsets on a
per-object instance basis, not a per-class basis.

The first case only affects classes that are involved in the diamond
problem, but the effects are so egregiously awful (in the case where
data is actually present) that it is prudent to outlaw it from
happening. The latter two cases impose a performance penalty on the
entire program, even if the diamond problem never arises: you're paying
for what you don't use.

Multiple inheritance is a seductive call. There are very, very, very few
times where it is actually proper--recall that inheritance, at least as
Java is concerned, is meant to model an "is-a" relationship, not a
"has-a" relationship. Since inheritance is an indelible part of the
public contract of a class in Java, the "is implemented in terms of"
relationship is supposed to be handled via composition (cf., Effective
Java). Let the JIT and the optimizer work through the overhead;
premature optimization, after all, is the root of all evil.

 

[Silvio]

Considering Hibernate is from 2001 and JPA/JSR 220 is from 2006, that is
hardly surprising. Should Java not get features anyone once there is some
3rd party library with a similar feature ?

Liebe Gruesse,
Joerg

I think adding the JPA interface to Hibernate was an improvement. It is
just too bad that Hibernate and some competitors had to exist long
before a standard API was defined.

I welcome new language features, in fact I think Java gets them too
little and mostly too late. It has everything to do with the
backward-compatibility dogma. Given the current situation Java is in I
think the potential room for development is by definition too restricted.

Take closures as an example. Closures potentially enable the definition
of new abstractions that are as convenient to use as built in language
features. But the "effectively final" limitation on closures in Java8
reduce that potential enormously. I know and understand all the
reasoning behind that decision but it degrades closures to little more
than syntactical sugar over nested anonymous classes. Gone is the
potential of having classes that define their own control flow logic
which can be intertwined with normal control flow. Among other things
this means that doing callback-based coding in Java will remain very
awkward and non-native feeling.

Given a set of such powerful language features (you would need a couple
more) many of what is now done in Java by frameworks using annotations
could have been done cleanly and conveniently in the language or plain
(standard) libraries.

 

[Roedy Green]

I'm one of the guys that somewhen felt frustrated with Java

One language you have not yet tried is Ruby. I am not saying it is
what you are looking for, just that it is another possibility.

 

[Silvio]

And good riddance to it! Control flow is one area where I'd rather _not_
have to learn new idioms and idiosynchrasies for every additional library
and developer in the project.

That is a typical reaction from a Java programmer. You already do
nothing else than learn idioms and idiosyncrasies but have to do so more
awkwardly because you do it in the form of plain method calls and
manually managing handle objects, carefully try-catching everything to
make sure you close/release the handles. The try-with-resources
construct is a feeble attempt to alleviate a small part of this.

What is wrong with being able to use a Connection pool like:

pool {
con => {
//use Connection con
}
}

and have the ConnectionPool class take care of checking out a
connection, running the user code on it inside a try-catch block and
finally return the connection back to the pool? No reason to not be able
to nest such a construct inside a loop and increment some local
accumulator variable based on the result of repeatedly using the
connection, is there?

Java8 with its closures can approach this and libraries WILL evolve in
this direction. However, although code inside Java8 closures may be
textually embedded in surrounding code there is always a semantic
barrier surrounding it that will call for workarounds in many practical
situations. This will sooner make the result less readable, less
thread-safe and generally more error prone than if Java8 would have had
full closures.

There are compelling arguments for doing things the way they did. But
these are mostly related to backward compatibility and staying close to
the original language.

 

[Andreas Leitgeb]

And you think multiple inheritance has no costs? The moment you allow
multiple inheritance of implementations, you permit the so-called
"diamond problem." The diamond problem has three solutions:
1. There are multiple copies of some fields.
2. Offsets to a particular named field are dependent on object
instances, not on classes/class hierarchies.
3. Casting up or down a tree requires recomputing offsets on a
per-object instance basis, not a per-class basis.

I think, the diamond problem w.r.t fields is over-rated.

1.: It's like a plain tree-shaped class hierarchy, where multiple classes
in a vertical chain may already have non-private equally-named fields.
And the jvm is quite good at keeping these separate...
2.: It would still only depend on the Object's getClass(), not
on each individual instance.
3.: Only casts along an "is-*also*-a"-line would need to know some
offset, and the compiler already masters harder problems than that.

Just recently I came a cross a configuration of entities akin to

mammal | egg-layer
\ /
platypus

and I will probably need to decide on one super class, then
duplicate some code (even if just as stubs) to get the other
candidate super-class' code in.

Multiple inheritance is a seductive call. There are very, very, very few
times where it is actually proper--recall that inheritance, at least as
Java is concerned, is meant to model an "is-a" relationship, not a
"has-a" relationship.

So, if some entity "is-a"nother entity, but "is-also-a" yet another
entity, then why is Java praised for forcing me to model an "is-also-a"
relation as a "has-a"?