Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26606 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-25 03:09 -0800
    Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-25 12:46 +0100
      Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-25 05:20 -0800
      Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-25 22:10 +0100
        Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-25 14:34 -0800
        Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-26 08:54 +0100
          Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-26 00:29 -0800
            Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-26 15:29 +0100
              Re: Alternatives languages on the JVM: which one or is there no alternative? Arne Vajhøj <arne@vajhoej.dk> - 2013-11-26 21:55 -0500
                Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-27 08:59 +0100
                  Re: Alternatives languages on the JVM: which one or is there no alternative? Joerg Meier <joergmmeier@arcor.de> - 2013-11-27 10:41 +0100
                    Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-28 12:48 +0100
                      Re: Alternatives languages on the JVM: which one or is there no alternative? leif.roar@invalid.com (Leif Roar Moldskred) - 2013-11-28 16:28 -0600
                        Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 00:03 +0100
                          Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-29 00:41 -0800
                            Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 12:05 +0100
                              Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-29 03:51 -0800
                                Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 16:44 +0100
                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 16:48 +0100
                                Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-02 06:33 -0800
                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-02 15:50 +0100
                                    Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-02 16:26 +0100
                                      Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-02 21:07 +0100
                                        Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-02 23:33 +0100
                                        Re: Alternatives languages on the JVM: which one or is there no alternative? markspace <markspace@nospam.nospam> - 2013-12-02 18:07 -0800
                                          Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-03 08:59 +0100
                                          Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-12-03 00:14 -0800
                                            Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-03 09:42 +0100
                                              Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-12-03 02:58 -0800
                                                Re: Alternatives languages on the JVM: which one or is there no alternative? Martin Gregorie <martin@address-in-sig.invalid> - 2013-12-03 20:55 +0000
                                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-12-04 00:12 -0800
                                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-14 03:31 -0400
                                                    Re: Alternatives languages on the JVM: which one or is there no alternative? Martin Gregorie <martin@address-in-sig.invalid> - 2013-12-14 10:11 +0000
                                                    Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-14 17:39 +0100
                                                      Re: Alternatives languages on the JVM: which one or is there no alternative? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-12-14 16:52 +0000
                                                      Re: Alternatives languages on the JVM: which one or is there no alternative? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-14 13:47 -0400
                                                        Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-14 23:55 +0100
                                          Re: Alternatives languages on the JVM: which one or is there no alternative? Sebastian <news@seyweiler.dyndns.org> - 2013-12-04 10:39 +0100
                                            Re: Alternatives languages on the JVM: which one or is there no alternative? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-14 03:56 -0400
    Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-26 21:28 +0000
      Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-26 23:29 +0100
        Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-27 05:13 +0000
          Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-27 22:57 +0100
            Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-29 23:22 +0000
              Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-30 14:41 +0100
              Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-30 16:49 -0600
          Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-27 23:07 -0600
            Re: Alternatives languages on the JVM: which one or is there no alternative? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-11-28 23:41 +0000
              Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-29 00:08 -0600
                Re: Alternatives languages on the JVM: which one or is there no alternative? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-11-29 16:49 +0000
                  Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-30 16:46 -0600
                    Re: Alternatives languages on the JVM: which one or is there no alternative? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2014-02-14 15:36 +0000
            Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-29 23:37 +0000
    Re: Alternatives languages on the JVM: which one or is there no alternative? Roedy Green <see_website@mindprod.com.invalid> - 2013-11-28 12:50 -0800

Page 1 of 3  [1] 2 3  Next page →

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

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

[toc] | [next] | [standalone]

#26607

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

[toc] | [prev] | [next] | [standalone]

#26609

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

[toc] | [prev] | [next] | [standalone]

#26613

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/

[toc] | [prev] | [next] | [standalone]

#26615

> 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

[toc] | [prev] | [next] | [standalone]

#26621

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.

[toc] | [prev] | [next] | [standalone]

#26622

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 artifacts which 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 to associate 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 and C# 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

[toc] | [prev] | [next] | [standalone]

#26624

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

[toc] | [prev] | [next] | [standalone]

#26634

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

[toc] | [prev] | [next] | [standalone]

#26636

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
>

