More than 2800 developers speak out about Java 8

I guess that even for Google would be cheaper to just upgrade it to support Java 8 features than to replace it completely with something else. Especially since that "something else" would still need to support all existing apps for a long time to go. Otherwise, they could as well just cancel Android as a whole.

I really don't think google will consider that seriously for the low level. The point of dalvik is to provide a consistent low level platform for arbitrary phone manufacturers to support, which is something the jvm is explicity designed for (in a more abstract manner). Node has an interesting, simple, and effective approach to concurrency, but if I am interpreting your comment correctly I do not think node is the proper choice for a phone platform. Don't mistake an ease of abstraction in one realm for an ease of abstraction in another (specifically abstractions suited towards phone apps versus concurrent processing).

yeah whatever, they will never do that.

Did you forget Google created Dart because Javascript is a stupid mess? Google has at least 2 languages (Dart/Go) to try on before they'd even think about that turd that is javascript. And the list goes on GWT .... Google is definetly a Java shop,doing everything not to code in javascript.

I don't see how they would benefit from this sort of sabotage... Switch it to Node and quickly sell it to Microsoft?

Yes.

"Speak out" in that context is not universally negative, but it does tend to imply criticism.

> Why would this be considered "an outright lie"?

I think that comment was a bit exaggerated.

> Does "speak out" always have to be attributed to negative opinions?

I would say no, not always, but generally, yes. That's exactly what I thought when I read the headline and then when I went to the link I was disappointed that I wouldn't find a critique of Java 8. I am, however, still interested in a survay ;)

Note that I am enthusiastic about Java 8, so thinking there was a valid critique of it really piqued my interest.

No, they are stating that they technically have a large enough sample for the results to be meaningful if the sample were unbiased (what they call 'scientifically random') - a large enough sample size is a necessary but not sufficient condition to allow valid statistical inferences to be drawn.

Scientifically random would be choosing data points such that each member of the target population, Java developers, has an equal chance of being surveyed. This blog's survey has a couple biases, one is self selection (it was only posted on the blog so only people who read the blog have responded).

When drawing a survey population that you want to use to extend knowledge to the total population you need to sample in a way that doesn't introduce bias. The Simple Random Sampling method is the gold standard here: sample in a way such that each subset of the total population of a given size has equal chance of being selected. This includes, as a special case, that each individual has an equal chance of being selected.

http://en.wikipedia.org/wiki/Simple_random_sample

More complex sampling methods can be used since SRS is usually intractable (you'd need to put every single person in your superpopulation into a lottery by magic, else you'll bias toward those who like email surveys or actually read their mail). In the event you use one of these you usually need a bias mitigation strategy. For instance, you might just state something like "we assume that receptiveness to email and dislike for Java are correlated". It's then up to the reader to decide whether they trust your assumptions.

You might also do some other support studies which help to measure the size of the bias your non-SRS sampling methodology induces and then correct for them.

I'm assuming that is a good number for a randomly sampled group. The self selection nature of people that will be taking a typesafe survey gives me doubts about whether it is good here.

But also google: self-selection bias, which invalidates pretty much all online polls, including this one.

I also don't see that as the primary source of verbosity in Java.

In Scala I can do:

import com.foo.bar.{Bar => FooBar}

But that's mostly just useful for dealing with cases where you have to deal with classes with the same name in different packages.

The verbosity in Java comes from a lack of type inference, lack of first-class properties (get/set naming convention doesn't count), and a whole basket of other missing features. Another large contributor to Java verbosity is sadly the the Java culture of over-engineering and resistance to change which has built up over the years (the latter partly in response to the glacial evolution of Java in the last decade).

E.g. -

I personally prefer unchecked exceptions to error codes, but otherwise, compare C's "#include <stdio.h>" to Java's "import java.io....;". (markdown won't let me put in a star here for some reason)

The FILE * type is so much more compact an interface than the zoo in the Java io package. Select an appropriate fopen/popen "factory method call", and off you go.

Regarding exception types, the Java libs have too many exception types you either must catch in the wrong place, or redeclare as thrown, rather than how C# does it with unchecked exceptions.

Why do people keep saying this? It's blatantly wrong, as mentioned multiple times by the JodaTime author itself.