Java Lambda Question

[clay]

Java 8 is finally getting anonymous first class functions which is a feature that has already existed in many (most?) other JVM languages such as Scala for many years.

One big difference is that Java 8 is using invokedynamic method handles and sacrifices Java 6 backward compatability while the other JVM languages stick with Java 6 friendly byte code.

I've seen some presentation slides arguing that invokedynamic methodhandles are a better implementation. Now, that we can download a Java 8 build with lambda support and run our own tests, can I see any of the benefits of the new JVM features used by Java 8 over something like Scala which sticks with strictly JDK 6 byte code? Is there a certain type of benchmark that I can run that demonstrates the advantages?

[Jon Kiparsky]

On Mon, Oct 1, 2012 at 6:25 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

One big difference is that Java 8 is using invokedynamic method handles and sacrifices Java 6 backward compatability

Every major Java release sacrificed backward compatibility, so it will be business as usual.

I don't think this is true, is it? Is there anything that compiles, say, under Java 4 and won't compile under 5,6, or 7?

I mean, it would have made sense to require parameterization of generics. The only reason that wasn't done - the only reason you can still declare

ArrayList al = new ArrayList();

is to preserve backwards compatibility. 

[Cédric Beust ♔]

On Mon, Oct 1, 2012 at 7:38 PM, Jon Kiparsky <jon.ki...@gmail.com> wrote:

On Mon, Oct 1, 2012 at 6:25 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

One big difference is that Java 8 is using invokedynamic method handles and sacrifices Java 6 backward compatability

Every major Java release sacrificed backward compatibility, so it will be business as usual.

I don't think this is true, is it?

It's not.

-- 

Cédric

[Josh Berry]

I think we are confusing forward compatibility with backwards
compatibility. Most major releases have introduced something that
would not compile under a previous release. All releases can run
things that were valid in a previous release. Not guaranteed to
compile, as assert used to not be a keyword, but by and large this is
the case. (I don't recall all of the exceptions.)

[Fabrizio Giudici]

On Tue, 02 Oct 2012 05:21:06 +0200, Josh Berry <tae...@gmail.com> wrote:

> I think we are confusing forward compatibility with backwards
> compatibility. Most major releases have introduced something that
> would not compile under a previous release. All releases can run
> things that were valid in a previous release. Not guaranteed to
> compile, as assert used to not be a keyword, but by and large this is
> the case. (I don't recall all of the exceptions.)

Definitely. Java is mostly backward compatible and I feel Java 8 will be
the first exception.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Andreas Petersson]

Am 02.10.2012 10:36, schrieb Fabrizio Giudici:
>
> Definitely. Java is mostly backward compatible and I feel Java 8 will
> be the first exception.

Is there any particular reason a java 8 compiler woudl be unable to emit
bytecode (with a -target parameter) that is backwards-compatible?
couldn't the compiler just emit anonymous classes instead of invokedynamic?

[Matthew Farwell]

Is there any technical reason? Given that

adding the option to create anonymous classes as well as invokedynamic would certainly make the compiler more complex;

using invokedynamic will almost certainly be more efficient in terms of .class files generated & probably execution;

and Oracle would probably want to push people to use the latest JVM (it is 99% backward compatible after all)

I see this as being a reasonable choice. But obviously, I don't know anything :-) Of course, any particular compiler is free to implement lambdas however it wants.

Matthew Farwell.

2012/10/2 Andreas Petersson <and...@petersson.at>

Am 02.10.2012 10:36, schrieb Fabrizio Giudici:

Definitely. Java is mostly backward compatible and I feel Java 8 will be the first exception.

Is there any particular reason a java 8 compiler woudl be unable to emit bytecode (with a -target parameter) that is backwards-compatible? couldn't the compiler just emit anonymous classes instead of invokedynamic?

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

Coming from the other direction, I'd be very surprised if other JVM languages don't begin offering a solution based on invokedynamic once Java 8 adoption takes off.

Given that Oracle will be optimising the VM for this pattern in particular, the benefits in terms of size, performance, and interop are hard to ignore.

[Matthew Farwell]

I don't know of anything that doesn't compile, but I've found a few things that exhibit different behaviour. The best example is the static initialisation of classes. Using the following example:

package foo;

public class FooTest {

  public static class Foobar {

    static {

      System.out.println("hello world");

    }

  }

  public static void main(String args[]) {

    System.out.println("Foobar=" + Foobar.class);

  }

}

The 1.4 class for FooTest will invoke the static initialiser for Foobar and do the println, but the 1.6 will not. This is using the same JVM and javac, only varying the -source and -target: that is the emitted bytecode varies. I assume that this change was deliberate, but it confused me at the time when I came across it :-)

Matthew Farwell.

2012/10/2 Jon Kiparsky <jon.ki...@gmail.com>

[Ricky Clarkson]

You 'feel' that it won't be backward compatible?  I like reasons, do you have any of those or only feelings?

[Simon Ochsenreither]

I don't think this is true, is it?

Every version of Java has incremented the class file version and classes compiled for a newer version won't run on older versions.
So you can't use a version of javac supporting lambdas and target an older version. (javac has the target argument, but that's more or less useless for this usecase because it it requires a source argument with the same version number.)

To do some sensible real-world measurements you would need

a) a corpus of code, in which lambdas are used idiomatically (this probably means a lot more frequent than with the current AIC syntax)
b) a compiler which understands lambdas and ...
c) ... would be able to generate classfiles with both the new class file version and the old class file version.

This is not possible currently with javac, and I don't see that changing for 8. (There is a chance that Retroweaver or a similar tool would add support for 8, though...)

A more degenerate usecase would be to measure with a 1.6-compatible corpus first, and then refactor it to use lambdas ... but I guess any results gained from that would be highly debatable.

I think clay's best bet is to use scalac as soon as the backend for 8 is available, because scalac doesn't suffer from the other restrictions and you can easily target different class file versions while using the current features.

[Ricky Clarkson]

Incidentally, I'm (very slowly) doing that refactor in a fork of Functional Java.  Unfortunately FJ uses classes instead of interfaces and unlike the BGGA prototype Java 8 lambdas can only target interface types.  I'm replacing final instance methods with Java 8 defender methods, and moving static methods to separate classes.

If you instead test it using scala, the scalaz library and Scala's parser combinators currently generate more .class files than you could shake a stick at.

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/kM5TMeZm2xwJ.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[clay]

I will be disappointed if all these anticipated JVM enhancements offer no measurable or noticeable improvement to Java 8 over current versions of Scala.

The only advantage I see is that the byte code is cleaner and doesn't need as many internal Java class files like what Scala generates. This sounds quite minor by itself.

Personally, I don't care about supporting older Java runtimes, but I expect the Java team to put out something better than what other languages like Scala and Groovy have shipped on the JVM many years ago.

I have another lambda question for this group, but I'll put that in another thread.

[Simon Ochsenreither]

I will be disappointed if all these anticipated JVM enhancements offer no measurable or noticeable improvement to Java 8 over current versions of Scala.

Well, I think there are chances for some minor optimizations due to not having to carry around all the class baggage and its semantics.

The only advantage I see is that the byte code is cleaner and doesn't need as many internal Java class files like what Scala generates. This sounds quite minor by itself.

Yes, that's pretty much it.

Personally, I don't care about supporting older Java runtimes, but I expect the Java team to put out something better than what other languages like Scala and Groovy have shipped on the JVM many years ago.

That's not planned. For the last decade, the JVM changes have been more along the line of “what's the most minimal thing to do to prevent the feature gap to the CLR from getting even more embarrassing”.

[Cédric Beust ♔]

On Tue, Oct 2, 2012 at 8:15 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

“what's the most minimal thing to do to prevent the feature gap to the CLR from getting even more embarrassing”.

The CLR is hardly ever a consideration in Java directions. The main concerns are much more along the lines of offering as much added value while preserving backward compatibility, two objectives that are, sadly, very strongly at odds with each other.

-- 

Cédric

[Casper Bang]

On Tuesday, October 2, 2012 6:00:50 PM UTC+2, Cédric Beust ♔ wrote:

The CLR is hardly ever a consideration in Java directions. The main concerns are much more along the lines of offering as much added value while preserving backward compatibility, two objectives that are, sadly, very strongly at odds with each other.

I think it's a crying shame the Java space has been so conservative, to this day I still don't get why we Sun/Oracle didn't go all in with a lean next-gen replacement to remain relevant and give C# some competition.

The bulk of the remaining talent pool in the Java space seems to revolve around Android, which we have the courts word for isn't even technically Java. Gone from this mainsteam Java space are Neal Gafter, Guy Steele, Gilad Bracha, Joshua Bloch, Martin Odersky, Bill Venners, Michael Nygard, Mads Torgersen, Peter von der Ahé etc. Even SpringSource's Rod Johnson just joined Scala.

[Kevin Wright]

I'm with Cédric here, Sun and Oracle alike both had to tow the line for their most profitable support contract holders, investment banks.

For their part, the banks largely showed a level of risk aversion that makes Beaker from the Muppets look like Chuck Norris - paying *vast* sums of money to ensure that nothing moves much beyond 1.3 (in case something broke) except for *critical* bug/security fixes.  As a result, the language is largely stagnant and most improvements to Java have happened within the JVM - which is now so good that a great many other languages want to run on top of it.

My personal feeling is that Oracle should capitalise on this, and work to add features to the JVM to support Scala, Clojure, Groovy, Mirah, etc.  Playing to their strengths instead of playing catch-up with languages that are better seen as collaborators and not competition.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Russel Winder]

On Tue, 2012-10-02 at 17:58 +0100, Kevin Wright wrote:
> I'm with Cédric here, Sun and Oracle alike both had to tow the line for
> their most profitable support contract holders, investment banks.
>
> For their part, the banks largely showed a level of risk aversion that
> makes Beaker from the Muppets look like Chuck Norris - paying *vast* sums
> of money to ensure that nothing moves much beyond 1.3 (in case something
> broke) except for *critical* bug/security fixes. As a result, the language
> is largely stagnant and most improvements to Java have happened within the
> JVM - which is now so good that a great many other languages want to run on
> top of it.
>
> My personal feeling is that Oracle should capitalise on this, and work to
> add features to the JVM to support Scala, Clojure, Groovy, Mirah, etc.
> Playing to their strengths instead of playing catch-up with languages that
> are better seen as collaborators and not competition.

Whilst investment banks have a reputation for being ultra conservative
and eschewing all upgrades, at least two international investment banks
I know of are throwing out their Java systems and replacing them with
small Scala core and Python everywhere else. Another is replacing the
large Java system with a small Java core and Python out in the business
units. There will be other case studies.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[clay]

I think everyone would agree that Java has been very slow to evolve relative to just about everything else.

However, Is the CLR ahead of the JVM? Really? Is C# ahead of Java? How so?

The big important features that C# has that Java 7 lacks are already in Java 8: concise, first class functions, functional enhancements to collections, sane date/time api. I suspect Java 8 might even leap frog C# on the latter two  items.

C# has other small plusses over Java that I like, but they aren't deal breakers: multi-line string literals, no checked exceptions, value types aka structs, better handling of nullable primitives, declaration side covariance/contravariance of generic classes (where generic types are declared as in/out). Output parameters are also a small plus.