[toc] | [prev] | [next] | [standalone]

#26637

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.

[toc] | [prev] | [next] | [standalone]

#26651

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.

[toc] | [prev] | [next] | [standalone]

#26654

Silvio <silvio@internet.com> 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.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#26655

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

[toc] | [prev] | [next] | [standalone]

#26660

Am Freitag, 29. November 2013 00:03:53 UTC+1 schrieb Silvio:
>This will sooner make the result less readable, less
>thread-safe and generally more error prone than if Java8 would have had
>full closures. 

What do you mean by "full closures"? That closure variables are not only readable, but also writable? Non-local returns missing? Just curious as to what full closures are expected to be.

Thanks, Saxo

[toc] | [prev] | [next] | [standalone]

#26663

On 11/29/2013 09:41 AM, Saxo wrote:
> Am Freitag, 29. November 2013 00:03:53 UTC+1 schrieb Silvio:
>> This will sooner make the result less readable, less
>> thread-safe and generally more error prone than if Java8 would have had
>> full closures.
>
> What do you mean by "full closures"? That closure variables are not only readable, but also writable? Non-local returns missing? Just curious as to what full closures are expected to be.
>
> Thanks, Saxo
>

You are right, that is a vague term. And yes, that is what I mean. In 
addition there are some syntactical limitations that make Java8 lambdas 
stand out from their surrounding code.

That is something that could be improved upon with some extra language 
features but I am afraid these would not go down easy with the 
conservative Java crowd, which is a pity. Anyone interested should look 
up Scala thunks and its alternative call syntax (infix call notation, 
multiple parameter lists, using braces, implicit call of apply/update 
etc). Nothing magical, simply some pragmatic additions that allow for 
much cleaner and more readable user code.

The current lambdas are an obvious compromise between people who would 
have welcomed more far fetched closure semantics and syntax versus 
people who where opposed to adding closures in the first place. That is 
understandable but I doubt having partial closures is better than not 
having them at all. I think it is unlikely that the current lambdas will 
evolve into full closures. Perhaps waiting a couple more years until the 
Java world became more receptive to the idea would have made it possible 
to do it right at once?

[toc] | [prev] | [next] | [standalone]

#26665

Am Freitag, 29. November 2013 12:05:37 UTC+1 schrieb Silvio:

> The current lambdas are an obvious compromise between people who would 
> 
> have welcomed more far fetched closure semantics and syntax versus 
> 
> people who where opposed to adding closures in the first place. That is 
> 
> understandable but I doubt having partial closures is better than not 
> 
> having them at all. I think it is unlikely that the current lambdas will 
> 
> evolve into full closures. Perhaps waiting a couple more years until the 
> 
> Java world became more receptive to the idea would have made it possible 
> 
> to do it right at once?

AFAIK Java8 lambdas are somewhat less verbose wrappers around anonymous inner classes. When I saw that closure vars inside Java8 lambdas are final my first thought was that obviously Java is from now on on maintenace and that's it. The language Java won't evolve any more. I guess things will just stay like that from now on as the case for Cobol or something. The focus will be on tools, framewors, systems, etc. as it already has been for a while I fear ...

[toc] | [prev] | [next] | [standalone]

#26667

On 11/29/2013 12:51 PM, Saxo wrote:
> Am Freitag, 29. November 2013 12:05:37 UTC+1 schrieb Silvio:
>
>> The current lambdas are an obvious compromise between people who would
>>
>> have welcomed more far fetched closure semantics and syntax versus
>>
>> people who where opposed to adding closures in the first place. That is
>>
>> understandable but I doubt having partial closures is better than not
>>
>> having them at all. I think it is unlikely that the current lambdas will
>>
>> evolve into full closures. Perhaps waiting a couple more years until the
>>
>> Java world became more receptive to the idea would have made it possible
>>
>> to do it right at once?
>
> AFAIK Java8 lambdas are somewhat less verbose wrappers around anonymous inner classes. When I saw that closure vars inside Java8 lambdas are final my first thought was that obviously Java is from now on on maintenace and that's it. The language Java won't evolve any more. I guess things will just stay like that from now on as the case for Cobol or something. The focus will be on tools, framewors, systems, etc. as it already has been for a while I fear ...
>

