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

Discussion in 'Java' started by Saxo, Nov 25, 2013.

  1. Saxo

    Saxo Guest

    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
     
    Saxo, Nov 25, 2013
    #1
    1. Advertising

  2. Saxo

    Silvio Guest

    On 11/25/2013 12:09 PM, Saxo wrote:
    > 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
     
    Silvio, Nov 25, 2013
    #2
    1. Advertising

  3. Saxo

    Saxo Guest

    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
     
    Saxo, Nov 25, 2013
    #3
  4. On 25.11.2013 12:46, Silvio wrote:

    > 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


    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Nov 25, 2013
    #4
  5. Saxo

    Saxo Guest


    > 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
     
    Saxo, Nov 25, 2013
    #5
  6. Saxo

    Silvio Guest

    On 11/25/2013 10:10 PM, Robert Klemme wrote:
    > 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.
     
    Silvio, Nov 26, 2013
    #6
  7. On Tuesday, November 26, 2013 8:54:58 AM UTC+1, Silvio wrote:
    > On 11/25/2013 10:10 PM, Robert Klemme wrote:
    > > 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.


    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
     
    Robert Klemme, Nov 26, 2013
    #7
  8. Saxo

    Silvio Guest

    On 11/26/2013 09:29 AM, Robert Klemme wrote:
    >
    > 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.


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


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


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

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

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


    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
     
    Silvio, Nov 26, 2013
    #8
  9. 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.


    --

    "I'm a doctor, not a mechanic." Dr Leonard McCoy <>
    "I'm a mechanic, not a doctor." Volker Borchert <>
     
    Volker Borchert, Nov 26, 2013
    #9
  10. 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?).

    > 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

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Nov 26, 2013
    #10
  11. Saxo

    Arne Vajhøj Guest

    On 11/26/2013 9:29 AM, Silvio wrote:
    > 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
     
    Arne Vajhøj, Nov 27, 2013
    #11
  12. 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 <>
    "I'm a mechanic, not a doctor." Volker Borchert <>
     
    Volker Borchert, Nov 27, 2013
    #12
  13. Saxo

    Silvio Guest

    On 11/27/2013 03:55 AM, Arne Vajhøj wrote:
    > On 11/26/2013 9:29 AM, Silvio wrote:
    >> 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#.


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

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


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


    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.

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


    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

    > Arne
    >
     
    Silvio, Nov 27, 2013
    #13
  14. Saxo

    Joerg Meier Guest

    On Wed, 27 Nov 2013 08:59:37 +0100, Silvio wrote:

    > 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

    --
    Ich lese meine Emails nicht, replies to Email bleiben also leider
    ungelesen.
     
    Joerg Meier, Nov 27, 2013
    #14
  15. On 27.11.2013 06:13, Volker Borchert wrote:
    > 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...


    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?

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


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

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


    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?

    >> How do you do that? The only way I can think of is
    >> having an additional thread blocking in ReferenceQueue.remove().

    >
    > BTDT


    And why did it not work for you?

    >> wouldn't it make more sense to let T know of its container / owner?

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


    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Nov 27, 2013
    #15
  16. On 11/26/2013 11:13 PM, Volker Borchert wrote:
    > 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.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer ðŸ§, Nov 28, 2013
    #16
  17. Saxo

    Silvio Guest

    On 11/27/2013 10:41 AM, Joerg Meier wrote:
    > On Wed, 27 Nov 2013 08:59:37 +0100, Silvio wrote:
    >
    >> 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
    >


    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.
     
    Silvio, Nov 28, 2013
    #17
  18. Saxo

    Roedy Green Guest

    On Mon, 25 Nov 2013 03:09:05 -0800 (PST), Saxo <> wrote,
    quoted or indirectly quoted someone who said :


    >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.
    --
    Roedy Green Canadian Mind Products http://mindprod.com
    Unlike many machines, computers require no water once they are
    manufactured.
     
    Roedy Green, Nov 28, 2013
    #18
  19. Saxo

    Silvio Guest

    On 11/28/2013 11:28 PM, Leif Roar Moldskred wrote:
    > Silvio <> wrote:
    >>
    >> 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.

    >
    > 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.
     
    Silvio, Nov 28, 2013
    #19
  20. Re: Alternatives languages on the JVM: which one or is there noalternative?

    Joshua Cranmer 🧠<> wrote:
    > 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"?
     
    Andreas Leitgeb, Nov 28, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?iso-8859-1?B?bW9vcJk=?=

    Compilers migrate other languages to JVM?

    =?iso-8859-1?B?bW9vcJk=?=, Mar 1, 2006, in forum: Java
    Replies:
    1
    Views:
    424
    Chris Uppal
    Mar 1, 2006
  2. Steve
    Replies:
    2
    Views:
    423
  3. Raga
    Replies:
    2
    Views:
    484
    Chris Uppal
    Oct 16, 2006
  4. Charles Oliver Nutter

    Language poll: which one on the JVM?

    Charles Oliver Nutter, Jan 29, 2007, in forum: Ruby
    Replies:
    1
    Views:
    113
    Ed Howland
    Jan 31, 2007
  5. Charles Oliver Nutter

    [mildly OT] JVM Languages group

    Charles Oliver Nutter, Aug 5, 2007, in forum: Ruby
    Replies:
    6
    Views:
    118
    Charles Oliver Nutter
    Aug 6, 2007
Loading...

Share This Page