On the flip side, as far as language features and elegance go, Scala really trumps both Java and C# by a large margin.

I like the fact that JVM has Java as kind of a simpler, stabler option and Scala as the more progressive, elegant option. This reminds me of the early days of .NET, when Microsoft offered VB.NET as the more entry level option and C# for the more serious programmer. In reality, VB.NET was just a less efficient dialect of C# and there wasn't really a good reason to use it. With Java/Scala, I think there are more good reasons to use each language.

Also, I like the culture/community of the JVM far more than that of the .NET. The JVM has a more open, academic like culture, where people constantly debate and choose what they feel is the best product language/ide/build tool/test framework/web framework/etc. On the .NET side, there is more unquestionable loyalty to everything Microsoft. Even when Scala/Clojure ship on .NET, there is much less openness to considering anything non-Microsoft on it's technical merit.

[Fabrizio Giudici]

On Tue, 02 Oct 2012 12:12:29 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> You 'feel' that it won't be backward compatible? I like reasons, do you
> have any of those or only feelings?

"Feel" because honestly I still don't understand what will be in and out,
and which decisions are final or not. I suppose that being the week of J1
there will be some final word soon (maybe there has already been, but I'm
not in SF and this week I can't follow blog posts live).

[Fabrizio Giudici]

On Tue, 02 Oct 2012 18:57:31 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> I think it's a crying shame the Java space has been so conservative, to
> this day I still don't get why we Sun/Oracle didn't go all in with a lean
> next-gen replacement to remain relevant and give C# some competition.

It's still our old story: given that Java may be slowly declining, but
it's still much more spread than C# (BTW, the latest Tiobe says that ObjC
is 3rd and passed C#), perhaps Sun and Oracle made (mostly) the right
choices.

[Simon Ochsenreither]

I first typed my response to your comments, but it looks that it became more of a rant about the current state of the Java ecosystem. So nothing against you, clay, your response just caused me to vent my deep frustration about the willfull ignorance, the anti-intellectualism, and the denial of reality which has spread through some parts of the Java ecosystem.

I think everyone would agree that Java has been very slow to evolve relative to just about everything else.

However, Is the CLR ahead of the JVM? Really? Is C# ahead of Java? How so?

 

Yes, feature-wise they are years apart (unified type system, meta-object protocol, tail calls, generics, assembly system, ...).

HotSpot's garbage collector is way more sophisticated, as well as HotSpot's JIT compiler.
Sadly, those don't really translate into any clear performance benefits, because .NET's approach is completely different in this regard:
Their language features/compiler are designed to do most of the work upfront, so their JIT compiler has to do magnitudes less:

For instance, the whole notion of dynamic recompilation doesn't exist in the CLR. Their JITter runs once, before execution, that's it. (It can also run AOT.)

As another example, their implementation of Generics might make it hard for alternative languages to run on the CLR and interface with existing assemblies, but from a performance/memory point of view it combines the strength of C++'s model with the advantages of having a runtime to generate the appropriate specializations on demand. (Scala can do some specialization at compile-time, but without any help from the JVM it is painful, bug-prone and complicated to actually manage to trigger the JVM's fast path.

The .NET/language team has managed -- by carefully designing their language to not require extensive runtime-analysis -- to avoid the need for sophisticated runtime services (compared to the JVM) to achieve more or less comparable performance and a lot less memory consumption.

Generally, if running Eclipse on top of IKVM on top of the CLR has lower memory consumption AND faster startup time than "the usual way" and this is not even raising the eye brow of the "Java community" I really wonder what can ...

The big important features that C# has that Java 7 lacks are already in Java 8: concise, first class functions, functional enhancements to collections, sane date/time api. I suspect Java 8 might even leap frog C# on the latter two items.

 

There is a lot more to it (properties, type inference, better Generics and associated overloading/inheritance, tuples, unsigned numbers, better native interop and tons of other stuff). Considering the last two: C# had those collection methods for years already and has put them to great usage (LINQ), while Java will only get the most basic implementation at the end of 2013 (which will be basically useless for implementing some LINQ-style abstraction).
The Date&Time stuff will be an improvement over the available libraries on .NET, though.
 

C# has other small plusses over Java that I like, but they aren't deal breakers: multi-line string literals, no checked exceptions, value types aka structs, better handling of nullable primitives, declaration side covariance/contravariance of generic classes (where generic types are declared as in/out). Output parameters are also a small plus.

 

The non-existance of structs is one of the reasons (the need for complex GC/JIT/optimizer infrastructure is another one) why Java is such a memory hog (which is one of the major complaint of people having to use stuff written for the JVM). Also, it is crippling all the data structure implementations: Either you implement your data structure in terms of arrays or you will suffer from the 20/80 split (20% data, 80% overhead).
Even worse, this is an issue no JIT compiler can solve.
 

On the flip side, as far as language features and elegance go, Scala really trumps both Java and C# by a large margin.

 

I praise your optimism, but if I see how some "senior Java developers" which never used the language start hyperventilating in their blog posts as soon as someone mentions Scala, and how every three months a new "slightly improved, slightly different Java" is announced with great fanfare (and failing to deliver anything valuable afterwards) I'm not sure many people in the Java community have realized this.

For some people, Scala is great when they can show that their ecosystem is not ten years behind .NET, but as soon as senior developers feel that their "seniority" is threatened they get _very_ angry about the language.

First the usual "OMG Java Joe will NEVER understand this!!!!!!" (although .NET developers have coped with magnitudes higher complexity (look at C#, just look at it; or read the spec if you don't believe me)).
Then the bogus "OMG, I found a method signature I don't understand" while failing to mention that achieving the same semantics in Java is just completely impossible (and would probably require bytecode assembly, annotation preprocessing or hacking javac itself).

Also, I like the culture/community of the JVM far more than that of the .NET. The JVM has a more open, academic like culture, where people constantly debate and choose what they feel is the best product language/ide/build tool/test framework/web framework/etc.

 

I don't see much of this anymore. I guess the constant anti-intellectualism drove many people away. The .NET side at least listens to their language designers and engineers ... just look at F#. The newest version will revolutionize the way developers will be able to use external data sources like databases and web services. If they will decide to integrate it in C# too, it will be a black day for the whole Java ecosystem.
Even NET's current line-up of libraries and tools, the whole out-of-the-box experience is years ahead of the state of the art in the Java ecosystem.

On the Java side, we have bizarro bullshit approaches like JDBC, raw SQL, code generation, JPA, and a ton of other ugly, half-assed non-solutions to problems which shouldn't have existed in the first place.

On the .NET side, there is more unquestionable loyalty to everything Microsoft.

At least they manage to ship things in time, not ten years late. Even if the current Java stewards would actually decide to work on Java/the JVM again, I see no way they wouldn't spend the next ten years playing catch-up (just look at their roadmap if you want to get depressed). Compare that to what's happening in .NET currently: async in C#/F#, the whole Roslyn project or F# type providers.

Maybe the Java community really needs some "the platform is burning" memo to wake up, stop their self-congratulatory circle-jerk, look at what's happening outside their bubble and decide to start working again on stuff that actually matters.

(To those people you will immediately respond with something along the lines of "but Java is the most popular language", "look at TIOBE" or "Java will be used for ever": you're missing the point, completely.)

I really hope this can be turned around, and I'm counting on you guys! :-)

[Fabrizio Giudici]

On Tue, 02 Oct 2012 22:11:19 +0200, Simon Ochsenreither
<simon.och...@gmail.com> wrote:

> *I first typed my response to your comments, but it looks that it became

> more of a rant about the current state of the Java ecosystem. So nothing
> against you, clay, your response just caused me to vent my deep
> frustration
> about the willfull ignorance, the anti-intellectualism, and the denial of

> reality which has spread through some parts of the Java ecosystem.*

Quickly said, I'm a practical guy. I start reasoning from facts. This is
the n+1 post which says C# ecosystem is way ahead on Java. And sure there
are many objective points like those you mentioned.

Still, I repeat myself, and I don't see any stat which shows that C# usage
is superior than Java. C# seems to be passed by ObjC. I'm sorry to repeat
things like rain man, but I usually stop repeating my questions only when
I see an answer. So far, zero answers. Right? So, perhaps all that
technology superiority doesn't sell a lot. Either perhaps because it
sounds good, but in practice it doesn't bring so much value. Or because
it's more complex and people don't like it. Or because Microsoft's world
is so closed and people prefer the open stuff. Or, please give me another
explanation (oh, and please, let us understand how the C# ecosystems deals
with databases in a different way than JPA, provided that JPA is not the
only approach of Java to the problem).

For what concerns "Java seniors who hyperventilate about Scala", please
don't make me laugh. We're not in the middle age, Java seniors don't hold
any power in controlling the world and the fact that new technology
players, when they have the proper cards, can turn the world upside down
in a few years (see Apple iOS and Google Android) only means that there's
competition and the propagation of news can't be prevented by people
hyperventilating (I only imagine how many people hyperventilated at Nokia,
and Nokia died all the way). So, if Scala is so much hype and then zero
penetration, the problem perhaps lies in another place. That is: it's
really complex and most developers have already problems properly using
Java, because they lack OO knowledge and skills. Seniors just understand
that putting mediocre drivers into the seat of a Ferrari is just the
perfect recipe for a crash. Scala is for elites and elites, as usual,
don't understand the real world. It's like Mac OS X developers, hey look
at J1 and Devoxx top people use Mac OS X for Java development, but in the
real world it's just less than 10%, and Windows is used much more than
Linux. So many times the real world is different than theoretical
predictions.

Not a rant, of course, just a reality check IMO. :-)

[Simon Ochsenreither]

After reading that response I'm not sure whether you have actually read what I wrote.
Most of the stuff you say was actually explicitly addressed in my comment already and some of the stuff is more or less beating down a straw man build up from things I never said.

Isn't it quite ironic that people claim that Java is the more "academic" ecosystem, when – as soon as some technical points are brought up – someone immediately attacks with the same, sore, old business-pov/popularity/from-authority response?

[Fabrizio Giudici]

It's not an attack: it's the reality check that says that in academia you
discuss about what's the better technology on paper, outside academia you
discuss about what's the better technology in the sense that sells more.
Nothing more, nothing less. Frankly, I'm still amazed by the fact that, if
I was in your side, I'd be the first to ask myself: hell, but given that
"my" stuff is better, why isn't selling more? Instead, I don't see the
question, I don't see the answer and only the reiteration about that
technology is still the better one.

For the record I've read your whole post twice, and it was long - with a
reason, because you had many points - mine is shorter, that is just a
couple of questions, did you read them? You're not answering, might I know
why? :-)

[Ricky Clarkson]

Selling more has little to do with being better, get that out of your head.  You're Italian, right?  Starbucks sells more than Italian coffee shops, but is not better in any meaningful way (perhaps more comfortable chairs).

Our competitor sells more than us, we both sell developer-hours.  In fact they win big because their projects with the same client are behind and ours aren't, so they get to charge more overtime.  Which is better?  I'd say we are, we're delivering on time or early, and from what I can gather, better quality.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Fabrizio Giudici]

On Tue, 02 Oct 2012 23:21:17 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Selling more has little to do with being better, get that out of your
> head.
> You're Italian, right? Starbucks sells more than Italian coffee shops,
> but is not better in any meaningful way (perhaps more comfortable
> chairs).

It's a matter of market targets. Almost the whole rest of the world
doesn't know what coffee means, or - better - give to the word "coffee" a
different meaning - and they are hundreds of millions of customers versus
a few dozens of italians. But, figure it out, Starbucks gave up opening
shops in Italy. It's not a comparable example, because there are no big
geographic differences in the popularity of Java vs C#.

In any case, I'm perfectly aware that selling is not necessarily related
to being better, and it's exactly part of my point. Either you think that
this lack of causation is a matter of the cynical fate, or you try to find
out a rationale. Found a rationale, you try to fight the cause. The only
rationale I've seen so far is blaming the Java seniors. So, what? Are you
going to wait for all of them to retire?

[Kevin Wright]

In related news:

"Vitamin Water" outsells Laurent-Perrier vintage Rosé

"Turkey ham" outsells Jamón Serrano

Pre-cut sandwich-size processed cheese squares outsell Parmigiano Reggiano

Wal-mart sells more suits than both Paul Smith and Armani combined

McDonalds outsell every Michelin-starred restaurant, ever

Cattle-class outsell first-class plane tickets by a wide margin

160Kbps MP3s outsell both FLAC and AAC lossless recordings

Apple headphones seen in many more train carriages than Shure 535s

Crickets and mealworms make up less that 0.01% of protein consumption in the US, mechanically-recovered connective tissue continues to be more popular.

Is it really fair to say that outside of academia, that only way we compare things is on the basis of popularity or profitability?  My experience in so many things is that the better option is the LESS popular one.  Sometimes this is down to cost, but just as often it's simply resistance to change and fear-aversion.  And cost really isn't an issue in most non-Microsoft programming languages, even operational costs are zero when changing from Java to something else on the same VM.

p.s. Yes, I have eaten insects.  They're very healthy, and taste a bit like prawns or popcorn, depending on the insect and how it's cooked.

[Simon Ochsenreither]

It's not an attack: it's the reality check that says that in academia you  
discuss about what's the better technology on paper, outside academia you  
discuss about what's the better technology in the sense that sells more.  
Nothing more, nothing less.

 

Maybe that's the reason why this mailing list has become such an ghetto.
There seems to be no chance to have a sensible, constructive debate about technical topics without people thinking they have to do "reality checks" on other people (and think that's "OK"?).

In my opinion, you're not even trying to participate constructively, you make up non-rational requirements instead to kill of discourse. Basically, every technology would need to get more "popular" than Java before you would assess it's technical benefits and disadvantages? Is that right? That's basically what I gather from your comments.

 

You're not answering, might I know why? :-)

Because I prefer to stay on topic.
I try to have an intellectual debate, while you try to turn it into some sort of popularity contest, which I'm – clearly, as indicated – not interested in.

[Ricky Clarkson]

> The only rationale I've seen so far is blaming the Java seniors.

Perhaps I should tell you why I'm not using Scala (and why I have done in other jobs) in my workplace today.  It's not related to Java seniors in any way.

Current job: Management don't like variety, if we switch to Scala we'd have to port everything that's in Java today to Scala, and that's too risky.  I was denied the use of IDEA (which I'm using anyway, shh!!) for the same reason; in the past somebody had caused a production error and that error was wrongly traced back to a slightly different version of Eclipse between two developers.  Therefore, thou must use the same version of the same IDE as the next guy, and each project must be written the same way as the next.

The people called seniors in the client don't even spell Java properly and don't know what Scala is, though I can see that other parts of the same company do use Scala without any problems.

Previous job: Direct management liked Scala but it was a little less mature back then so we restricted it to unit testing (specs is excellent) and small standalone projects.  Top management barely approved of Java, everything else in the company was straight C.  Given that their core business was hardware, that wasn't too shocking.  I had "Java and Scala Programmer" in my email signature but I doubt the top brass ever read that far down.

Job before that: I got bored in a project that only had users for 4 months a year and learned Scala by porting the project to it in the 8 quiet months.  I made some big software engineering mistakes there and learned more about how (not) to run software projects than I did about Scala.  My manager didn't care what it was written in as long as I could make stuff work.

Incidentally, the current job is project-based and I'm putting myself forward for a Scala project with a different client when this project comes to a close at the end of the year.  It's not all downhill!

[Ricky Clarkson]

I disagree that it's a ghetto, but there's certainly scope for improvement.

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/V_q-cLtzTkUJ.

[clay]

- Better Generics: Java lacks reified generics in that it discards type info at runtime. I agree that this is a deficiency of Java, but the practical consequences of this seem quite obscure. Sure C# can do List<int> faster than a Java List<Integer>, but int[] goes much faster in both languages, and most super performance sensitive code uses that. Other language features have more tangible benefits.

- Properties: The getter/setter practice of Java is horrendous. C# has first class properties which is better. Scala is even better, in that it eliminates the getter/setter boilerplate and doesn't even need a special property mechanism, you can just use val/var/def.

- Unsigned integers: I know there are some use cases, particularly in hashing and cryptography, where you really want a 32/64-bit unsigned int. Java 8 has library functions to address this which can hypothetically be properly optimized to give full performance benefit. It's still slightly nicer to have native unsigned primitives in C#, but practically Java 8 is fine.

The above three, to me feel like tired language wars points, by people who are already emotionally dead set of liking C# and hating Java, but in reality, these points don't have large practical implications and are trivial to work around.

- Tail Call Optimization: OK, this is important and Java is behind on this one. Scala has this however.

- Tuples: I looked at the new .NET 4.0 tuples in the standard library, and those aren't any different than any third party tuple library on Java. Scala and others have more native, language level tuples.

"On the Java side, we have bizarro bullshit approaches like JDBC, raw SQL, code generation, JPA, and a ton of other ugly, half-assed non-solutions to problems which shouldn't have existed in the first place."

Tons of Java technologies were terrible in hindsight or have been replaced by something much better. The .NET landscape is absolutely no different. In my personal experience, Java devs are more quick to say, the official product is bad, let's use something better, while .NET developers are more likely to stick with and defend the official product. For example, most Java devs rightfully hated JSF and used another alternative (Play looks great today). In the .NET world, tons of developers used and defended Visual SourceSafe until a few years ago: ugh!

- LINQ: I've used LINQ when I was doing C#, but I am no expert. Could you articulate what this does better than Java 8? Is it really years ahead? Most LINQ examples I see on the Internet can be translated into Java 8's functional collections (I'm not sure about join type operations) and the latter syntax is more intuitive/natural. Also, for external database access, typesafe's slick looked like a better solution at a superficial level (I haven't actually had the chance to use it yet).

- F#: I haven't used it, but I've heard great things about F#, and I suspect they are right. This sounds like a more academic, thinking man's programming language and that's not what the typical Joe C# dev wants. I've talked to several C# exclusive shops and interest in F# was very low. Secondly, I couldn't get this running on Mono on my Linux dev system and F# clearly isn't the Mono team's priority. On Microsoft forums, most people said to just use OCaml if you don't want to set up a Windows VM. Ocaml is on my todo list, along with deeper forays into Haskell, but if F# is just a .NET flavor of Ocaml, I can just stick with the latter.

"Maybe the Java community really needs some "the platform is burning" memo to wake up, stop their self-congratulatory circle-jerk..."

In my observations, even Java developers hate Java :) Or are at best luke warm about it. The last problem in the Java community is over-confidence :) There are several people in this Java forum who constantly talk about how terrible Java is. I don't see anything close to that type of self-loathing over on C# forums and I don't think that's due to product quality.

"Isn't it quite ironic that people claim that Java is the more "academic" ecosystem, when – as soon as some technical points are brought up – someone immediately attacks with the same, sore, old business-pov/popularity/from-authority response?"

That's not ironic at all. I use Python a lot because of all the great libraries and the community built up around it. I don't even think Python the language itself is terribly special. It's the same with Java. You have made some technical points against Java, several of which I agree with, but I still like the libraries, community, etc. I don't care about the TIOBE index or that kind of mass market.

BTW, I really like Java as a tool for some use cases, but I don't think I'm irrational about it. I use a lot of Python (numpy/scipy type stuff) and JavaScript for web stuff. I'm also trying to invest more learning energy on science/engineering knowledge rather than programming languages. I'd rather understand some new machine learning or data processing papers or engineering skills rather than learn a new programming language feature. However, the latter is more fun and entertaining. It's like a break from the hard stuff.

[Simon Ochsenreither]

Hi clay,

- Better Generics: Java lacks reified generics in that it discards type info at runtime. I agree that this is a deficiency of Java, but the practical consequences of this seem quite obscure.

 

The practical consequence is that for example an ArrayList with one million doubles takes up 28MB instead of 8MB (and that's just on a 32bit VM). While some might argue that RAM can be considered infinite these days, CPU cache sadly isn't. Imagine the performance improvements if an ArrayList could guarantee that its values are stored in one chunk! I certainly would prefer living without > 70% memory overhead for the simplest use-cases (it gets much worse with stuff like Tree{Set,Map} or collections of ConcurrentHashMaps).

Sure C# can do List<int> faster than a Java List<Integer>, but int[] goes much faster in both languages, and most super performance sensitive code uses that. Other language features have more tangible benefits.

 

The issue at least in Java is that arrays don't work well with pretty much any other language feature. They are no collection, they don't interoperate with Generics, they don't follow the variance rules, etc etc etc.
I don't want to use a feature which most Java designers/JVM engineers consider more or less deprecated.
 

- Properties: The getter/setter practice of Java is horrendous. C# has first class properties which is better. Scala is even better, in that it eliminates the getter/setter boilerplate and doesn't even need a special property mechanism, you can just use val/var/def.

 

Pretty much agree.
 

- Unsigned integers: I know there are some use cases, particularly in hashing and cryptography, where you really want a 32/64-bit unsigned int. Java 8 has library functions to address this which can hypothetically be properly optimized to give full performance benefit. It's still slightly nicer to have native unsigned primitives in C#, but practically Java 8 is fine.

 

Yes, I don't care about them too much.

The above three, to me feel like tired language wars points, by people who are already emotionally dead set of liking C# and hating Java,

 

I don't really have any opinion about that. Java is conceptually a much nicer, smaller, simpler language, but if I had to get work done (and everything else wouldn't matter), I would choose C# immediately, because it is much more pragmatic about getting things done.
 

but in reality, these points don't have large practical implications and are trivial to work around.

 

The missing struct/reified generics issue can't be worked around at all, and the consequences are huge. 

- Tail Call Optimization: OK, this is important and Java is behind on this one. Scala has this however.

 

Not really. Or more precisely: Only in some limited cases known at compile time. If you don't want to fall back to trampolining (and suffer from poor interop and performance) you really need VM support for this.
Considering that Schwaighofer already implemented it for interpreter, client _and_ server compiler while preserving the existing security mechanisms years ago and that the patchset was even updated to track JVM changes (as far as I remember) I really wonder how far down it lives on the priority list.

Nevertheless, it is possible to live without it. In the beginning, the CLR did have some pretty severe restrictions on TCO, too.
 

- Tuples: I looked at the new .NET 4.0 tuples in the standard library, and those aren't any different than any third party tuple library on Java. Scala and others have more native, language level tuples.

 

The issue is that there isn't any standardization around it in Java, so its use is pretty much restricted to isolated islands. Same issue with function types.
 

"On the Java side, we have bizarro bullshit approaches like JDBC, raw SQL, code generation, JPA, and a ton of other ugly, half-assed non-solutions to problems which shouldn't have existed in the first place."

Tons of Java technologies were terrible in hindsight or have been replaced by something much better. The .NET landscape is absolutely no different. In my personal experience, Java devs are more quick to say, the official product is bad, let's use something better, while .NET developers are more likely to stick with and defend the official product.

 

I guess the difference is that Microsoft listens to feedback and is open to considerable improvements and changes to their libraries without needing tons of people telling them exactly that for years. See for example how the Entity Framework came to live and where it is now. The disadvantage of that is that it sometimes looks like as if Microsoft reinvents their approach to e. g. ORM every second year. They move fast and they leave people behind, and they are not really upfront about it.

Apart from that, there are also alternatives like Dapper, NHibernate, etc. which interoperate quite nicely where it matters.

 

- LINQ: I've used LINQ when I was doing C#, but I am no expert. Could you articulate what this does better than Java 8? Is it really years ahead?

 

The issue is that Java is missing the infrastructure in the compiler to lift the closures to an AST representation for further processing. Without this, it is hard to translate the arguments given to the collection methods to SQL or some other representation.
You could probably write some tool to analyze the generated bytecode, but tooling would suffer from that. C#'s LINQ isn't perfect though, because the lifting is shallow, which means that for instance references to external methods will fail at runtime (as far as I remember) because no lifted representation exists/was generated for them. That has a certain impact on re-use, but LINQ is still magnitudes better than the burning trainwrecks of JPQL or the Criteria API.

One of the seldom glimpses of sanity I have seen in the Java ecosystem lately was JOOQ, which relies heavily on code generation though.
 

Most LINQ examples I see on the Internet can be translated into Java 8's functional collections (I'm not sure about join type operations) and the latter syntax is more intuitive/natural. Also, for external database access, typesafe's slick looked like a better solution at a superficial level (I haven't actually had the chance to use it yet).

 

Yes, Slick does a lot things right and has all the necessary infrastructure available to also solve the rest properly, but imho there is still a long way to go. Nevertheless, I'm still waiting for type macros, because it's 2012 and I can't seriously imagine that I'm writing code to describe database tables (or use code generation) when the database has _all_ the necessary information already available. I guess this will be the next case of bigotry where some mechanism to solve a huge, real-world issue is perfectly fine in one language (F#) and totally "OMG so complex!!!!!!!" in another (Scala). :-)

 

- F#: I haven't used it, but I've heard great things about F#, and I suspect they are right. This sounds like a more academic, thinking man's programming language and that's not what the typical Joe C# dev wants. I've talked to several C# exclusive shops and interest in F# was very low. Secondly, I couldn't get this running on Mono on my Linux dev system and F# clearly isn't the Mono team's priority. On Microsoft forums, most people said to just use OCaml if you don't want to set up a Windows VM. Ocaml is on my todo list, along with deeper forays into Haskell, but if F# is just a .NET flavor of Ocaml, I can just stick with the latter.

Yes, that's my impression, too. I also had issues getting it to run on Mono. I guess it gets a bit more easier after the 3.0 release.
It is impressive to watch how they manage to ship useful, practical, but conceptually advanced features without anyone declaring Jihad on them. I really wish something like this could be pulled off in the Java ecosystem...
(Some of the stuff is also a bit scary though, like the possibility to use inline CIL bytecode instructions in source code.)
 

In my observations, even Java developers hate Java :) Or are at best luke warm about it. The last problem in the Java community is over-confidence :) There are several people in this Java forum who constantly talk about how terrible Java is. I don't see anything close to that type of self-loathing over on C# forums and I don't think that's due to product quality.

 

But on the other side, you just saw how some people try every tactic possible to shut constructive discussion down on this list. :-) In the end, I think the .NET people are a bit more oriented towards getting things done, because Microsoft gets things done. But we are stuck with discussing the same thing over and over because on the large scale, big O didn't get much done apart from incrementing version numbers.
 