That is very likely, unfortunately. Personally I can live with that 
since I only use Java for legacy purposes and have done so for about 
five years now. Over 95% of the Java code I dive into now and then is 
even pre-1.5 (you know, casts, raw types, etc.).

But Java does not only serve a role as the status quo language for the 
JVM. It is also the most prominent arena where the new kids arrive. 
Unless one or some of the alternative JVM languages take over that role 
the JVM will (and already has) become less and less compelling to the 
rock-stars to be. The university I once attended now uses C# as the 
language for its primary entry level programming course. That used to be 
Java (not in my time of course, I learned programming with Algol68) ...

[toc] | [prev] | [next] | [standalone]

#26668

On 11/29/2013 04:44 PM, Silvio wrote:
> On 11/29/2013 12:51 PM, Saxo wrote:
>> Am Freitag, 29. November 2013 12:05:37 UTC+1 schrieb Silvio:
>>
>>> The current lambdas are an obvious compromise between people who would
>>>
>>> have welcomed more far fetched closure semantics and syntax versus
>>>
>>> people who where opposed to adding closures in the first place. That is
>>>
>>> understandable but I doubt having partial closures is better than not
>>>
>>> having them at all. I think it is unlikely that the current lambdas will
>>>
>>> evolve into full closures. Perhaps waiting a couple more years until the
>>>
>>> Java world became more receptive to the idea would have made it possible
>>>
>>> to do it right at once?
>>
>> AFAIK Java8 lambdas are somewhat less verbose wrappers around
>> anonymous inner classes. When I saw that closure vars inside Java8
>> lambdas are final my first thought was that obviously Java is from now
>> on on maintenace and that's it. The language Java won't evolve any
>> more. I guess things will just stay like that from now on as the case
>> for Cobol or something. The focus will be on tools, framewors,
>> systems, etc. as it already has been for a while I fear ...
>>
>
> That is very likely, unfortunately. Personally I can live with that
> since I only use Java for legacy purposes and have done so for about
> five years now. Over 95% of the Java code I dive into now and then is
> even pre-1.5 (you know, casts, raw types, etc.).
>
> But Java does not only serve a role as the status quo language for the
> JVM. It is also the most prominent arena where the new kids arrive.
> Unless one or some of the alternative JVM languages take over that role
> the JVM will (and already has) become less and less compelling to the
> rock-stars to be. The university I once attended now uses C# as the
> language for its primary entry level programming course. That used to be
> Java (not in my time of course, I learned programming with Algol68) ...
>

Of course I didn't, I learnt programming with Algol68...

[toc] | [prev] | [next] | [standalone]

#26696

On Friday, November 29, 2013 12:51:41 PM UTC+1, Saxo wrote:
> Am Freitag, 29. November 2013 12:05:37 UTC+1 schrieb Silvio:
> 
> > The current lambdas are an obvious compromise between people who would 
> > have welcomed more far fetched closure semantics and syntax versus 
> > people who where opposed to adding closures in the first place. That is 
> > understandable but I doubt having partial closures is better than not 
> > having them at all. I think it is unlikely that the current lambdas will 
> > evolve into full closures. Perhaps waiting a couple more years until the 
> > Java world became more receptive to the idea would have made it possible 
> > to do it right at once?
> 
> AFAIK Java8 lambdas are somewhat less verbose wrappers around anonymous inner classes. When I saw that closure vars inside Java8 lambdas are final my first thought was that obviously Java is from now on on maintenace and that's it. The language Java won't evolve any more. I guess things will just stay like that from now on as the case for Cobol or something. The focus will be on tools, framewors, systems, etc. as it already has been for a while I fear ...

The problem with "real" closures (i.e. the ones you can write to) is that they require a dramtic change in the underlying mechanics: you need to keep stack frames around for longer than a method call.  Having that in Java would be really nice but the potential for impact on the huge basis of existing code is severe.  I personally like the simplified anonymous classes approach because it is a pragmatic step forward: you get to use anonymous functions with far less visual overhead than before.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web