I primarily use "Java" on Android. I'm very excited to see the language progressing. Recently, I read Gosling gave Oracle a B+ on stewardship of the language:
However, I'm getting pretty nervous with the lack of conformance Android Java has to the real Java stack. The two are diverging, and I don't see how Google can remedy this.
My guess is that Java 6 & 7 were modest enough that many developers of open source libraries thought it easy to support a profile that worked on Android.
If Java 8 adoption is as brisk as this poll suggests, with all the features many have been waiting for, I'm worried a lot of the libraries I use may become incompatible with Android.
Already, its hit and miss if a open source java library works on android. I just tried lmax disruptor and it didn't work. Things that depend on NIO.2 won't work either.
Still too early to tell about adoption. The article wasn't specific enough - it may be that as people find out about Android incompatibilities they hold off their upgrade plans, regardless of their apparent insatiable appetite for lambdas.
The worst that could happen is if android drops java as the primary language. I wonder if google is willing to do that, or if they are now too invested in the language to drop it.
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).
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'm also of the opinion that Google will not replace Java-based Android with nodejs-based Android.
On the other hand, I think it's worth pointing out that a lot of JavaScript development does happen at Google, albeit within the confines of the Closure compiler. Some kind of nodejs project somewhere at Google would not be out of the question. It's a big company. https://www.npmjs.org/package/closurecompiler
my point is given the success of all these javascript only mobile plateforms, it's not going to happen.If one wants to develop js apps,the web is here and free.That's why these weboses make little sense.
Google invest plenty of resources in JavaScript as well - they're active in helping define ECMAScript 6, they created V8 and Angular.js, and they employ a bunch of the world's most talented JavaScript programmers.
Yeah, Google seems to be in a awkward space with their Java implementation with Apache depreciating the project it was based on. Right now they just seem to be doing nothing, but at some point they'll have to make a move...
I sincerely hope Google will upgrade the Dalvik compiler to accept Java 8's syntax. My wishful thinking is that they did not find compelling reasons to upgrade the spec to Java 7 since it did not represent a major upgrade when it comes to the core language. It has some definite improvements over Java 6, but there was no true groundbreaking improvement over older Java versions. At least not to the same degree as generics in Java 5 or now lambdas in Java 8.
Besides, Java 8 lambdas should tickle the fancy of Google's engineers. First, it introduces a feature that is already trivially available in Javascript, Python and Go. In addition, remember that Google already develops and heavily uses the Guava library, which introduces the least painful workarounds to use some functional programming in Java, so it seems there is some motivation already.
It would be a pitiful split for the Java community if Google does not adapt Java 8. I fully expect that Java 8 lambdas will change the way Java programming is done. If Google stays with a pure imperative Java, it will likely split the ecosystem in two different languages. Java 7 did not introduce enough language features for this to happen, but Java 8 definitely will.
> Immediate Java 8 Migration Plans: 65% of Java developers have plans to upgrade to Java 8 within the next 24 months.
Er; "within the next 2 years" = "immediate"? That's a long-enough time scale that a lot of the respondents may be thinking "well, all our enterprise stuff is still on version 6, but surely my plans to overhaul everything won't take more than two years, will they?"
Also, 2800 is not actually a very high number, is it? Is that enough to be representative of Java developer intentions, preferences, etc.?
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.
I would like to have my hands on the actual data so I can divide results by years of experience etc. This is too generic and doesn't server truly a purpose other than create some hype about Java 8.
Now, what I would LOVE it would be a survey and thorough interview of the public before Java 9 is built instead of after...
As long as java doesn't support aliasing (ie: import com.tool.foo.Bar as FooBar) , its gonna be very hard to tackle the extreme verbosity java results in.
As a working Java programmer, I wouldn't have said that this was the main source of verbosity in Java. Could you perhaps expand on how this results in verbosity? Perhaps an example of some code in Java as it exists now, and a less verbose version of the code in a hypothetical Java-with-aliasing.
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).
The verbosity of Java is because you have to take care of stupid low level details. All kinds of buffered readers, loops, internal class state juggling, etc. There is no support for first class functions, despite them tacking lambdas on awkwardly.
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.
They say "That being said, the sample, while not scientifically random, is double what’s considered statistically relevant for the total population of Java developers worldwide."
Great. So to forecast the next presidential election they're going to poll a million NRA members and celebrate the fact that the sample size is much greater than what's needed.
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.
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.
In addition to the problem you point to (size of a sample is irrelevant if it isn't random), statistical relevance of a sample is based on the size of the sample alone, not the size of the population, so their claim that it is "double what's considered statistically relevant for the total population of Java developers worldwide" is nonsense.
The survey went out to largely a Scala audience (anyone signed up for the Typesafe newsletter). As a developer using mostly Scala with some legacy Java code to maintain I see various benefits to Java 8:
1) More enhancements to the core java libs that are more functional programming friendly for use from Scala.
2) Legacy Java code less painful to maintain.
3) Java programmers suddenly stopped calling $FEATURE evil, since Java now provides $FEATURE too (well for a small subset of Scala features anyway).
Can someone please moderate the title? The actual blog article title is "Java 8 Survey Results". The given HN title of "More than 2800 developers speak out about Java 8" is misleading, if not an outright lie.
Why would this be considered "an outright lie"? Does "speak out" always have to be attributed to negative opinions? This article wasn't perceived as negative towards Java in my eyes, but one could say that the respondents to the survey spoke out about their future intents and most desired features.
> 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.
I was expecting a more critical piece as well, but I'm not sure the words "speak out" gave me that impression as much as the fact that it was (a) a survey about Java and (b) HN front page news. Java is not always a popular topic here.
One could interpret some of the answers as a bit critical of Java (or the community), but not Java 8 specifically. The fact that 22% of Java devs are using a release that is 7 years old and hasn't been updated in a year isn't something the Java community is likely bragging about.
I mentioned elsewhere in the thread that the takeaway for me was that 83% were excited about lambdas, which Scala already offers, and the notion that Java's future updates might start looking more like Scala. So the survey may suggest "why not just use Scala?"
For me, "speak out" implies mostly unsolicited statements of opinion. Negative or positive does not play a role. Replying to a solicited survey does not constitute speaking out. Representing the results of a survey as a mass "speaking-out" gives far more impact to the article than it would otherwise have, as if it were some spontaneous outpouring of opinion on the subject.
Regardless, I thought HN had a policy against editorialising article titles.
Is it just me, or does this survey say basically nothing at all? Here's a summary if you don't want to bother reading the PDF (and you probably shouldn't bother):
- Most use Java7, a few still use Java6
- Mixed response on when exactly people will upgrade to j8
- Most exciting feature in j8 is lambdas
- 98% use Oracle JVM, 20% use dalvik (android)
- App servers popularity is Tomcat, Jetty, Jboss, others
- Mixed thoughts on Oracle getting security right
Seriously, what is the point of these questions...? You could get all these answers with a google search.
It doesn't say much. This survey will likely be picked up by Java news sources and read by Java devs, since there don't seem to be many surveys geared towards Java devs these days. Maybe some of them will check out Scala.
Why would the company most behind Scala post a very positive survey about Java? One would think that Scala's success probably relies on either replacing or supplementing Java.
The only item that would be rather newsworthy would be the plans to adopt 8, but as you mentioned the survey doesn't provide a clear answer.
My takeaway was that the most interesting new feature for people was lambdas, and Scala already offers lambdas. This could be interpreted as "Survey respondents are most excited about a Java feature that they could already have if they used Scala".
Java 8 is very interesting to me, and although Lambdas get the most publicity, I feel the concurrency updates and streams are the most important new features.
I'm actually the most excited about JodaTime basically being baked into the language. Date and Calendar are so, so bad that it would be hard for Instants to not be an improvement.
Because one of the main authors behind JSR-310 happens to be the JodaTime author and considers it to be inspired by JodaTime, even if it's different to fix some flawed assumptions JodaTime made [1]. And as far as practical use goes, they're very similar, since they draw upon the same concepts. I don't see how it isn't a fair description, especially when you compare to how bad Date/Calendar are right now.
The new Date & Time API deserves more attention. Working with and persisting dates has always been one of the bigger pain points when working with the JDK. Just last week we encountered some strange bug in Grails where it won't persist null values if using custom UserTypes under certain conditions (which we need to persist Joda date types).
56 comments
[ 3.6 ms ] story [ 76.4 ms ] threadhttp://info.typesafe.com/acton/attachment/3608/f-004a/0/-/-/...
http://www.javaworld.com/article/2087444/open-source-tools/j...
However, I'm getting pretty nervous with the lack of conformance Android Java has to the real Java stack. The two are diverging, and I don't see how Google can remedy this.
My guess is that Java 6 & 7 were modest enough that many developers of open source libraries thought it easy to support a profile that worked on Android.
If Java 8 adoption is as brisk as this poll suggests, with all the features many have been waiting for, I'm worried a lot of the libraries I use may become incompatible with Android.
Already, its hit and miss if a open source java library works on android. I just tried lmax disruptor and it didn't work. Things that depend on NIO.2 won't work either.
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.
On the other hand, I think it's worth pointing out that a lot of JavaScript development does happen at Google, albeit within the confines of the Closure compiler. Some kind of nodejs project somewhere at Google would not be out of the question. It's a big company. https://www.npmjs.org/package/closurecompiler
Besides, Java 8 lambdas should tickle the fancy of Google's engineers. First, it introduces a feature that is already trivially available in Javascript, Python and Go. In addition, remember that Google already develops and heavily uses the Guava library, which introduces the least painful workarounds to use some functional programming in Java, so it seems there is some motivation already.
It would be a pitiful split for the Java community if Google does not adapt Java 8. I fully expect that Java 8 lambdas will change the way Java programming is done. If Google stays with a pure imperative Java, it will likely split the ecosystem in two different languages. Java 7 did not introduce enough language features for this to happen, but Java 8 definitely will.
> Immediate Java 8 Migration Plans: 65% of Java developers have plans to upgrade to Java 8 within the next 24 months.
Er; "within the next 2 years" = "immediate"? That's a long-enough time scale that a lot of the respondents may be thinking "well, all our enterprise stuff is still on version 6, but surely my plans to overhaul everything won't take more than two years, will they?"
Also, 2800 is not actually a very high number, is it? Is that enough to be representative of Java developer intentions, preferences, etc.?
Now, what I would LOVE it would be a survey and thorough interview of the public before Java 9 is built instead of after...
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).
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.
Great. So to forecast the next presidential election they're going to poll a million NRA members and celebrate the fact that the sample size is much greater than what's needed.
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.
1) More enhancements to the core java libs that are more functional programming friendly for use from Scala.
2) Legacy Java code less painful to maintain.
3) Java programmers suddenly stopped calling $FEATURE evil, since Java now provides $FEATURE too (well for a small subset of Scala features anyway).
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.
One could interpret some of the answers as a bit critical of Java (or the community), but not Java 8 specifically. The fact that 22% of Java devs are using a release that is 7 years old and hasn't been updated in a year isn't something the Java community is likely bragging about.
I mentioned elsewhere in the thread that the takeaway for me was that 83% were excited about lambdas, which Scala already offers, and the notion that Java's future updates might start looking more like Scala. So the survey may suggest "why not just use Scala?"
Regardless, I thought HN had a policy against editorialising article titles.
Why would the company most behind Scala post a very positive survey about Java? One would think that Scala's success probably relies on either replacing or supplementing Java.
The only item that would be rather newsworthy would be the plans to adopt 8, but as you mentioned the survey doesn't provide a clear answer.
My takeaway was that the most interesting new feature for people was lambdas, and Scala already offers lambdas. This could be interpreted as "Survey respondents are most excited about a Java feature that they could already have if they used Scala".
[1] http://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941....