Nice day!

Simon

[Russel Winder]

On Tue, 2012-10-02 at 15:38 -0700, clay wrote:
> - Better Generics: Java lacks reified generics in that it discards type
> info at runtime. I agree that this is a deficiency of Java, but the
> practical consequences of this seem quite obscure. Sure C# can do List<int>
> faster than a Java List<Integer>, but int[] goes much faster in both
> languages, and most super performance sensitive code uses that. Other
> language features have more tangible benefits.

Are you sure int[] goes "much faster"? Define "much"? I bet the
difference in performance between ArrayList<Integer> and int[] in Java 7
and Java 8 is a lot less than you might suggest based on Java 1.0. No
measurement, no conclusion.

[…]

> - Tuples: I looked at the new .NET 4.0 tuples in the standard library, and
> those aren't any different than any third party tuple library on Java.
> Scala and others have more native, language level tuples.

I have no idea about .NET, but tuples in Python are great. Multiple
values returned from methods/functions. Immutable struct literals.
Fabulous stuff.

[…]

>
> - F#: I haven't used it, but I've heard great things about F#, and I
> suspect they are right. This sounds like a more academic, thinking man's
> programming language and that's not what the typical Joe C# dev wants. I've
> talked to several C# exclusive shops and interest in F# was very low.
> Secondly, I couldn't get this running on Mono on my Linux dev system and F#
> clearly isn't the Mono team's priority. On Microsoft forums, most people
> said to just use OCaml if you don't want to set up a Windows VM. Ocaml is
> on my todo list, along with deeper forays into Haskell, but if F# is just a
> .NET flavor of Ocaml, I can just stick with the latter.

F# is OCaml without a GIL. If you are interested in real parallelism,
you do not want OCaml. I suspect F# use on .NET will win out over C# use
over time.

> "Maybe the Java community really needs some "the platform is burning" memo
> to wake up, stop their self-congratulatory circle-jerk..."

The JVM is platform is far from burning in the sense of being destroyed.
Java, Scala, Groovy, JRuby, Jython, Clojure, Kotlin, Ceylon. The JVM
itself is hosting a vibrant ecosystem. The danger is that every person
using it will write their own language. There lies destruction.

On the other hand JavaOne does appear to be a self-congratulatory
circle-jerk. Especially given the appallingly few numbers of women
there. The real question is how to get software development up to 40% or
50% women.

> In my observations, even Java developers hate Java :) Or are at best luke
> warm about it. The last problem in the Java community is over-confidence :)
> There are several people in this Java forum who constantly talk about how
> terrible Java is. I don't see anything close to that type of self-loathing
> over on C# forums and I don't think that's due to product quality.

The average Java programmer doesn't actually care as long as they get
paid. Far too many people working with Java do not think about what
they are doing and don't care.

> "Isn't it quite ironic that people claim that Java is the more "academic"
> ecosystem, when – as soon as some technical points are brought up – someone
> immediately attacks with the same, sore, old
> business-pov/popularity/from-authority response?"
>
> That's not ironic at all. I use Python a lot because of all the great
> libraries and the community built up around it. I don't even think Python
> the language itself is terribly special. It's the same with Java. You have
> made some technical points against Java, several of which I agree with, but
> I still like the libraries, community, etc. I don't care about the TIOBE
> index or that kind of mass market.
>
> BTW, I really like Java as a tool for some use cases, but I don't think I'm
> irrational about it. I use a lot of Python (numpy/scipy type stuff) and
> JavaScript for web stuff. I'm also trying to invest more learning energy on
> science/engineering knowledge rather than programming languages. I'd rather
> understand some new machine learning or data processing papers or
> engineering skills rather than learn a new programming language feature.
> However, the latter is more fun and entertaining. It's like a break from
> the hard stuff.

Nothing wrong with Python.

[Casper Bang]

I think you have a lot of good points Simon, many of which I have raised in the past as well. It's an unhealthy self-righteous which causes people to see things black or white, rather than the nuances in between.

I'll just add another small example of where C# proves to be catering to "getting things done" compared to Java; working with base-10 decimals. It's such a common everyday scenario, to have to work with amounts and percentages and bugs are introduced if relying on IEEE-754 semantics. While Java provides a complex, verbose and error-prone class BigDecimal, C# provides a language literal up front. To make matters worse, this is the sort of thing that Java could've been burned into the syntax-sugar part of the parser a long time ago.

[Russel Winder]

On Tue, 2012-10-02 at 21:07 +0200, Fabrizio Giudici wrote:
> On Tue, 02 Oct 2012 18:57:31 +0200, Casper Bang <caspe...@gmail.com>
> wrote:
>
> > I think it's a crying shame the Java space has been so conservative, to
> > this day I still don't get why we Sun/Oracle didn't go all in with a lean
> > next-gen replacement to remain relevant and give C# some competition.

Because JetBrains have Kotlin, RedHat have Ceylon, there is Scala,
Groovy, JRuby, Jython, Clojure, and yet Java is what the average
programmer writes.

> It's still our old story: given that Java may be slowly declining, but
> it's still much more spread than C# (BTW, the latest Tiobe says that ObjC
> is 3rd and passed C#), perhaps Sun and Oracle made (mostly) the right
> choices.

Navel gazing of this sort is not constructive. I care about getting
software-based things that actually work and do not have brain-dead user
interfaces and user experiences. 90% of programmers couldn't design a UI
with good UX is a century of Sunday's. Witness all the f###### crap we
get as Web applications. I have yet to find any "shopping site" – all
written using Java or ASP.NET – that is anything other than a real pain
to use. I got beyond caring about programming language hegemony long
ago. Now I care about the rubbish that is forced onto society by the
average programmer.

[Casper Bang]

On Wednesday, October 3, 2012 10:55:29 AM UTC+2, Russel wrote:

Because JetBrains have Kotlin, RedHat have Ceylon, there is Scala, 
Groovy, JRuby, Jython, Clojure, and yet Java is what the average
programmer writes.

The Java ecosystem is notorious for sucking at coming up with standards and requiring people to come up with their own solutions. This used to apply at the framework/library level, now it has expanded to the language level. That's great for hobby projects and cultivating intellectual curiosity, but most medium sized companies/organizations require standards and long-term trustworthiness. Unfortunately, this pushes companies over on .NET and Windows, especially when they get fed the integration (SharePoint, Axapta/NAV etc.) sales pitch.

[Kevin Wright]

On 2 October 2012 23:38, clay <clayt...@gmail.com> wrote:

- Better Generics: Java lacks reified generics in that it discards type info at runtime. I agree that this is a deficiency of Java, but the practical consequences of this seem quite obscure. Sure C# can do List<int> faster than a Java List<Integer>, but int[] goes much faster in both languages, and most super performance sensitive code uses that. Other language features have more tangible benefits.

This isn't about reification, it's about boxing.  Scala already demonstrates that manifests can be just as effective as reification, and fortess had a nice alternative too (before it was canned).  The performance and memory benefit of Arrays wouldn't be achieved through reification, but with jvm-native structs/tuples and something akin to John Rose's fixnum proposal

 

- Unsigned integers: I know there are some use cases, particularly in hashing and cryptography, where you really want a 32/64-bit unsigned int. Java 8 has library functions to address this which can hypothetically be properly optimized to give full performance benefit. It's still slightly nicer to have native unsigned primitives in C#, but practically Java 8 is fine.

Screw the unsigned int, I want unsigned bytes!  These have been sorely missed by anyone doing hardware I/O or network protocol stuff.  You can expect the issue to come up again if we ever see a significant number of people hacking over the GPIO of a Raspberry PI using Java...

 

- Tail Call Optimization: OK, this is important and Java is behind on this one. Scala has this however.

Sadly limited, and can make debugging difficult.  burning it into the JVM would be far more effective.

 

- Tuples: I looked at the new .NET 4.0 tuples in the standard library, and those aren't any different than any third party tuple library on Java. Scala and others have more native, language level tuples.

They can be stack-allocated, and elements inside such a tuple don't need to be boxed.  This is a *significant* difference!

 

- LINQ: I've used LINQ when I was doing C#, but I am no expert. Could you articulate what this does better than Java 8? Is it really years ahead? Most LINQ examples I see on the Internet can be translated into Java 8's functional collections (I'm not sure about join type operations) and the latter syntax is more intuitive/natural. Also, for external database access, typesafe's slick looked like a better solution at a superficial level (I haven't actually had the chance to use it yet).

Without extractors, pattern-matching, some form of flatMap/bind operation, etc. the lambdas in Java 8 are a level of abstraction below Scala and LINQ.  And that's before we even start considering Futures, Options, etc. which can also take advantage of the same monadic operations.

 

- F#: I haven't used it, but I've heard great things about F#, and I suspect they are right. This sounds like a more academic, thinking man's programming language and that's not what the typical Joe C# dev wants. I've talked to several C# exclusive shops and interest in F# was very low. Secondly, I couldn't get this running on Mono on my Linux dev system and F# clearly isn't the Mono team's priority. On Microsoft forums, most people said to just use OCaml if you don't want to set up a Windows VM. Ocaml is on my todo list, along with deeper forays into Haskell, but if F# is just a .NET flavor of Ocaml, I can just stick with the latter.

"Maybe the Java community really needs some "the platform is burning" memo to wake up, stop their self-congratulatory circle-jerk..."

In my observations, even Java developers hate Java :) Or are at best luke warm about it. The last problem in the Java community is over-confidence :) There are several people in this Java forum who constantly talk about how terrible Java is. I don't see anything close to that type of self-loathing over on C# forums and I don't think that's due to product quality.

"Isn't it quite ironic that people claim that Java is the more "academic" ecosystem, when – as soon as some technical points are brought up – someone immediately attacks with the same, sore, old business-pov/popularity/from-authority response?"

That's not ironic at all. I use Python a lot because of all the great libraries and the community built up around it. I don't even think Python the language itself is terribly special. It's the same with Java. You have made some technical points against Java, several of which I agree with, but I still like the libraries, community, etc. I don't care about the TIOBE index or that kind of mass market.

BTW, I really like Java as a tool for some use cases, but I don't think I'm irrational about it. I use a lot of Python (numpy/scipy type stuff) and JavaScript for web stuff. I'm also trying to invest more learning energy on science/engineering knowledge rather than programming languages. I'd rather understand some new machine learning or data processing papers or engineering skills rather than learn a new programming language feature. However, the latter is more fun and entertaining. It's like a break from the hard stuff.

On Tuesday, October 2, 2012 3:11:19 PM UTC-5, Simon Ochsenreither wrote:

I first typed my response to your comments, but it looks that it became more of a rant about the current state of the Java ecosystem. So nothing against you, clay, your response just caused me to vent my deep frustration about the willfull ignorance, the anti-intellectualism, and the denial of reality which has spread through some parts of the Java ecosystem.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/NVYbE2hxl30J.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

On Tuesday, October 2, 2012 10:36:49 AM UTC+2, fabrizio.giudici wrote:

On Tue, 02 Oct 2012 05:21:06 +0200, Josh Berry <tae...@gmail.com> wrote:

Definitely. Java is mostly backward compatible and I feel Java 8 will be  
the first exception.

This doesn't make much sense to me, but perhaps I'm missing something. To wit:

* All javacs, from 1.1 to 1.7, all retained the ability to compile 'old' code (code written for e.g. java 1.4 compiled on a javac 1.6), and emit bytecode which does the same thing, but only runs on more modern JVMs. This did occasionally cause warnings (such as a billion raw types warnings when compiling j1.4 code with j1.5 without -source 1.4), and, in rare cases, did not work at all (assert keyword). As far as I know, Java 8 will be no different!

* All javacs, from 1.1 to 1.7, all retained the ability to fully emulate old compilers by settings source, target, and bootclasspath to the older version. In rare cases this does not work (yes, no java release has ever truly been backwards compatible, but in cases which wouldn't come up except in extremely strange situations, usually where the old code was pretty much guaranteed to be buggy or at least intentionally written to cause issues). As far as I know, Java 8 will be no different!

* All javacs, from 1.1 to 1.7, DO NOT emit bytecode which is capable of running on a JVM associated with a previous version. In this sense javac8 will not be 'backwards compatible' but then **NO JAVAC EVER** can make that claim. You can use -target X to change this, but you can't mix -source Y and -target X where Y exceeds X, and this has been true for as far as I know all javacs. There was a special third party tool which could take 1.5 class files (compiled with generics) and mix them down to 1.4 versioned class files that still worked, so that you could write code with generics and compile it into class files that would run on JVM 1.4s. This was NOT written or endorsed by Sun.

In conclusion: What makes java 8 so special here?

[Josh Berry]

On Wed, Oct 3, 2012 at 8:14 AM, Reinier Zwitserloot <rein...@gmail.com> wrote:
> On Tuesday, October 2, 2012 10:36:49 AM UTC+2, fabrizio.giudici wrote:
>
>> On Tue, 02 Oct 2012 05:21:06 +0200, Josh Berry <tae...@gmail.com> wrote:
>>
>> Definitely. Java is mostly backward compatible and I feel Java 8 will be
>> the first exception.
>>
>
> This doesn't make much sense to me, but perhaps I'm missing something. To
> wit:

So, I had to go back and make sure I didn't actually say that. This
being essentially the point I was alluding to in my snippet. Much
more thoroughly (and clearly) made, though. :)

I haven't followed up afterwards to clear up what I meant, though,
since it looked like that point was touched by others before I saw my
direct responses.

[clay]

Reinier Zwitserloot, you are correct regarding inter-version compatability. I just think there was some confusion.

Kevin, "[C# tuples] can be stack-allocated, and elements inside such a tuple don't need to be boxed.  This is a *significant* difference!"

.NET tuples are reference type classes, not structs. AFAIK, they can not stack allocated. Sure, C# can use primitives without boxing, which is the generics issue we talked about separately.

Russel, "tuples in Python are great." Python and Scala and many others have full proper tuple syntax and integration. C# and Java do not. C# has several advantages over Java, but I don't think this is one of them.

"The average Java programmer doesn't actually care as long as they get paid."

I don't think you can single out Java in this regard. This probably applies to most salaried employees to some extent.

"Are you sure int[] goes "much faster"? Define "much"?"

Ok, I will try this out.

Simon, "The issue at least in Java is that arrays don't work well with pretty much any other language feature. They are no collection, they don't interoperate with Generics, they don't follow the variance rules, etc etc etc. I don't want to use a feature which most Java designers/JVM engineers consider more or less deprecated."

Scala addresses this point far better than C#/Java. Scala provides Array[Int] which performs identically to Java int[] but integrates with the rest of the language as you describe. I've personally benchmarked Scala Array[Int] and found it performed equivalently to Java int[].

Kevin, "Without extractors, pattern-matching, some form of flatMap/bind operation, etc. the lambdas in Java 8 are a level of abstraction below Scala and LINQ.  And that's before we even start considering Futures, Options, etc. which can also take advantage of the same monadic operations."

Java 8 has a flatMap. So does C#, but it is called SelectMany. Java also has a Future class. Option is a whole separate issue and on that Java/C# use plain null while Scala/F# use Option. You are all over the place.

Simon, It sounds like you are saying that LINQ solves external database integration better than JPA/Hibernate (I completely agree). But LINQ isn't really much different than ECMAScript or Java 8 or Scala for local functional collection processing.

"The Java ecosystem is notorious for sucking at coming up with standards and requiring people to come up with their own solutions. This used to apply at the framework/library level, now it has expanded to the language level. That's great for hobby projects and cultivating intellectual curiosity, but most medium sized companies/organizations require standards and long-term trustworthiness. Unfortunately, this pushes companies over on .NET and Windows, especially when they get fed the integration (SharePoint, Axapta/NAV etc.) sales pitch."

"In the end, I think the .NET people are a bit more oriented towards getting things done, because Microsoft gets things done."

There are the worker, builder, "git 'er done" types: immediate, concrete, tangible, simple results.

There are the intellectuals: long learning curves, more abstract ideas, more about finding better ways of doing things and innovation rather than merely churning out quantities of work tickets.

I'm trying to move more towards the latter group.

[clay]

On Wednesday, October 3, 2012 3:48:35 AM UTC-5, Russel wrote:

Are you sure int[] goes "much faster"? Define "much"? I bet the
difference in performance between ArrayList<Integer> and int[] in Java 7
and Java 8 is a lot less than you might suggest based on Java 1.0. No
measurement, no conclusion.

 

With current JDK 8 build on my Linux x64 box:

Primitive test n=1.0e+06 completed in 0.108 seconds

ArrayList test n=1.0e+06 completed in 1.804 seconds

That difference is absolutely huge. About to try the same thing with C#/Mono.

Source Code:

import java.util.ArrayList;

public class ArrayTest {

public static void benchmark(String name, Runnable runnable) {

long start = System.nanoTime();

runnable.run();

long stop = System.nanoTime();

long delta = stop - start;

double seconds = ((double) delta) / 1000000000.0;

System.out.println(String.format("%s completed in %.3f seconds", name, seconds));

}

public static void main(String[] args) {

final int n = 1000000;

testWithPrimitiveArray(n);

testWithArrayList(n);

}

public static void testWithPrimitiveArray(final int n) {

benchmark(String.format("Primitive test n=%6.1e", (double) n), new Runnable() {

@Override

public void run() {

final int[] a = new int[n];

// Do something with the array...

for (int i = 0; i < n; i++) {

a[i] = i;

}

for (int k = 0; k < 100; k++) {

for (int i = 0; i < n; i++) {

a[i] = a[n-1-i] * 2;

}

}

}

});

}

public static void testWithArrayList(final int n) {

benchmark(String.format("ArrayList test n=%6.1e", (double) n), new Runnable() {

@Override

public void run() {

final ArrayList<Integer> a = new ArrayList<Integer>(n);

// Do something with the array...

for (int i = 0; i < n; i++) {

a.add(i);

}

for (int k = 0; k < 100; k++) {

for (int i = 0; i < n; i++) {

a.set(i, a.get(n-1-i) * 2);

}

}

}

});

}

}

[clay]

C#/Mono results:

Primitive test n=1000000 completed in 0.2528684 seconds

ArrayList test n=1000000 completed in 1.0193116 seconds

Quick + Dirty Interpretation:

C# int[] is dramatically faster than List<int>, even with the lack of boxing. In this one-off benchmark, List<int> took ~4x the time.

Also interesting, Java int[] ran much faster than C# int[]. I assume the Linux JDK is simply faster than the Mono runtime for array processing.

As expected, C# List<int> ran significantly faster than Java List<Integer> presumably due to boxing issues. The Java version took ~1.8x the time.

I can also benchmark Scala again if anyone wants (I've done this before). Array[int] matches Java int[] performance and gives you full language integration and consistency. In other words, the best of both worlds.

Code:

using System;

using System.Collections.Generic;

using System.Diagnostics;

namespace CollectionsTest

{

public delegate void Runnable();

public class ArrayTest

{

public static void benchmark(String name, Runnable runnable) {

Stopwatch stopWatch = new Stopwatch();

stopWatch.Start();

runnable();

stopWatch.Stop();

Console.WriteLine("{0} completed in {1} seconds", name, stopWatch.Elapsed.TotalSeconds);

}

public static void Main(string[] args) {

const int n = 1000000;

testWithPrimitiveArray(n);

testWithArrayList(n);

}

public static void testWithPrimitiveArray(int n) {

benchmark(String.Format("Primitive test n={0}", n), () => {

int[] a = new int[n];

// Do something with the array...

for (int i = 0; i < n; i++) {

a[i] = i;

}

for (int k = 0; k < 100; k++) {

for (int i = 0; i < n; i++) {

a[i] = a[n-1-i] * 2;

}

}

});

}

public static void testWithArrayList(int n) {

benchmark(String.Format("ArrayList test n={0}", n), () => {

List<int> a = new List<int>(n);

// Do something with the array...

for (int i = 0; i < n; i++) {

a.Add (i);

[clay]

Scala Results:

Scala Array Test and for loops. n=1.0e+06 completed in 0.961 seconds

Scala Array Test and while loops. n=1.0e+06 completed in 0.130 seconds

This is with Scala 2.10-M7 and JDK 7u7.

First, obvious gotcha. whlie loops run *way* faster than for loops with ranges in Scala. I thought they were fixing that optimization issue in 2.10.

Second, Scala Array[Int] took ~1.3x as long as Java int[]. I thought Scala was much closer from my older benchmarks. Maybe that's a JDK 7/8 difference? I don't feel like running that right now.

Code:

package scalatest

object ArrayTest {

def benchmark(name: String, runnable: () => Unit): Unit = {

val start: Long = System.nanoTime();

runnable();

val stop = System.nanoTime();

val delta = stop - start;

val seconds: Double = delta.asInstanceOf[Double] / 1000000000.0;

println("%s completed in %.3f seconds".format(name, seconds));

}

def main(args: Array[String]): Unit = {

val n = 1000000;

testWithScalaArrayAndFor(n);

testWithScalaArrayAndWhile(n);

}

def testWithScalaArrayAndFor(n: Int): Unit = {

benchmark("Scala Array Test and for loops. n=%6.1e".format(n.asInstanceOf[Double]), () => {

val a = new Array[Int](n);

// Do something with the array...

for (i <- 0 until n) {

a(i) = i;

}

for (k <- 0 until 100) {

for (i <- 0 until n) {

a(i) = a(n-1-i) * 2;

}

}

});

}

def testWithScalaArrayAndWhile(n: Int): Unit = {

benchmark("Scala Array Test and while loops. n=%6.1e".format(n.asInstanceOf[Double]), () => {

val a = new Array[Int](n);

// Do something with the array...

var i: Int = 0;

while (i < n) {

a(i) = i;

i += 1;

}

var k: Int = 0;

while (k < 100) {

i = 0;

while (i < n) {

a(i) = a(n-1-i) * 2;

i += 1;

}

k += 1;

}

});

}

}

[clay]

OK, I couldn't help myself: reran Java test code on JDK7. Wow:

Java 8 Primitive test n=1.0e+06 completed in 0.108 seconds

Java 8 ArrayList test n=1.0e+06 completed in 1.804 seconds

Java 7 Primitive test n=1.0e+06 completed in 0.165 seconds

Java 7 ArrayList test n=1.0e+06 completed in 1.908 seconds

C#/Mono Primitive test n=1000000 completed in 0.2528684 seconds

C#/Mono ArrayList test n=1000000 completed in 1.0193116 seconds

Scala Array Test and for loops. n=1.0e+06 completed in 0.961 seconds

Scala Array Test and while loops. n=1.0e+06 completed in 0.130 seconds

Two big surprises for me:

Scala Array[Int] + JDK7 actually ran significantly *faster* than Java 7 int[]

JDK8 int[] runs much faster than JDK7 int[]. I figured the big optimizations on simple tasks were already realized long ago.

"Generally, if running Eclipse on top of IKVM on top of the CLR has lower memory consumption AND faster startup time than "the usual way" and this is not even raising the eye brow of the "Java community" I really wonder what can ..."

This is absolutely raising my eyebrows. I am surprised to hear that. I would be interested into more specifics of what is causing the difference there.

I feel the same sentiment though in reverse. Why are so many people, even in a Java group, pointing out how much faster C# is with integer arrays, when benchmarks indicate the exact opposite?

BTW, from memory, Microsoft CLR on Windows which is much faster than the Mono CLR, but Java JDK is faster than both on these types of tests (int[] performance)

[Ricky Clarkson]

Ignore anything these benchmarks tell you other than maybe any 10:1 or similar ratios.  You're not accounting for JVM warmup and you're biasing the benchmark towards the second item to run in each main by simply running it second.  You will get lots of accidental odd results like this.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/t_L_SXSOfTsJ.

[Casper Bang]

I feel the same sentiment though in reverse. Why are so many people, even in a Java group, pointing out how much faster C# is with integer arrays, when benchmarks indicate the exact opposite?

I feel tempted to say something about the uselessness of micro-benchmarks on a managed runtime, and yet somehow attracted to dive into the matter. However before doing so, you should make multiple runs, cut away the best 25% and the worst 25% and average the result. Then normalize your numbers to make it comparable across platforms. Also, how about coming up with a real problem less susceptible to compiler/JIT short-circuits, i.e. finding primes via % and use array/list as cache? This would also allow Scala enthusiasts start beating the concurrency drum.

[Kevin Wright]

If you're serious about running micro-benchmarks like this, you want to use something like Google's caliper (http://code.google.com/p/caliper/) - It does a very good job of handling things like warm-up properly.

Also, if performance is critical, avoid both the for-comprehension/loop entirely and go straight to recursion (do not pass Go, do not collect $200).  Make sure it's tail-recursive.

If the task is big enough and performance is even more critical, consider running using ScalaCL (http://code.google.com/p/scalacl/) so that it can run in parallel across however many cores you have in your GPU.  As always, the overhead in doing anything like this will more than outweigh the gain if the "work" is trivial.

On 3 October 2012 17:10, Ricky Clarkson <ricky.c...@gmail.com> wrote:

Ignore anything these benchmarks tell you other than maybe any 10:1 or similar ratios.  You're not accounting for JVM warmup and you're biasing the benchmark towards the second item to run in each main by simply running it second.  You will get lots of accidental odd results like this.

On Wed, Oct 3, 2012 at 1:08 PM, clay <clayt...@gmail.com> wrote:

OK, I couldn't help myself: reran Java test code on JDK7. Wow:

Java 8 Primitive test n=1.0e+06 completed in 0.108 seconds

Java 8 ArrayList test n=1.0e+06 completed in 1.804 seconds

Java 7 Primitive test n=1.0e+06 completed in 0.165 seconds

Java 7 ArrayList test n=1.0e+06 completed in 1.908 seconds

C#/Mono Primitive test n=1000000 completed in 0.2528684 seconds

C#/Mono ArrayList test n=1000000 completed in 1.0193116 seconds

Scala Array Test and for loops. n=1.0e+06 completed in 0.961 seconds

Scala Array Test and while loops. n=1.0e+06 completed in 0.130 seconds

Two big surprises for me:

Scala Array[Int] + JDK7 actually ran significantly *faster* than Java 7 int[]

JDK8 int[] runs much faster than JDK7 int[]. I figured the big optimizations on simple tasks were already realized long ago.

"Generally, if running Eclipse on top of IKVM on top of the CLR has lower memory consumption AND faster startup time than "the usual way" and this is not even raising the eye brow of the "Java community" I really wonder what can ..."

This is absolutely raising my eyebrows. I am surprised to hear that. I would be interested into more specifics of what is causing the difference there.

I feel the same sentiment though in reverse. Why are so many people, even in a Java group, pointing out how much faster C# is with integer arrays, when benchmarks indicate the exact opposite?

BTW, from memory, Microsoft CLR on Windows which is much faster than the Mono CLR, but Java JDK is faster than both on these types of tests (int[] performance)

--

[clay]

Micro-benchmarks are statistics, and of course, you can angle your benchmark to tell whatever story you want. Yes, this stuff is subject to various tricks and short-circuits

OTOH, You can drown out anything with enough skepticism and if you are so emotionally entrenched, you can refuse to believe anything.

I believe my benchmarks were meaningful in a small way. If you refuse to believe them, I'm not going to labor an argument further.

the guys over here: http://shootout.alioth.debian.org/. put a *ton* of time into polishing these types of micro-benchmarks and still they aren't remotely perfect. I don't have the motivation to sink that much time + effort into that.

[Fabrizio Giudici]

On Tue, 02 Oct 2012 23:54:35 +0200, Simon Ochsenreither
<simon.och...@gmail.com> wrote:

>
>
>> It's not an attack: it's the reality check that says that in academia
>> you
>>
>> discuss about what's the better technology on paper, outside academia
>> you
>>
>> discuss about what's the better technology in the sense that sells more.
>> Nothing more, nothing less.
>
> Maybe that's the reason why this mailing list has become such an ghetto.
> There seems to be no chance to have a sensible, constructive debate about
> technical topics without people thinking they have to do "reality checks"
> on other people (and think that's "OK"?).

You seem to talk as a lawyer at a trial, moving the target playing with
words. Sorry, this is my honest impression. I've asked for a reality
checks of *facts*, the main being that C# is less popular than Java. You
have moved the discussion to reality check on people, which is not clearly
my intention.

>
> In my opinion, you're not even trying to participate constructively, you
> make up non-rational requirements instead to kill of discourse.

I'm putting questions and you aren't answering. Guess who's not
participating constructively?

> Basically,
> every technology would need to get more "popular" than Java before you
> would assess it's technical benefits and disadvantages? Is that right?

No, it's not what I'm saying. I'm saying that if a technology has got
benefits, but doesn't get popular, a reasonable theory (among others) is
that most people don't think those benefits are so relevant (you might
propose alternate theories, it's what I've asked, and you didn't reply).
Sure, the conservative attitude of decision-makers, most of which tend to
be conservative, doesn't help, but I say this can cause delays rather than
full stops. Hell, I've experienced a lot of conservative people ten years
ago that opposed to the introduction of Java (or C#) defending C++ or C,
but those resistances proved to be futile. If this isn't happening again,
there must be other reasons.

I've read for instance how the thread went on the branch about benchmarks
of int[] and such. Interesting, but at the moment I don't know any
customer who needs to work with an array of millions of floats, thus
considering those benchmarks relevant for picking C# (not counting the
fact that, in the rare case I got one, a specific, optimized
implementation backed by float[] would probably perform well, even though
of course it wouldn't be a perfect fit with other collections).

Of course it could be plain ignorance of people, but while I reckon that
most people are ignorant of the existence of Scala, this is not true about
C#. I can't recall anybody who knows Java and doesn't know that at least
C# exist.

> I try to have an intellectual debate, while you try to turn it into some
> sort of popularity contest, which I'm – clearly, as indicated – not
> interested in.

The popularity *is* the topic, because I think that if I propose a new
technology I want to change the world, not just praise my group because
we're so smart, too bad the rest of the world can't catch up. Now,
comparing technologies by benchmarking doesn't make much sense (of course
it depends on benchmarks and we're talking about micro-benchmarks). If I
read that Akka does massive amounts of transactions, that's a different
kind of benchmark and I'm more interested in it. You are starting with the
pre-assumption that those Java limitations are life changers. I'm saying
that I first look what people do and figure out that those needs are the
life changer. So, rather than benchmarks I'd like to see real-world
stories where people say "We dropped Java and moved to C# because we
couldn't do that". I'm not seeing much about that, because the net average
measurement of these trends is - figure out - popularity.

PS In a post here from yesterday I've read about people moving to
"smaller" Java systems and Python. Not C#. And how does Python do
benchmarks on millions of floats? Or perhaps what people appreciated is a
different thing? I'd be happy to know by the OP more details on this.

[Fabrizio Giudici]

On Wed, 03 Oct 2012 14:14:15 +0200, Reinier Zwitserloot
<rein...@gmail.com> wrote:

> not work at all (assert keyword). As far as I know, Java 8 will be no
> different!

Let's first reset the discussion and have a check on a piece of
information of mine that I'm probably getting wrong. I'm still assuming
Java 8 will do generics reification. Is this right?

> * All javacs, from 1.1 to 1.7, DO NOT emit bytecode which is capable of
> running on a JVM associated with a previous version. In this sense javac8

There's something I don't understand here. I can use JDK 6 (I suppose JDK
7, not tried yet) to generate code for Android, which is Java 5. Just a
matter of --source --target, right?

> will not be 'backwards compatible' but then **NO JAVAC EVER** can make
> that
> claim. You can use -target X to change this, but you can't mix -source Y
> and -target X where Y exceeds X, and this has been true for as far as I
> know all javacs.

Let's define my concept of backward-compatible in this scenario. I'm a
corporate, I have a large codebase in Java 6 (for instance). My upgrade to
JAva 7 will be incremental and made by a path such as:

1. I move to JDK 7 with --source --target 6 and check whether it runs on
JDK 6. Eventually I fix things so this happens.
2. Then I check whether the thing runs on JDK 7. Eventually I fix things
so this happens. At this point I'm mostly happy, since the biggest trouble
with Java 6 is when it goes EOL. Now I'm on a runtime that is still
getting patches.
3. I now move to --source --target 7. Eventually I fix things so this
happens.
4. At this point, I can incrementally start using features of Java 7.

"Fix things so this happens" admits that I have some work to do, if this
work is very well confined I still call it (practical) backward
compatibility of a new JDK. Perhaps I'm using the wrong term?

[Fabrizio Giudici]

> 1. I move to JDK 7 with --source --target 6 and check whether it runs on
> JDK 6. Eventually I fix things so this happens.
> 2. Then I check whether the thing runs on JDK 7. Eventually I fix things
> so this happens. At this point I'm mostly happy, since the biggest
> trouble with Java 6 is when it goes EOL. Now I'm on a runtime that is
> still getting patches.
> 3. I now move to --source --target 7. Eventually I fix things so this
> happens.
> 4. At this point, I can incrementally start using features of Java 7.
>
> "Fix things so this happens" admits that I have some work to do,

Forgot to specify: I'm happy whether steps #1 and #2 aren't too much
expensive, because I could have a timeframe to respect. Once I've
satisfied step #2, I'm more relaxed on time planning #3 and #4.

[Ricky Clarkson]

No, Java 8 is not expected to reify generics.  Even if it were there are ways of doing that without breaking backward compatibility.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

[Fabrizio Giudici]

On Wed, 03 Oct 2012 20:23:43 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> No, Java 8 is not expected to reify generics. Even if it were there are
> ways of doing that without breaking backward compatibility.

So I retire my prediction about Java 8 to break compatibility, that was
related to this point. Just out of curiosity, reified generics are planned
for Java 9 or postponed without any plan for now?

[Martijn Verburg]

Tentatively scheduled for 9 or 10 - I'd prefer to see 9 personally but appreciate its a non trivial change ;-)

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Kevin Wright]

IIRC, reification is on the "long term" schedule, for somewhere between versions 10 and 14

[Cédric Beust ♔]

On Wed, Oct 3, 2012 at 12:14 PM, Martijn Verburg <martijn...@gmail.com> wrote:

Tentatively scheduled for 9 or 10 - I'd prefer to see 9 personally but appreciate its a non trivial change ;-)

But why? I'm still struggling to find out why some people feel so strongly about the importance of reified generics. If you spend some time thinking about the implications and costs of reified generics, you actually realize that the need is rare and that even in such situations, type literals (or similar) can get you very far, and that erasure comes with many more pros and less cons than reified generics do.

I captured these thoughts in this article a while ago, I'd love to hear if your use case for reified generics is not covered there.

-- 

Cédric

[Martijn Verburg]

Hi Cedric,

I confess I am actually torn.  I'm a big fan of polyglot and reified generics could throw a spanner in the works for this. We had a fun discussion with Charlie (JRuby) Martin (Scala), Jeff (Gosu) and Ola about this last year.

Counter point is that I feel that type erasure generics breaks the principle of least surprise for the day to day developer.

I always harp on about empirical evidence, so I really should set up a workshop and have developers try out both types and see what their feedback is. :)

Food for thought - thanks for triggering it!

Cheers,

Martijn

[Cédric Beust ♔]

Fair enough, let us know if you reach any interesting conclusions!

-- 

Cédric

[Fabrizio Giudici]

On Wed, 03 Oct 2012 22:39:13 +0200, Cédric Beust ♔ <ced...@beust.com>
wrote:

> On Wed, Oct 3, 2012 at 12:14 PM, Martijn Verburg
> <martijn...@gmail.com>wrote:
>
>> Tentatively scheduled for 9 or 10 - I'd prefer to see 9 personally but
>> appreciate its a non trivial change ;-)
>
>
> But why? I'm still struggling to find out why some people feel so
> strongly
> about the importance of reified generics. If you spend some time thinking
> about the implications and costs of reified generics, you actually
> realize
> that the need is rare and that even in such situations, type literals (or
> similar) can get you very far, and that erasure comes with many more pros
> and less cons than reified generics do.
>
> I captured these thoughts in this

> article<http://beust.com/weblog/2011/07/29/erasure-vs-reification/>a

> while ago, I'd love to hear if your use case for reified generics is
> not
> covered there.

I pretty much agree with you. So I'm more relaxed knowing that it probably
won't ever happen (because, guys, saying after Java 10 today means well
beyond the horizon).

I presume this statement makes me much more of a Java senior lobbyist,
doesn't it?

[Kevin Wright]

On top of this, reification forces you to even some aspect of your type system at the byte code let level.

Imagine if Java already had reified generics, then decided to add declaration-site inheritance in the style of C# or Scala. It wouldn't be possible.

The same goes for any new type system, such as dependent types or the union types proposed for Scala v3. You'd be out of luck!  Farewell to potential future innovation...

[Ricky Clarkson]

I think the main driver is to retain the illusion that everything is discoverable at runtime and that bytecode looks like source code in certain ways.

I personally am not bothered either way on this, but I know people often run up against the limitation.  In fact, any generic warning or error that a programmer doesn't understand is often misattributed to erasure.

Scala shows that you don't need reification to allow primitives as type parameters, however Scala also goes to lengths with its Manifests to let you get at the original types that I do wish it would present that as reification and not make you have to see any Manifest use in source.

I wouldn't see reification as a disaster for Java if it did arrive, not sure whether Fabrizio is basing this on reason or feelings again.

[Ricky Clarkson]

I think you mean variance, not inheritance.  And didn't that change happen to C# between 2 and 3 or 3 and 4, the addition of in and out in type parameter declarations?

If it happened for C#, and C# uses reified types, then reification in Java shouldn't be a reason the same type system change would be impossible for Java.

[Kevin Wright]

I'm fairly convinced that once Scala enables pattern-matching to transparently use any relevant manifests in scope, coupled with context bounds for passing Manifests around, then we'll have solved all the main use-cases for reification.

Something like:

def method[T : Manifest](xs: List[T]) = xs match {

  case List[String] => doSomething

  case List[Int] => doSomethingElse

  case _ => sys.error("Unexpected type: " + manifest[T].erasure) 

}

[Kevin Wright]

On 3 October 2012 22:43, Ricky Clarkson <ricky.c...@gmail.com> wrote:

I think you mean variance, not inheritance.  And didn't that change happen to C# between 2 and 3 or 3 and 4, the addition of in and out in type parameter declarations?

Yup, I did. Not sure I can get away with blaming that one on autocorrect either :)

 

If it happened for C#, and C# uses reified types, then reification in Java shouldn't be a reason the same type system change would be impossible for Java.

It would be tricky if Java had already codified use-site variance at the bytecode level, then subsequently moved to add declaration-site variance.  Not impossible, just challenging.

--

[mP]

Simon,

The easiest measure that shows Java is advanced, is the shear inbalance of NET projects that are ports of Java libraries. It seems a lot of people appreciate and value these commodities and thats why they port them. There is very little in comparison going the other way. All numbers are relative, but cannot be disputed that many of the cool libraries on NET came from Java. Java itself has also copied ideas, ports etc from other places, but IMHO its obvious who is in front of whom

htq.

mP

On Wednesday, October 3, 2012 1:15:22 AM UTC+10, Simon Ochsenreither wrote:

I will be disappointed if all these anticipated JVM enhancements offer no measurable or noticeable improvement to Java 8 over current versions of Scala.

Well, I think there are chances for some minor optimizations due to not having to carry around all the class baggage and its semantics.

The only advantage I see is that the byte code is cleaner and doesn't need as many internal Java class files like what Scala generates. This sounds quite minor by itself.

Yes, that's pretty much it.

Personally, I don't care about supporting older Java runtimes, but I expect the Java team to put out something better than what other languages like Scala and Groovy have shipped on the JVM many years ago.

That's not planned. For the last decade, the JVM changes have been more along the line of “what's the most minimal thing to do to prevent the feature gap to the CLR from getting even more embarrassing”.

[Fabrizio Giudici]

On Wed, 03 Oct 2012 23:38:07 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:


> I wouldn't see reification as a disaster for Java if it did arrive, not
> sure whether Fabrizio is basing this on reason or feelings again.

You know, I'm not an expert of these things, so it must be at least
partially feeling. But I don't see how could be possible to introduce
reification without sacrificing part of the backward compatibility. I'm
with Sun and Oracle on this, it's an important aspect, because I see how
reluctant people are to move to a new version (even in this period when
JDK 6 is going EOL, I don't know a customer who's going to move, with the
exception of a single project where I've been the lead and I prepared
everything for a smooth transition to JDK 7, and there are chances we move
in the next weeks. I see the introduction of reification as a big increase
of the cost of my former two migration steps (see my previous email) and,
as Cédric said, just a small value in return.

[Casper Bang]

The easiest measure that shows Java is advanced, is the shear inbalance of NET projects that are ports of Java libraries. It seems a lot of people appreciate and value these commodities and thats why they port them. There is very little in comparison going the other way. All numbers are relative, but cannot be disputed that many of the cool libraries on NET came from Java. Java itself has also copied ideas, ports etc from other places, but IMHO its obvious who is in front of whom

Keep in mind though, that more Java developers move over to .NET than the other way around and that probably has a direct effect on ports. Also, if you listen to pod-casts, you will undoubtedly have noticed how .NET people are not shy about looking over the fence to the neighbors whereas (some of) the Java community is a bit uptight about their own turf. Just as a fun exercise, go take a look at the interview/topic list between .NET Rocks and The Java Posse and notice the difference.

Also, for a very long time, the mindset in the Java camp has been either rebuttal (we still don't have closures*, it took over a decade to get enums etc.) or even ridicule of alternatives (Ruby, Mono etc.). Thankfully this has changed somewhat over the last couple of years, pushed by JVM polygloth, Android etc., however just a few episodes ago, you could still find the Java Posse inflate a minute news-item about the deprecation of Moonlight into a 10 minute general rant about Mono.

*http://benhutchison.wordpress.com/2009/02/14/suns-rejection-of-delegates-for-java/

[Fabrizio Giudici]

On Thu, 04 Oct 2012 10:56:52 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> Keep in mind though, that more Java developers move over to .NET than the
> other way around and that probably has a direct effect on ports. Also, if

Again, I'd like to have some proof of this, because Java is declining, but
C# seems to. If we don't build these assertions upon something that can be
proved, and it's beyond the personal anecdotal experience (for which I
surely presume bona-fide, but it's still anecdotal), we can say everything
and its opposite.

[Casper Bang]

On Thursday, October 4, 2012 11:16:46 AM UTC+2, fabrizio.giudici wrote:

Again, I'd like to have some proof of this, because Java is declining, but  
C# seems to. If we don't build these assertions upon something that can be  
proved, and it's beyond the personal anecdotal experience (for which I  
surely presume bona-fide, but it's still anecdotal), we can say everything  
and its opposite.

As flawed as it is, I guess I'd have to invoke the Tiobe index proof:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

However, what I was was based more on my own experiences in the industry than Tiobe. Java is declining less thanks to Android (yay), the Java numbers would certainly be lower without Google around.

[Reinier Zwitserloot]

On Wednesday, October 3, 2012 7:10:28 PM UTC+2, fabrizio.giudici wrote:

Let's first reset the discussion and have a check on a piece of  
information of mine that I'm probably getting wrong. I'm still assuming  
Java 8 will do generics reification. Is this right?

No, that is most definitely not in the cards, and it was only a very small maybe for a very short period of time. Generics Reification is highly unlikely to show up in 9, either.

 

Let's define my concept of backward-compatible in this scenario. I'm a  
corporate, I have a large codebase in Java 6 (for instance). My upgrade to  
JAva 7 will be incremental and made by a path such as:

1. I move to JDK 7 with --source --target 6 and check whether it runs on  
JDK 6. Eventually I fix things so this happens.

This is a strange decision; you're sticking with java6 (the language) and java6 (the class file format), but you're moving to java7 (the runtime library), by doing this, except that last part is a mix of what you compile against and what you run on (are you running on JVM7 or JVM6 with the class files that fall out of this compile run?) If JVM6, then you should probably also use a JVM6 bootclasspath. However, at that point, what are you really testing here? Every javac ever released gets this right, with extremely tiny edge cases where it doesn't (such as trying to call a private method on a parameterized type whose erasure matches your own type. This was legal in Java6 and Java5, and is not legal on Java7, even with --source 1.6).

  

2. Then I check whether the thing runs on JDK 7. Eventually I fix things  
so this happens. At this point I'm mostly happy, since the biggest trouble  
with Java 6 is when it goes EOL. Now I'm on a runtime that is still  
getting patches.

Okay, but this is a _much_ more complex switch than making sure your code compiles when using -source 1.7 -target 1.7. Of course, if you do that, you HAVE TO run on JVM7, because JVM6 won't accept the output, and you can't make an intermediate step with -source 1.7 -target 1.6, because javac does not accept that.

 

3. I now move to --source --target 7. Eventually I fix things so this  
happens.

Right, so this is pretty much a gimme when you've gotten this far.

 

4. At this point, I can incrementally start using features of Java 7.

Sure.

 

"Fix things so this happens" admits that I have some work to do, if this  
work is very well confined I still call it (practical) backward  
compatibility of a new JDK. Perhaps I'm using the wrong term?

Java8 will also give you the opportunity to use the above schedule. Nothing will change; javac8 will accept -source 1.7 -target 1.7 and will produce class files that run just fine on either JVM7 or JVM8, and you are quite unlikely to run into any issues when you do so. When you are ready, you can take your 1.7 source files and compile them using javac8 -source 1.8 -target 1.8 and it'll most likely compile just fine with no errors. The biggest clash here will be 'default' methods and how there might be some weirdness if you e.g. extended java.util.List with a custom class and gave it a sort() method. That SHOULD work fine, but I can foresee some minor issues there.

At that point you can start using J8 features.

That was my point, really: Java 8 is no different from java7, 6, 5, 4, 3, 2, or 1.1. In fact, it is 'nicer' - java4 and java5 remain the least backwards compatible releases; java4 introduced 'assert', and java5 introduced thousands of warnings if you tried to compile java4 code on it with -source 1.5.

[Russel Winder]

On Wed, 2012-10-03 at 18:57 +0200, Fabrizio Giudici wrote:
[…]

> PS In a post here from yesterday I've read about people moving to
> "smaller" Java systems and Python. Not C#. And how does Python do
> benchmarks on millions of floats? Or perhaps what people appreciated is a
> different thing? I'd be happy to know by the OP more details on this.

Clearly Python is not yet able to compete with C, C++ or Fortran at huge
computations, but using PyPy, simple computations can be about 5x → 10x
slower than C. But this matters not in the context of use which is fast
evolution, few runs computations.

The rationale for finance industry, bioinformatics, CERN, and the like
to use Python is that it is more than fast enough for that which it is
asked to be used for computationally, and significantly faster for the
using community to evolve to that which is needed.

This says nothing about Python versus any other language in any
technical sense, it is just an observation on why Python is gaining
traction again.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Fabrizio Giudici]

On Thu, 04 Oct 2012 11:39:19 +0200, Casper Bang <caspe...@gmail.com>
wrote:

> As flawed as it is, I guess I'd have to invoke the Tiobe index proof:
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> However, what I was was based more on my own experiences in the industry
> than Tiobe. Java is declining less thanks to Android (yay), the Java
> numbers would certainly be lower without Google around.

Just read Tiobe yesterday before my posts and if you look at the graphs,
C# trends in the past year is controversial. After a peak, it has gone
down and on a year average it seems flat since 2011. Too bad data aren't
available in numeric format, I'd like to run some moving average (well,
too bad that Tiobe doesn't understand the value of moving averages).

I still have doubts that Tiobe is including Android in Java. The rate of
decline of Java on a multi-year average is pretty stable and if it
included a ramp up of Android this meant that there should have been a
faster Java decline started exactly at the same time of the introduction
of Android (first coincidence) and with an increase of the slope exactly
of the same magnitude of Android (second coincidence). Also, read here:

http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm

"The language should have an own entry on Wikipedia and it should clearly
state that it concerns a programming language. This is the reason why
(Ruby on) Rails, Excel, Android, Boost, Cocoa, ASP and AJAX are not
considered programming languages for the index."

I think that most job announces and google-related searches about Android
use the Android word, and not Java. That's the reason I think Tiobe could
be missing them.

Also consider that tags at StackOverflow (ok, they measure a different
thing) see C# 1st and Java 2nd; if you sum the Android tag frequency to
Java tag frequency, Java gets first:

http://programmers.stackexchange.com/questions/165934/why-is-there-a-large-discrepancy-between-the-stackoverflow-tag-frequency-and-the

Just a hint that Android is not "included" in Java. Of course, these are
very vague considerations... It's frustrating not having a reliable source.

[clay]

A quick test with Python 3.2.3 and numpy int arrays yields (I also tested 2.7.x and the results weren't much different):

arrayTest with n=1.0e+03 completed in 0.14937710762023926 seconds

arrayTest with n=1.0e+04 completed in 1.50266695022583 seconds

arrayTest with n=1.0e+05 completed in 14.913049936294556 seconds

These results are extremely slow. Well outside the ballpark of the Java/Scala/C# numbers. I tried PyPy, but that gave me errors with NumPy.

While Java is very strict about all libraries being native Java and fully JVM and cross platform, Python is not. Many Python libraries are written in C, particularly performance sensitive ones, so Python apps often run quite fast, even if they rely heavily on C code.

Python is popular because it's very simple, easy to learn, lightweight. It's easy to use without an IDE or project files or build scripts and it's frequently used through a REPL. None of these things are unique, Scala/Groovy come with excellent REPL interfaces, but I think Python gained a lot of mindshare for this type of usage. The big strength of Python is its community. Also, lots of people who previously would have used Matlab, R, or Mathematica for REPL centric calculation tasks (including myself) have switched to Python. Take a look at the SciPy conference and you can really see that there is a vibrant community of natural science types that have built up around Python.

Here is the Python code I used:

import numpy

import time

def arrayTest(n):

a = numpy.zeros(n, dtype=numpy.int)

# Do something with the array...

for i in range(0, n):

a[i] = i

for k in range(0, 100):

for i in range(0, n):

a[i] = a[n-1-i] * 2;

def doTiming(name, f):

start = time.time()

f()

elapsed = time.time() - start;

print('{0} completed in {1} seconds'.format(name, elapsed))

def timeArrayTest(n):

doTiming('arrayTest with n={0:.1e}'.format(n), lambda: arrayTest(n))

if __name__ == '__main__':

    timeArrayTest(1000)

    timeArrayTest(10000)

    timeArrayTest(100000)